Nikos Mavrogiannopoulos <[email protected]> writes: > Let's say for example that someone wants to encrypt a message > that consists of a header (5) bytes and indefinite data provided by > some other layer. With the API that needs to know the block size, the > code to encrypt would be quite complex, while the blocksize-agnostic > code would be straight forward to use.
I'm been thinking a bit more. I'm leaning towards the nettle_aead struct as an interface to the aead primitives. Then, additional buffering should be done in the same way (ok, parameterized by the block size) regardless of the underlying algorithm, hence it's not a primitive at that level. For ease of use, I think we could have a family of aead_* functions which lets the application treat the nettle_aead as opaque objects. I think one could add functions for incremental processing too, not only the complete-message functions already sketched. How should the easy-to-use interface for incremental encryption/decryption look like? I see two alternatives: Either provide some macro or function, which, given an aead algorithm and the input size, returns the largest possible output size. Then the application should arrange to pass a large enough buffer, call the encrypt/decrypt function, which returns the amount of output actually produced. Or use struct nettle_buffer for the destination operand, possibly in combination with some macro/function to query the needed space. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
