Joachim Strömbergson joachim@secworks.se writes:
Recently, Trevor Perrin from Openwhispersystems wrote a paper that describes how given a Curve25519 (or Curve448) keypair can reuse them in a specific DSA construction called XEdDSA. The XEdDSA is in fact a way to convert the Curve-keys in a specific way and then use them with Ed25519, Ed448 to sign or verify messages.
I haven't read the paper, but I guess it's just a change of coordinates, the same or the inverse of what's done in curve25519_mul_g? Which uses the Edwards curve representation for speed and to reuse precomputed tables. If so, should be quite easy.
Not sure why key reuse is desirable, though, since curve25519 keys are both small and cheap to generate.
Another algorithm that I've seen been used in embedded space is the SipHash PRF/keyed hash function. It is very fast on Cortex-M devices and have low code and RAM resource requirements. If implemented in Nettle I think we should support both 64 and 128 bit digests.
This is new to me. Also the keyed-hash mode of skein looks like it can be pretty fast and use little RAM.
OCB is an aead construction that has seen little used until now due to licensing issues. But the licensing has been changed by Rogaway et al and there is a RFC for OCB. The cost for OCB goes asymptotically towards one cipher block operation/message block.
OCB is definitely an interesting construction, it's more or less the only reasonable aead I'm aware of which isn't a cipher + separate mac + new packaging.
CMAC, I don't know.
OFB have also been requested in the past, not because it's technically better than other modes, but because it's in real use.
I don't know what the idea is in relation to password hashing, memory/computational hard functions. PBKDF2 is in Nettle, but not bcrypt, scrypt or the PHC winner Argon2. Are there any interest in adding them to Nettle?
Maybe. The main feature of scrypt is to make hardware accelleration expensive. Which makes sense to me. What are the features of the others? Unlike most other constructions, speed isn't really a desirable feature... And for embedded systems, it makes a lot of sense to reuse some primitive which is already used for other purposes.
Finally. Since Skein was being developed, how about adding blake2? Blake2 was one of the runner ups for SHA-3 and is faster than Keccak. There is also versions of Blake2 suitable for embedded systems.
Last time I looked at blake2, it seemed there were so into high performance, that they had defined multiple incompatible versions intended for different machines. Which put me off a bit. But if there's an agreed upon general-purpose version of blake2, that would make more sense.
I'm also not sure how to deal with research and Nettle. On one hand, it's nice if people use Nettle as a base for implementing new algorithms, and that makes it easier to integrate code once a new algorithm matures. But on the other hand, for a practical library, it's not really useful to include dozens of obscure algorithms and research projects. And supported algorithms also need documentation, which has a cost both to writing and reading. A compromise might be an --enable-experimental configure flag to include unsupported algorithms for research and evaluation purposes? Or some recommended practices for forking and extending Nettle.
Regards, /Niels