On 03/17/2011 05:29 AM, Niels Möller wrote:
Daniel Kahn Gillmor dkg@fifthhorseman.net writes:
My problem with this is that i then have to handle the case where the user invokes process() without having remembered to set a key.
Can't you just raise some error ?
Sure, but that introduces a different kind of ugliness -- i'm not sure that trading off this ugliness for the other one is worthwhile, though i'm willing to be convinced.
You'd need to have some flag to remember if it's been initialized, but you need that anyway for the is_encrypt method, right?
i'm not sure i see the parallel. is_encrypt() says whether the Crypt::Nettle::Cipher object was initialized as an encrypting cipher or a decrypting cipher.
I'm actually not enforcing any of these constraints in the perl code -- they'll just crop up if the user passes the wrong data down to the library underneath.
That seems a bit dangerous. I thought the principle was that it shouldn't be easy to write perl code which triggers some assertion failure in some C routine.
Yes, that would be ideal. I think the right way to go in the long term (as noted in the BUGS section of Cipher.pm) is to add internal buffering for process() calls so the user can pass arbitrarily-sized data to the object.
The extra fiddly bits with this arrangement are:
0) process_in_place() is still brittle: you won't be able to call it at all if the internal buffer isn't on a clean block boundary, and you also won't be able to call it with arbitrary-sized data.
1) the data retrieved from process() isn't guaranteed to be the same size as the data fed in.
2) i'll need to introduce a finish() call that handles some sort of padding and emits the final data.
It's a bunch more bookkeeping internally, but it does seem like it would let the user treat the block ciphers as something approximating a stream cipher without having to think much about it, which would be nice.
I think getting RSA working is higher priority for me at the moment, but i'll certainly keep this suggestion on my plate.
It's in the CVS version of Nettle, but not yet in any release. Maybe most of the discussion was private rather than on this list?
When a new version is released, i'll be happy to update the perl bindings to enable access to the new features :)
Is the revision control for Nettle publicly visible?
--dkg