comment on

SQLite Encryption Extension

Second paragraph on that page (emphasis mine):

Some of the documentation on this website is open to viewing by the general public. However, access to the SEE source code and precompiled binaries requires a username and password, which is available only to licensees. Perpetual source-code licenses are available for purchase separately.

So, security by obscurity? Sorry, but that has a certain unwelcome smell. See Kerckhoffs's principle.

https://www.sqlite.org/see/doc/release/www/readme.wiki lists the following algorithms:

RC4 with security enhancements
AES-128 in OFB mode
AES-128 in CCM mode
AES-256 in OFB mode
Simple XOR (in the text below the list)

XOR is explicitly documented as "demonstration module that does not do real encryption". Consider it broken.

RC4 is insecure, if not broken. Period. See RC4. There are no agreed "security enhancements".

AES-128 is probably still ok, if implemented correctly. But side channel attacks can be very efficient, recovering the entire 128-bit key using 6 to 7 blocks of encrypted content. See Advanced Encryption Standard.

AES-256 should be ok, if implemented correctly.

How can you check if AES is implemented correctly? How can you check the "security enhancemments" for RC4? Well, buy the pig in the poke, then look at what you bought. Security by obscurity.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

In reply to Re^2: How to secure SQLite3 in Windows IIS CGI by afoken
in thread How to secure SQLite3 in Windows IIS CGI by RedJeep

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


Problems? Is your data what you think it is?
	PerlMonks