[email protected] (Niels Möller) writes: > So the question is, should we decide that nettle_cipher is för block > ciphers only (where the encrypt and decrypt functions don't change any > state )? Fitting arcfour and block ciphers into the same > abstraction doesn't make much sense anyway, since they should be used > very differently. Then we can make the context argument const for > nettle_crypt_func, but we'd also have to delete > > extern const struct nettle_cipher nettle_arcfour128; > > or replace it with something else, which is an incompatible interface > change. As long as it's the only supported stream cipher, it doesn't > make much sense to me create a new general stream cipher construction.
Breaking API compatibility is painful. Other libraries like libgcrypt also try to use the same interface for both stream ciphers and block ciphers too. However, in my experience this makes things difficult at a higher level -- the distinction perculate up because stream ciphers doesn't (for example) have a block length so you either have to say it has a block length of 1 byte (or 1 bit if you support bit-lengths) which can cause problems if you want to do MAC or other processing on a block-by-block basis (MAC:ing each byte is not a good idea..). So I would support making stream ciphers a different beast than block ciphers as far as the API goes, unless the API change is too painful. If we had used a object oriented language, there could be a super-class "cipher" and two sub-classes "block cipher" and "stream cipher". Then some functions could take any "cipher" and some (like GCM) could take any "block cipher". Fortunately we aren't using OO here though. :-) /Simon _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
