New cryptographic primitives

[Adam Petcher]

Hi Eric,

I don't immediately see anything in your list of implementations that we 
don't already have, and that we clearly need. But I would be interested 
in hearing from you or others about whether there is demand for these 
algorithms. The ones that are used in TLS 1.3 are valuable, but we 
already have implementations for all of them on your list.

Your implementations may be faster than the ones in the JDK, in which 
case we may want to incorporate them (or at least the techniques used). 
If you benchmark your implementations and see an improvement, then we 
can figure out how to proceed.

On 1/5/2019 8:50 AM, Eric McCorkle wrote:
> Hello,
>
> I've been out of the loop on OpenJDK development for some time, so I
> don't have an up-to-date knowledge on what cryptographic primitives have
> been added to the codebase recently, so forgive me if any of this is
> out-of-date.
>
> However, I understand there's been a move to add some more cryptographic
> primitives to the default JCA provider.  I've spent the last year or so
> working on my own implementations of various primitives within the
> context of my own JCA provider implementation, and if there's enough
> interest, I'd be glad to contribute them back to OpenJDK.
>
> My project code can be found here: https://github.com/dsiproject/krypton
>
> Prime field arithmetic is here:
> https://github.com/dsiproject/primefields-java
>
> Elliptic curve primitive ops are here:
> https://github.com/dsiproject/safecurves-java
>
>
> What I have so far are the following:
>
> * ChaCha family stream ciphers
> * Salsa family stream ciphers
> * HC-256 stream cipher (another eSTREAM finalist)
> * SHA-3 (keccak) hash function[0]
> * BLAKE2b hash function
> * RipeMD-160 hash function
>
> Each implementation includes a test suite taken from test vectors found
> in RFCs or papers.
>
> I also have efficient, constant-time (in the context of side-channels)
> prime field operations over the following prime fields:
>
> * 2^130 - 5
> * 2^221 - 3
> * 2^222 - 117
> * 2^251 - 9
> * 2^255 - 19
> * 2^382 - 105
> * 2^383 - 187
> * 2^414 - 17
> * 2^511 - 187
> * 2^521 - 1
>
> These implementations are based on pseudo-mersenne prime arithmetic,
> which allows for implementations that avoid timing, branching, and
> memory side-channels.  These implementations are thoroughly tested and
> documented.
>
> The field 2^130 - 5 corresponds to the Poly1305 MAC, and could be used
> in an implementation of that MAC (I've intended to do this, but haven't
> gotten to it yet).
>
> The remainder correspond to the following elliptic curves, all of which
> meet the criteria in the safecurves paper (see
> https://safecurves.cr.yp.to/):
>
> * M-221
> * E-222
> * Curve1174
> * Curve25519
> * E-382
> * M-383
> * Curve41417
> * M-511
> * E-521
>
> I have implementations of elliptic curve group operations for these
> curves.  The basic group operations are based on Edwards curve
> arithmetic (under the birationally-equivalent Edwards curves for M-221,
> Curve25519, M-383, and M-511).  Group multiplication is accomplished
> using the single-coordinate Montgomery ladder (under the
> birationally-equivalent Montgomery curves for E-222, Curve1174, E-382,
> Curve41417, and E-521), followed by a y-coordinate recovery step.  The
> single-coordinate ladder is also available, as this can be used to
> implement ECDH directly.
>
> These implementations are also free of timing, branching, and memory
> side-channels, and the implementations are also thoroughly tested and
> documented.
>
> Additionally, I provide implementations of the Elligator hash functions
> for all curves.  For cofactor-4 curves (E-222, Curve1174, E-382, E-521),
> I provide subclasses that use Mike Hamburg's Decaf point compression
> technique[1, 2], which reduces the cofactor to 1.
>
> I do not have JCA providers for these curves, but it should be fairly
> straightforward to implement them (especially for ECDH, as I have a
> stress-test for that in the elliptic curve test suite)
>
>
> All of this is tested and working. I have plans to implement the
> following at some point, but haven't gotten to it:
>
> * Whirlpool hash
> * Skein hash (and the corresponding Threefish block cipher)
> * Poly1305 MAC
> * Twofish/Threefish block cipher (some work on threefish)
> * Serpent block cipher (some work on this)
> * SIDH, a post-quantum key agreement protocol
> * XMSS, a post-quantum stateful signing scheme
> * SPHINCS, a post-quantum stateless signing scheme
> * Some key derivation functions as hashes (particularly scrypt)
>
>
> So if there's any interest in the work I've done, I'd be happy to
> contribute any part of it back.  Additionally, if there's interest in
> the work I've planned but haven't done, I'd be happy to collaborate with
> anyone to see it through.
>
>
> [0]: I have not implemented the weaker SHAKE variants, but that
> shouldn't be hard to do.
>
> [1]: Hamburg also describes a Montgomery ladder variant that works
> directly on Decaf-compressed points.  I've got that mostly working, but
> there's a technique that's necessary to decode the final ladder, which
> the paper glosses over, which I haven't been able to get working in all
> cases.
>
> [2]: Henry de Valence has some work from the last year which describes a
> technique called Ristretto, which eliminates cofactors as high as 8.
> I've intended to try implementing this for the cofactor-8 curves (M-221,
> Curve25519, M-383, Curve41417, M-511) as soon as I get the Decaf
> formulas working.
>