stream cipher refinements

[buggywhip]

This PR addresses several issues found while reviewing the stream ciphers. The current focus is on Salsa20/XSalsa20 and Sosemanuk, but the intent is, if in agreement, to extend the following to all stream ciphers. ...and perhaps block ciphers and hash functions.

1- flow control between the cipher's functions: enforce the calling of setiv() before calling crypt(), enforce the calling of setup() before calling setiv(), etc. The proper sequences vary for Salsa20, XSalsa20, and RC4 for example.

2- "one call" helper functions to support the [frequent] needs to crypt small, in-memory data with a single call. See Salsa20 and Sosemanuk in doc/crypt.tex.

3- an alternate and preferred way to get a cipher's state size. See bottom of Dynamic Language section in doc/crypt.tex.

4- miscellaneous small "corrections"

Checklist

• [ x ] documentation is added or updated
• tests will be added or updated

[karel-m]

Larry, there are IMO too much things combined in one PR.

1/ Things related to st->status

• I see the point, looks more or less reasonable

2/ The <something>_onecall stuff

• here it needs some discussion
• not that I am against but I am not sure whether there is a demand for this (I do not have a use case but others may have)
• naming convention - we already use *_memory style for encauth functions of similar kind
• these functions have to be in a separate .c files otherwise you get a bunch of useless bloat linked to your executable when using static library
• if we want to support this we should provide it for all stream ciphers

3/ Ad <something>_state_size

• thing like this IMO does not quite fit into libtomcrypt API
• having a special functions like salsa20_state_size, xsalsa20_state_size, sosemanuk_state_size for 3 "somehow chosen" structs simply does not look right to me
• do not we already have crypt_get_size for this?

4/ Renaming sosemanuk_state *ss > sosemanuk_state *st

• this will become a merge conflict with my PR fix clang-tidy warning: inconsistent-declaration-parameter-name #417 (or vice versa)
• not a big deal, just want you to know

And my comments to the code ... well, later :)

[buggywhip]

there are IMO too much things combined in one PR.

I agree. I will start over by canceling/deleting this PR/branch and resubmitting one for each topic. 1- stream ciphers - call order mgmt using st->status 2- stream ciphers - *_memory single function calls 3- stream ciphers - *_state_size functions And eventually, I'd like to see these concepts extended to block ciphers and hash functions where applicable.

[buggywhip]

2/ The <something>_onecall stuff here it needs some discussion not that I am against but I am not sure whether there is a demand for this (I do not have a use case but others may have)

I do. I write a lot of small[er] programs and virtually all my *cryptions are on small data, be the written in Python or C. A single helper function call as part of the called library is much preferred.

naming convention - we already use *_memory style for encauth functions of similar kind

I wasn't aware. I've adopted the *_memory() convention.

these functions have to be in a separate .c files otherwise you get a bunch of useless bloat linked to your executable when using static library

I moved the _onecall() functions to misc/crypt/crypt_helper_functions and renamed them _memory(). Building crypt_helper_functions.c is controlled by a #define for LTC_HELPER_FUNCTIONS and each function is likewise controlled by the define for that cipher. Is there some other reason separate files are required?

if we want to support this we should provide it for all stream ciphers

part of the original plan

[buggywhip]

3/ Ad <something>_state_size thing like this IMO does not quite fit into libtomcrypt API having a special functions like salsa20_state_size, xsalsa20_state_size, sosemanuk_state_size for 3 "somehow chosen" structs simply does not look right to me do not we already have crypt_get_size for this?

We do but these new functions make LTC much easier to use with languages like Python. From the dynamic language section in crypt.tex:

These new functions greatly simplify the supporting code needed in the calling programs. Using Python as an example, this new function instantiates `sosemanuk_state` with one line. import ctypes ... LTC = ctypes.CDLL('libtomcrypt.dylib') ... state = ctypes.c_buffer(LTC.sosemanuk_state_size()) replaces import ctypes ... LTC = ctypes.CDLL('libtomcrypt.dylib') ... def _get_size(name): size = ctypes.c_int(0) rc = LTC.crypt_get_size(bytes(name), byref(size)) if rc != 0: raise Exception('LTC.crypt_get_size(%s) rc = %d' % (name, rc)) return size.value ... state = ctypes.c_buffer(_get_size(b'sosemanuk_state'))

Salsa, XSalsa, and Sosemanuk were the first round. I submitted one for each of the other streams.

[sjaeckel]

1/ Things related to st->status

LGTM

2/ The _onecall stuff
...
I wasn't aware. I've adopted the *_memory() convention.

Perfect! Please create them in the appropriate folders as single files and not in a throw-in helper c-file

3/ Ad _state_size

please don't do this!

... also I don't see the disadvantage of using your _get_sizes() ... it's 6 lines of boilerplate in your python code vs. 3 lines of code in C + 1 new API function for each size you want to export like that ...

Now please split this PR up into 3 separate ones with the topics as proposed by Karel!

I'd do them in the order 4/ - 2/ - 1/ which is IMO the order of discussion-worthyness and therefore merged the fastest so we can go on.

[buggywhip]

#418 would be better if closed, subdivided into 4 smaller, better defined subtopics, and each resubmitted

[buggywhip]

Oops

[sjaeckel]

#418 would be better if closed, subdivided into 4 smaller, better defined subtopics, and each resubmitted

fine by me, please don't use weird characters in the branch names :D