Re: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations
Hi Bernd, thank you for the feedback!
On 01/25/2018 12:30 PM, Bernd Eckenfels wrote:
You Hello,
The spec should most likely mention AAD data as well and the 12 Byte
size of the nonce. And that the plaintext Limit is in blocks (and the
AAD Limit is a 64Bit counter)
Good point about AAD. My code currently doesn't check to make sure the
total AAD from each AAD update doesn't overflow the 64-bit length. It
definitely needs to and can be done pretty easily. Thanks for pointing
that out.
In terms of nonce length checking, I'll have to handle it multiple
ways. For ChaCha20ParameterSpec, I can check it in the constructor and
that's easy to do. Because ChaCha20-Poly1305 will use IvParameterSpec,
a check will need to be done in the init call. If I handle it there I
could avoid it in the ChaCha20ParameterSpec too, but it seems better to
report an error sooner rather than later and I don't think it hurts to
have the check in both places.
I will probably also need a similar check in ChaCha20Parameters when
AP.init() is called with whatever encoding we're going with.
(And yes there is no wrapping to be found, not even in RFC 8103 which
discusses key transport,)
Thanks for confirming our suspicions so far.
Does it need to define what AP.getEncoded() format/OID looks like?
Let me work backward from your two points:
Are you referring to the use of an OID instead of a name for use with
AP.getInstance()? If so I'll need to look that up, but I agree that it
needs to be called out in the specification. Thank you for pointing
that out.
Should we call out the encoding format?
It should. I would expect the output for ChaCha20-Poly1305 to just be a
DER-encoded OCTET STRING, so it would look something like
0x04 0x0C [insert 12 bytes here]
ChaCha20 is the one that concerns me, because I see no standardized
encoding. There are other algs that do SEQUENCES of octet strings and
integers in varying orders, but of course the meanings of those differ.
The ASN.1 that I'm currently encoding (because I wanted *something*) is:
SEQUENCE {
OCTET STRING (12 byte nonce)
INTEGER (initial counter value)
}
What worries me a bit is what alg name to assign to it in the standard
names document. If I call it "ChaCha20" and then some standardized
format is developed, then we have a potential conflict down the line as
we make our AP conform to the new standard. If I come up with another
name (call it "FooFoo20" as a placeholder), then getEncoded("FooFoo20")
could continue to provide that encoding into the future and leave room
for a standardized encoding with the name "ChaCha20". But what of the
default? Without a standardized format, does FooFoo20 become the
default? And when the standardized version becomes real then the
default probably should change to ChaCha20's encoding and we have
another behavioral change there. Neither of those alternatives really
sit well with me. I admit I don't have a good answer yet on this one.
--Jamil
Gruss
Bernd
--
http://bernd.eckenfels.net
_
From: Jamil Nimeh
Sent: Donnerstag, Januar 25, 2018 6:31 PM
Subject: Proposal: ChaCha20 and ChaCha20-Poly1305 Cipher implementations
To: OpenJDK Dev list
Hello all,
This is a proposal to introduce the ChaCha20 and ChaCha20-Poly1305
cipher implementations into JDK. At a high level, the plan is to
include both ChaCha20-Poly1305 and the base ChaCha20 stream cipher
into JDK as part of the SunJCE provider initially, and then add TLS
cipher suites as a follow-on feature.
Both algorithms will be CipherSpi implementations and will generally
conform to the details of that API. I will discuss below some of the
details such as which flavors of init are supported, etc.
* Instantiation
o For ChaCha20 and ChaCha20-Poly1305, the simple name will
suffice: either "ChaCha20" for the basic stream cipher or
"ChaCha20-Poly1305" for AEAD mode will work. You may however
use the 3-element transform "ChaCha20/None/NoPadding" and
"ChaCha20-Poly1305/None/NoPadding". Any other type of
transformation string will cause NoSuchAlgorithmException to
be thrown.
* Initialization
o All three engineInit methods in the CipherSpi API will be
supported. Keys provided through the various Cipher init
methods should have the algorithm String "ChaCha20" applied to
it (case-insensitive).
o For init/engineInit methods that take an
AlgorithmParameterSpec, ChaCha20 and ChaCha20-Poly1305 use
different APS classes.
+ ChaCha20 will have a new ChaCha20ParameterSpec which takes
a nonce (byte[]) and a counter (int). This class will
have getter methods to return those values if desired
(getNonce() and getBlockCounter(), respectively).
+ ChaCha20-Poly1305 will use IvParameterSpec to
Re: Update mechanism for the upcoming trust store
On 1/24/18 5:39 AM, Fotis Loukos wrote: You may not be aware, but the JDK does currently support a mechanism for blacklisting certificates. The lib/security/blacklisted.certs file contains a list of the fingerprints of certificates that are explicitly distrusted. If a root was compromised and added to this file it would no longer be trusted. My biggest concern is what you describe below, the dynamic update. However, currently there is no mechanism in OpenJDK to dynamically update that file. While I think there is merit in implementing something like that, many challenges would need to be addressed as part of that, for example, where and how does this file get updated, how is it verified, etc. The verification step can be implemented as described above. I think that the update step requires some design, but I don't think it is that difficult. For example, a naive algorithm such as every Monday plus a random number of days/hours/minutes in order to avoid heavy traffic during the update period would be good for starters. As a first step to try a new format, you could even fetch it once during installation and provide a means for the user to update it manually. One thing we could potentially do initially is to provide a stable https URL where an updated blacklist could be downloaded, something like what Mozilla does for OneCRL [1]. This would be an initial step, not the whole solution of course, but it at least would allow someone to quickly update their JDK should a certificate need to be distrusted ASAP. Let me look into that a bit. I think implementing a dynamic solution is more challenging and would require more design/review, etc but feel free to provide more details on any additional thoughts or design sketches you might have. --Sean [1] https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records
RFR 8181594: Efficient and constant-time modular arithmetic
JBS: https://bugs.openjdk.java.net/browse/JDK-8181594
Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/
This is a code review for the field arithmetic that will be used in
implementations of X25519/X448 key agreement, the Poly1305
authenticator, and EdDSA signatures. I believe that the library has all
the features necessary for X25519/X448 and Poly1305, and I expect at
most a couple of minor enhancements will be required to support EdDSA.
There is no public API for this library, so we can change it in the
future to suit the needs of new algorithms without breaking
compatibility with external code. Still, I made an attempt to clearly
structure and document the (internal) API, and I want to make sure it is
understandable and easy to use.
This is not a general-purpose modular arithmetic library. It will only
work well in circumstances where the sequence of operations is
restricted, and where the prime that defines the field has some useful
structure. Moreover, each new field will require some field-specific
code that takes into account the structure of the prime and the way the
field is used in the application. The initial implementation includes a
field for Poly1305 and the fields for X25519/X448 which should also work
for EdDSA.
The benefits of using this library are that it is much more efficient
than using similar operations in BigInteger. Also, many operations are
branch-free, making them suitable for use in a side-channel resistant
implementation that does not branch on secrets.
To provide some context, I have attached a code snippet describing how
this library can be used. The snippet is the constant-time Montgomery
ladder from my X25519/X448 implementation, which I expect to be out for
review soon. X25519/X448 only uses standard arithmetic operations, and
the more unusual features (e.g. add modulo a power of 2) are needed by
Poly1305.
The field arithmetic (for all fields) is implemented using a 32-bit
representation similar to the one described in the Ed448 paper[1] (in
the "Implementation on 32-bit platforms" section). Though my
implementation uses signed limbs, and grade-school multiplication
instead of Karatsuba. The argument for correctness is essentially the
same for all three fields: the magnitude of each 64-bit limb is at most
2^(k-1) after reduction, except for the last limb which may have a
magnitude of up to 2^k. The values of k are between 26 to 28 (depending
on the field), and we can calculate that the maximum magnitude for any
limb during an add-multiply-carry-reduce sequence is always less than
2^63. Therefore, no overflow occurs and all operations are correct.
Process note: this enhancement is part of JEP 324 (Key Agreement with
Curve25519 and Curve448). When this code review is complete, nothing
will happen until all other work for this JEP is complete, and the JEP
is accepted as part of some release. This means that this code will be
pushed to the repo along with the X25519/X448 code that uses it.
[1] https://eprint.iacr.org/2015/625.pdf
private IntegerModuloP_Base pointMultiply(byte[] k, IntegerModuloP u){
IntegerModuloP x_1 = u;
MutableIntegerModuloP x_2 = one.mutable();
MutableIntegerModuloP z_2 = zero.mutable();
MutableIntegerModuloP x_3 = u.mutable();
MutableIntegerModuloP z_3 = one.mutable();
int swap = 0;
// Variables below are reused to avoid unnecessary allocation
// They will be assigned in the loop, so initial value doesn't matter
MutableIntegerModuloP m1 = zero.mutable();
MutableIntegerModuloP DA = zero.mutable();
MutableIntegerModuloP E = zero.mutable();
MutableIntegerModuloP a24_times_E = zero.mutable();
for(int t = params.getBits() - 1; t >= 0; t--){
int k_t = bitAt(k, t);
swap = swap ^ k_t;
x_2.conditionalSwapWith(x_3, swap);
z_2.conditionalSwapWith(z_3, swap);
swap = k_t;
// A(m1) = x_2 + z_2
m1.setValue(x_2).setSum(z_2);
// D = x_3 - z_3
// DA = D * A(m1)
DA.setValue(x_3).setDifference(z_3).setProduct(m1);
// AA(m1) = A(m1)^2
m1.setSquare();
// B(x_2) = x_2 - z_2
x_2.setDifference(z_2);
// C = x_3 + z_3
// CB(x_3) = C * B(x_2)
x_3.setSum(z_3).setProduct(x_2);
// BB(x_2) = B^2
x_2.setSquare();
// E = AA(m1) - BB(x_2)
E.setValue(m1).setDifference(x_2);
// compute a24 * E using SmallValue
a24_times_E.setValue(E);
a24_times_E.setProduct(a24);
// assign results to x_3, z_3, x_2, z_2
// x_2 = AA(m1) * BB
x_2.setProduct(m1);
// z_2 = E * (AA(m1) + a24 * E)
z_2.setValue(m1).setSum(a24_times_E).setProduct(E);
// z_3 = x_1*(DA - CB(x_3))^2
