[Botan-devel] Small file ciphering speed

Mr Diggilin mr.diggilin at gmail.com
Thu Sep 18 06:24:36 EDT 2008

Thank you for you're reply. Unfortunately I have to confess I'm rather
new to this, and so for the most part you lost me.
One thing is that it seems I didn't make clear is that the database
fields are completely independent of one another. Random access is the
rule. This is where the problem is. I am making a new pipe & key and all
that for every single 50 byte field. My question is what my options are
for making such a system faster (or perhaps someone has a completely
different approach to recommend?).
I've already put forth the possibility of reusing the key and reusing
the pipe...
As for the key reuse, I understood the security problem you brought up,
but I didn't understand the solution, perhaps because you thought I was
doing something I'm not with the database.
As for the pipe reuse... is that recommended, or is there another way to
deal with a whole bunch on little encryption jobs?

Thanks again.
-mr diggilin

On Thu, 2008-09-18 at 08:27 +0200, Christophe Meessen wrote:
> Hello,
> don't know how this can fit your needs and with Botan but here are my 
> suggestions.
> Though some informations are missing. Is decoding always sequential and 
> in the same order ?
> Could there be missing/deleted/inserted  records in the sequence ?
> A single global key is enough if the amount of data is limited and 
> encrypted data is not much exposed. The security can be increased by 
> using a different key for each record, but you'll pay it with increased 
> processing time.
> The key to be used for each record would be a concatenation of a 
> sequence of random bytes common to all records (salt) and the record 
> identifier. It is assumed that the record identifier is a constant for a 
> given record. Encrypt this constructed key with a global key and save 
> the random bytes to generate the record key secured and hidden with the 
> global key. It is probably more secure to insert the record indentifier 
> in the middle and not at any ends of the record key.
> For the record itself I would recommend ctr, or better cfb, as chaining 
> algorithm because they doen't require adding padding bytes and are quite 
> fast.  The trick used to generate the  secondary key is the same working 
> principle used in ctr.
> With this method you will be able to decode any record with random 
> access. Records can be added or deleted. The only constrain is this 
> constant record identifier.
> I don't understand the S2K with 100 hash rounds. If this done for each 
> record, this is indeed not very efficient.
> Mr Diggilin a écrit :
> > I'm trying to use botan for encryption and decryption of thousands of
> > database rows with very little data (~50 bytes) in them. What I'm doing
> > currently takes about 1/4th of a second per field, which is *much*
> > slower than would make this practical. I have a few thoughts on how to
> > optimize, but I thought I'd ask here first to find out:
> > a. What's a good way of doing this with Botan?
> > b. What kind of speed can I expect?
> > c. I'm using an S2K with 100 hash rounds for each operation, which isn't
> > much. Would there be any security concerns if I reused the same key
> > (with more rounds) over all of the thousands of entries?
> >
> > My current de/ciphering routine as follows:
> >
> > auto_ptr<Pipe> Crypto::RunCipher(string Passphrase, wxInputStream * In,
> > SecureVector<byte>& Salt)
> > {
> >   Cipher_Dir Dir = (Salt == NULL) ? ENCRYPTION : DECRYPTION;
> >   KeyAndIV = 100 round s2k;
> >   SymmetricKey Key(KeyAndIV, KeySize); //256 key
> >   InitializationVector IV(KeyAndIV + KeySize, IVSize); //128 IV
> >   auto_ptr<Pipe> Out(new Pipe(get_cipher("Twofish/EAX", Key, IV,
> > Dir)));
> >   Out->start_msg();
> >   *In >> *Out;
> >   Out->end_msg();
> >   return Out;
> > }
> >
> > _______________________________________________
> > botan-devel mailing list
> > botan-devel at randombit.net
> > http://lists.randombit.net/mailman/listinfo/botan-devel
> >   

More information about the botan-devel mailing list