-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The approach should be:
Create a bunch of symetric keys (keep them in your process memory -
anyone with root access or same user might still be able to capture them)
save those sym-keys into your db protected by a PubKey (also called
a KeyEncryptionKey).
And ONLY AFTER you saved them (protected!) use them (aes is a good
choice) to encrypt your data please!
(in case something crashes your data would be lost otherwise)
Just in case it is important stuff you want to secure, you should
pre-create keys and back them up first.
btw. an 1024 bit RSA key will only encrypt less than 128 Bytes
For the records a 2ghz dual AMD would only encrypt a little more than
800 kbytes/second pubkey ops (1024 RSA)
or ~110.000 kBytes/sec 128-aes, (more than 100-fold)
Security experts nowadays suggest using 2048 or 4096 bit RSA's which
would boil down to 350kb/s.
cheers thilo
bash-4.1# openssl speed rsa1024
Doing 1024 bit private rsa's for 10s: 4087 1024 bit private RSA's in
10.01s
Doing 1024 bit public rsa's for 10s: 86372 1024 bit public RSA's in 10.01s
OpenSSL 1.1.0-dev 10 Jul 2009
built on: NetBSD 5.99.38
options:bn(32,32) md2(int) rc4(4x,int) des(ptr,risc1,16,long)
aes(partial) blowfish(idx)
compiler: gcc version 4.1.3 20080704 (prerelease) (NetBSD nb2 20081120)
sign verify sign/s verify/s
rsa 1024 bits 0.002449s 0.000116s 408.3 8628.6
On 2/23/2011 12:36 PM, Max Vlasov wrote:
> On Wed, Feb 23, 2011 at 1:03 AM, H. Phil Duby
> <phild...@phriendly.net>wrote:
>
>> On Tue, Feb 22, 2011 at 9:07 AM, Philip Graham Willoughby
>> <phil.willoug...@strawberrycat.com> wrote:
>>>
>>> On 22 Feb 2011, at 15:41, Max Vlasov wrote:
>>>> The obvious solution is public-key cryptography. The
>>>> question is about different ways how it could be implemented
>>>> with sqlite. The requirement
>> for
>>>> this system is that it should operate in two modes: -
>>>> insert-only when no reading operation is used. This mode
>>>> uses public
>> key
>>>> to store the data - full-mode when the private key is
>>>> supplied and any operation is
>> possible.
>>>
>>> It might work, but it wouldn't be quick. Public-key
>>> cryptography is very
>> slow. There are benchmarks on this page (
>> http://www.cryptopp.com/benchmarks.html) but most of what you
>> need to know is in the choice of scale: AES and other shared key
>> systems are in cycles-per-byte and RSA/friends are in
>> megacycles-per-operation.
>>
>> The simple answer to 'public-key' cryptography is very slow', so
>> to not encrypt the complete text. Instead you generate a random
>> key for one of the good [and fast] symmetric encryption
>> implementations, encrypt the complete text with that, and
>> encrypt only the symmetric key using public-key encryption.
>>
>>
>
> Good point, Phil. In case of virtual tables and insert-only mode
> there might be some intermediate caching (for example based on the
> boundaries of transaction) that uses the same random key. When the
> transaction ends the random key will be saved encrypted. In the
> worst case when a single record inserted wrapped in a transaction,
> one will get worst performance, but inserting a bunch of records
> will give a performance boost.
>
> Thanks for the idea,
>
> Max _______________________________________________ sqlite-users
> mailing list sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1uUu8ACgkQrfkjR68QUadLIACdHdS1ps1XtCzQ6axcRdAu/Dl2
tXAAn0Vt0LBW7zXNKxtezX77kmFiVr1s
=rEKe
-----END PGP SIGNATURE-----
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
