On 11 Aug 2015, at 1:30pm, Eric Hill <Eric.Hill at jmp.com> wrote: > We're getting some pushback from our lawyers suggesting that SQLite's use of > RC4 even just to generate random numbers is, in their minds, encryption for > export purposes. Now, this makes absolutely no sense to me, I can assure > you, and I am not finding anything online that would suggest that is a valid > position, but I'm wondering if this has come up before and if you have any > good ammunition for dealing with such an argument.
Sorry, but the use of the encryption code in the product doesn't matter because the purpose of SQlite is not covered by Note 4 (see below). If the product-as-a-whole incorporates encryption code then it is covered by the law. But ... how serious is that for SQLite ? First <https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items> and flowchart 1. It seems we have to understand Note 4. My conclusion is that SQLite is not covered by Note 4 because it is for "storing information". So SQLite is controlled under Cat 5 Part 2 and we proceed to ... <https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration> and we easily find the top test in flowchart 2 linked to from the above page: <https://www.bis.doc.gov/index.php/forms-documents/doc_view/328-flowchart-2> SQLite seems covered under self-registration rules under 740.17(b)(2) because it has "Cryptographic functionality or "encryption component" that is user-accessible and can be easily changed by the user." because its source code is public. Consequently you may self-classify as DF002: "WITH an encryption registration". To be covered in such a way SQLite documentation must make it clear that the 'user' of SQLite is the programmer who incorporated it in their software, not the end-user of the software or the product that incorporates the software. If this is not true then the 'user' of SQLite could be a non=programmer who would not understand the source code sufficiently to "easily" change it. Since RC4 is used only to generate random numbers for a non-cryptographic purpose, it may be worth simply replacing that algorithm in random.c with one which does not resemble cryptography or bring cryptography to mind. My understanding is that this would not need to involve any failure in backward or forward compatibility. The above information was provided for free and worth every penny. If you want good advice consult a good lawyer. Simon.
