Re: EasyPG API and usage questions

[Ted Zlatanov]

On Wed, 05 Mar 2008 16:25:22 +0900 Daiki Ueno <address@hidden> wrote: 

>>>>>> In <address@hidden> 
>>>>>> Ted Zlatanov <address@hidden> wrote:
DU> I think that it would not be too late to implement these features until
DU> someone else really wants them.  The former is not even provided by
DU> GPGME, GPA, etc.,

>> I don't think that just because a feature has not been done means it's
>> not useful.  I gave specific examples: I'd like to encrypt a Maildir
>> spool, and don't want to burn the CPU cycles necessary to use the
>> default cipher on it.  On the other hand, I want a good cipher (better
>> than the default if possible) applied to my passwords file.  If you
>> think those examples are only useful to me, I'll set up my own functions
>> to do it.  I think other users would like that kind of flexibility.

DU> Well, please don't make a hypothesis.  Do you really see any performance
DU> issues in your use cases?  Do you really see significant relevance
DU> between speed and strength of ciphers which GnuPG supports?

DU> I tried each cipher to encrypt 46MiB linux-2.6.24.tar.bz2, and got the
DU> following result: 3DES 4.201s, CAST5 1.558s, BLOWFISH 2.628s, AES
DU> 1.901s, AES192 1.988, AES256 2.108s, and TWOFISH 2.029s.  Here the
DU> fastest algorithm is CAST5 (128bit key), and the longest key length
DU> algorithm is AES256.  The time difference of them are only 0.55s (1/4 of
DU> AES256's).  The difference will decrease if the inputs are relatively
DU> small files in mail spools.

Right, because of startup costs.  Incidentally, is there a way to reduce
those by keeping GPG running continuously?  I couldn't find it in the
manual, but it will probably make a much bigger difference than the
cipher type.

I agree the difference is small, but it's measurable.  If you think it's
not useful to implement this, then let's drop the suggestion as we did
the other one (selective enabling of epa-file).

Ted