-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Aloha!
I've thought about som algorithms and constructs that I think would be useful, good to add to Nettle.
We are seeing in an interest in using EC keys for both DH and DSA operations. Esp in embedded systems. One should be careful of reusing keys for more than one purpose. But for EC there seem to be some circumstances when using the keys for the two constructions does not harm each other, see:
“On the Joint Security of Encryption and Signature in EMV.” Cryptology ePrint Archive, Report 2011/615, 2011. http://eprint.iacr.org/2011/6
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. Openwhispersystems have also code for XEd25519 on Github. I've looked at it and compared to the Curve code in Nettle. It seems that we could add this algorithm with basically a small wrapper.
https://whispersystems.org/docs/specifications/xeddsa/xeddsa.pdf
https://github.com/WhisperSystems/curve25519-java/blob/master/android/jni/ed...
https://github.com/WhisperSystems/curve25519-java/blob/master/android/jni/ed...
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.
https://131002.net/siphash/ https://github.com/veorq/SipHash
When it comes to block cipher modes, CMAC and OCB are two modes that are very interesting for embedded space. CMAC is a "better CBC-MAC" that can be/is used as KDF, MAC etc.
http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
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.
https://www.rfc-editor.org/rfc/rfc7253.txt http://web.cs.ucdavis.edu/~rogaway/ocb/
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?
https://github.com/P-H-C/phc-winner-argon2
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.
- -- Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================
Joachim Strömbergson joachim@secworks.se writes:
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?
I have a personal fork of nettle with scrypt support. I should put it up somewhere for review and possible inclusion in Nettle. It is a clean-room implementation and I did not spend any time on optimization, so there is room for improvement but I think functionality is more important as a first step.
/Simon
This would be a great thing to have.
Nettle already contains PBKDF2, and having scrypt would be a really nice thing to have especially because there is no scrypt in practically any libs and no official library.
Then Nettle would only miss, as you said, Argon2, and bcrypt. If Nettle had all these, it would become the ultimate pasword hashing / key derivation lib, :-).
On Tue, 8 Nov 2016 at 10.26 Simon Josefsson simon@josefsson.org wrote:
Joachim Strömbergson joachim@secworks.se writes:
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?
I have a personal fork of nettle with scrypt support. I should put it up somewhere for review and possible inclusion in Nettle. It is a clean-room implementation and I did not spend any time on optimization, so there is room for improvement but I think functionality is more important as a first step.
/Simon _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Aloha!
Niels Möller wrote:
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.
I'm at least seeing several projects where the ability to have a single keypair is highly desirable.
...
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.
Yes, the versions are different. blake2b is focused on high performance, 64-bit systems. Blake2s is for 8- to 32-bit systems. Having blake2s would imho be a good addition to sha2- and sha3.
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.
With the exception of the new XEdDS, Argon2 and possibly OCB mode, I would say that the suggested additions I listed are not for obscure research algorithms, but algorithms that see concrete usage. And OCB is taking off. My focus in general is not research, but embedded industry usage and needs.
The XEDdsa is very new, but is used in OpenWhisperSystems, and as I've said before meets a concrete need. The XEdDSA brings is a concrete and well defined way to transform Curve-keys to allow usage for signing too.
CMAC is very much not a research modem but an establish NIST standard. CMAC is much better (harder to misuse) than CBC-MAC and is used in massively deployed protocols.
But hey, It¨s just suggestions. I intended to provide code, but only if there is an interest for it.
- -- Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ========================================================================
Joachim Strömbergson joachim@secworks.se writes:
I'm at least seeing several projects where the ability to have a single keypair is highly desirable.
You're making me curious, can you give some example? For private keys, it should be easy to derive as many as one needs from a single secret using something like hash(secret | counter).
But for the corresponding public keys, there's no obvious way to link them together, so maybe a single key is more beneficial in that end? As a simpler alternative than having a main key and a signed certificate for each additional public key used for different purposes.
With the exception of the new XEdDS, Argon2 and possibly OCB mode, I would say that the suggested additions I listed are not for obscure research algorithms, but algorithms that see concrete usage.
Sorry, I didn't mean to discourage you. I imagine you have a much better overview of what's used in practice than I have.
But hey, It¨s just suggestions. I intended to provide code, but only if there is an interest for it.
Your contributions, past and future, are much appreciated. The attempt at separating research from mainstream wasn't intended to be a high bar, but it makes it easier for me if a proposed algorithm addition is accompanied by one or two examples of applications or protocols using it (like you surely did, for some of your suggestions). And from the set of non-obscure algorithms, which it makes sense to support in Nettle, I'd try to prioritize those most widely used.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
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.
An --enable-foo approach seems useful to me. It is good to have well-integrated versions of algorithms available in the nettle repository, but there is a high cost to inflict them to every installation. Maybe if a --enable-foo approach was introduced, we could even reduce the number of algorithms that are enabled by default.
/Simon
nettle-bugs@lists.lysator.liu.se
-
Aapo Talvensaari -
Joachim Strömbergson -
nisse＠lysator.liu.se -
Simon Josefsson