On 03/17/2011 05:29 AM, Niels Möller wrote:
> Daniel Kahn Gillmor <[email protected]> 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
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
