SHAKE XOFs

[Bernd Eckenfels]

Hello,

I noticed that the OASIS draft for extending PKCS#11 with SHA-3 also specifies 
new Mechanisms for SHAKE128/256. They introduce them as Key Derivation 
functions.

I wonder if this would also be the way to introduce this into JCA, at the 
moment XOFs have been a non-goal of JEP287, but there is some use for them In 
modern protocols I would guess. (This request was inspired by a discussion  on 
the bouncycastle crypto-dev mailing list about missing algorithms for it).

Gruss
Bernd
--
http://bernd.eckenfels.net

Re: SHAKE XOFs

[Adam Petcher]

On 4/11/2018 5:37 AM, Bernd Eckenfels wrote:


Hello,

I noticed that the OASIS draft for extending PKCS#11 with SHA-3 also 
specifies new Mechanisms for SHAKE128/256. They introduce them as Key 
Derivation functions.


Interesting. Though to be pedantic, it looks like they introduce key 
derivation mechanisms that are based on SHAKE128/256.




I wonder if this would also be the way to introduce this into JCA, at 
the moment XOFs have been a non-goal of JEP287, but there is some use 
for them In modern protocols I would guess. (This request was inspired 
by a discussion  on the bouncycastle crypto-dev mailing list about 
missing algorithms for it).


Continuing the pedantry, it would be reasonable to put these 
SHAKE128/256-based-KDFs under the KDF API (once that API exists). But 
the underlying SHAKE XOFs probably belong in a different API like 
MessageDigest or a new API that is more appropriate for XOFs. I expect 
that adding the XOFs to the API will be non-trivial because we don't 
have an obviously good place to put them. I think it would be fine to 
put them in MessageDigest, but we would need a way to specify the output 
length.


We will need SHAKE256 for Ed448[1], but my initial thought was to do a 
private implementation, because I don't know if these functions are 
useful enough to justify the effort of the API design. Maybe we can make 
an API for them as a separate effort.


It's also worth noting that the (bare) XOFs are not very good KDFs 
because they allow key extraction through related output attacks.


[1] https://bugs.openjdk.java.net/browse/JDK-8187789

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

[Jamil Nimeh]

Yes, that does appear to be the case, good catch!  I'll make that change.

--Jamil

On 4/11/2018 7:18 AM, Thomas Lußnig wrote:

Hi,

i found another point. The "key" field can be removed from 
ChaCha20Cipher.

1) This field is only set once and later checked if it was initialized.
 But we do not want to knew is the key exists but if key bytes 
exists.
2) So if two lines are changed from key to keyBytes we can remove this 
unused field.



Gruß Thomas

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html 


Lines 426 , 461 (change to keyBytes)
    if (key == null
Line 75+507 (remove)
    private Key key;
    this.key = key;


On 4/11/2018 12:34 AM, Jamil Nimeh wrote:

Hello everyone,

This is a quick update to the previous webrev:

* When using the form of engineInit that does only takes op, key and 
random, the nonce will always be random even if the random parameter 
is null.  A default instance of SecureRandom will be used to create 
the nonce in this case, instead of all zeroes.


* Unused debug code was removed from the ChaCha20Cipher.java file

* ChaCha20Parameters.engineToString no longer obtains the line 
separator from a System property directly.  It calls 
System.lineSeparator() similar to how other AlgorithmParameter 
classes in com.sun.crypto.provider do it.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/

Thanks,

--Jamil


On 03/26/2018 12:08 PM, Jamil Nimeh wrote:

Hello all,

This is a request for review for the ChaCha20 and ChaCha20-Poly1305 
cipher implementations.  Links to the webrev and the JEP which 
outlines the characteristics and behavior of the ciphers are listed 
below.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
http://openjdk.java.net/jeps/329

Thanks,
--Jamil

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

[Jamil Nimeh]

Okay, I will check that out and fix as appropriate.  Thanks for the 
comments!


--Jamil

On 4/11/2018 10:56 AM, Thomas Lußnig wrote:

Hi,

same with key/keyBytes is with the class Poly1305 also here the key is 
not used.


Gruß Thomas

On 4/11/2018 5:54 PM, Jamil Nimeh wrote:
Yes, that does appear to be the case, good catch!  I'll make that 
change.


--Jamil

On 4/11/2018 7:18 AM, Thomas Lußnig wrote:

Hi,

i found another point. The "key" field can be removed from 
ChaCha20Cipher.

1) This field is only set once and later checked if it was initialized.
 But we do not want to knew is the key exists but if key bytes 
exists.
2) So if two lines are changed from key to keyBytes we can remove 
this unused field.



Gruß Thomas

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html 


Lines 426 , 461 (change to keyBytes)
    if (key == null
Line 75+507 (remove)
    private Key key;
    this.key = key;


On 4/11/2018 12:34 AM, Jamil Nimeh wrote:

Hello everyone,

This is a quick update to the previous webrev:

* When using the form of engineInit that does only takes op, key 
and random, the nonce will always be random even if the random 
parameter is null.  A default instance of SecureRandom will be used 
to create the nonce in this case, instead of all zeroes.


* Unused debug code was removed from the ChaCha20Cipher.java file

* ChaCha20Parameters.engineToString no longer obtains the line 
separator from a System property directly.  It calls 
System.lineSeparator() similar to how other AlgorithmParameter 
classes in com.sun.crypto.provider do it.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/

Thanks,

--Jamil


On 03/26/2018 12:08 PM, Jamil Nimeh wrote:

Hello all,

This is a request for review for the ChaCha20 and 
ChaCha20-Poly1305 cipher implementations.  Links to the webrev and 
the JEP which outlines the characteristics and behavior of the 
ciphers are listed below.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
http://openjdk.java.net/jeps/329

Thanks,
--Jamil

RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

[Jack Ottofaro]

Hi Valerie,

I have an important customer awaiting this change. Can you please provide a
status update as to the progress of this effort and any information
available as to when it may be completed.

Thanks,

Jack

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

[Thomas Lußnig]

Hi,

i found another point. The "key" field can be removed from ChaCha20Cipher.
1) This field is only set once and later checked if it was initialized.
 But we do not want to knew is the key exists but if key bytes exists.
2) So if two lines are changed from key to keyBytes we can remove this 
unused field.



Gruß Thomas

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html
Lines 426 , 461 (change to keyBytes)
    if (key == null
Line 75+507 (remove)
    private Key key;
    this.key = key;


On 4/11/2018 12:34 AM, Jamil Nimeh wrote:

Hello everyone,

This is a quick update to the previous webrev:

* When using the form of engineInit that does only takes op, key and 
random, the nonce will always be random even if the random parameter 
is null.  A default instance of SecureRandom will be used to create 
the nonce in this case, instead of all zeroes.


* Unused debug code was removed from the ChaCha20Cipher.java file

* ChaCha20Parameters.engineToString no longer obtains the line 
separator from a System property directly.  It calls 
System.lineSeparator() similar to how other AlgorithmParameter classes 
in com.sun.crypto.provider do it.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/

Thanks,

--Jamil


On 03/26/2018 12:08 PM, Jamil Nimeh wrote:

Hello all,

This is a request for review for the ChaCha20 and ChaCha20-Poly1305 
cipher implementations.  Links to the webrev and the JEP which 
outlines the characteristics and behavior of the ciphers are listed 
below.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
http://openjdk.java.net/jeps/329

Thanks,
--Jamil

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

[Thomas Lußnig]

Hi,

ok that is an good point that if we have more values in the structure 
than we use this can make some confusion.
I was only looking from the coding point of view and saw that if i can 
use the same structure for booth cases this

can reduce the coding overhead. But i can fully understand your point.

Gruß Thomas

On 4/10/2018 11:37 PM, Jamil Nimeh wrote:

Hello Thomas, et al.,

On 3/26/2018 1:49 PM, Jamil Nimeh wrote:

Hi Thomas, thanks for the feedback

 1. Were there guidelines?  Not really, though I looked at other
parameter definitions in com.sun.crypto.provider and tried to
follow along the same lines that they do.  One thing that should
be changed is the LINE_SEP assignment shouldn't be an explicit
getProperty call.  I noticed most are doing
System.lineSeparator() so I'll change my implementation to match
that.  None of these params appear to stringify as json, so I'll
probably keep things consistent with the other parameter output.
 2. You make a fair point with respect to a null SecureRandom.  I can
make that spec change.
 3. Let me think on this one - I shied away from
ChaCha20ParameterSpec for AEAD mode only because you have this
nonce field that is set but gets ignored.  But making
ChaCha20ParameterSpec an IvParameterSpec potentially runs into
the same issue were it used for a ChaCha20-Poly1305 cipher.  If I
had to choose between the two I think I'd go with allowing
ChaCha20ParameterSpec to be used with CC20-P1305 rather than
making it a subclass of IvParameterSpec.  Doing the former helps
from a type safety perspective that you couldn't use a
ChaCha20ParameterSpec with other Ciphers that require an
IvParameterSpec.  I know I had some discussions early on in the
design where we talked about this, I need to refresh my memory as
to why we didn't allow it.

Finally getting back to #3.  Took me a while to find early discussions 
on this.  The primary objection to ChaCha20ParameterSpec being used 
with ChaCha20-Poly1305 (as opposed to plain old ChaCha20) has to do 
with the configurable block counter.  You have this parameter that is 
not used, and consumption of this type of AlgorithmParameterSpec then 
leaves it to documentation to define what happens (is it ignored?  
Used despite what the spec says?  Set to some default value regardless 
of what the caller sets there?).  Using IvParameterSpec with 
ChaCha20-Poly1305 is more clear because it only allows the caller what 
they need to get CC20/P1305 going, the nonce.  Respectfully, I would 
like to keep this as-is.


--Jamil


On 3/26/2018 12:45 PM, Thomas Lußnig wrote:


Hi Jamil,

1) where there any guidelines about how the engineToString should be 
formatted ?
I ask because i wondering why we need two new lines with access to 
the System property.
If it is represented as single line json no need to line break would 
be needed.


Gruß Thomas


/** * Creates a formatted string describing the parameters. * * 
@return a string representation of the ChaCha20 parameters. */ 
@Override protected String engineToString() { String LINE_SEP = 
System.getProperty("line.separator"); HexDumpEncoder encoder = new 
HexDumpEncoder(); StringBuilder sb = new StringBuilder(LINE_SEP + 
"nonce:" + LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]"); 
return sb.toString(); }

2) I do not think it is an good idea to say no secureRandom=null will cause IV 
to be null.
I see here the risk of weak implementations. I would suggest to throw an 
Exception to
enforce secure usages. If someone really want an insecure IV he can provide 
am SecureRandom
implementation retuning 0 only or an matching IV.

  * @param random a {@code SecureRandom} implementation.  If {@code null}
  *  is used for the random object, then a nonce consisting of all
  *  zero bytes will be used.  Otherwise a random nonce will be
  *  used.

3) If ChaCha20ParameterSpec would extends IvParameterSpec if would be valid for 
booth modes in engineInit.
 Even if the counter is not needed.
 As an alternative i would allow ChaCha20ParameterSpec also for AEAD mode.

Grup Thomas
On 3/26/2018 9:08 PM, Jamil Nimeh wrote:

Hello all,

This is a request for review for the ChaCha20 and ChaCha20-Poly1305 
cipher implementations.  Links to the webrev and the JEP which 
outlines the characteristics and behavior of the ciphers are listed 
below.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
http://openjdk.java.net/jeps/329

Thanks,
--Jamil

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

[Thomas Lußnig]

Hi,

same with key/keyBytes is with the class Poly1305 also here the key is 
not used.


Gruß Thomas

On 4/11/2018 5:54 PM, Jamil Nimeh wrote:

Yes, that does appear to be the case, good catch!  I'll make that change.

--Jamil

On 4/11/2018 7:18 AM, Thomas Lußnig wrote:

Hi,

i found another point. The "key" field can be removed from 
ChaCha20Cipher.

1) This field is only set once and later checked if it was initialized.
 But we do not want to knew is the key exists but if key bytes 
exists.
2) So if two lines are changed from key to keyBytes we can remove 
this unused field.



Gruß Thomas

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html 


Lines 426 , 461 (change to keyBytes)
    if (key == null
Line 75+507 (remove)
    private Key key;
    this.key = key;


On 4/11/2018 12:34 AM, Jamil Nimeh wrote:

Hello everyone,

This is a quick update to the previous webrev:

* When using the form of engineInit that does only takes op, key and 
random, the nonce will always be random even if the random parameter 
is null.  A default instance of SecureRandom will be used to create 
the nonce in this case, instead of all zeroes.


* Unused debug code was removed from the ChaCha20Cipher.java file

* ChaCha20Parameters.engineToString no longer obtains the line 
separator from a System property directly.  It calls 
System.lineSeparator() similar to how other AlgorithmParameter 
classes in com.sun.crypto.provider do it.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/

Thanks,

--Jamil


On 03/26/2018 12:08 PM, Jamil Nimeh wrote:

Hello all,

This is a request for review for the ChaCha20 and ChaCha20-Poly1305 
cipher implementations.  Links to the webrev and the JEP which 
outlines the characteristics and behavior of the ciphers are listed 
below.


http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
http://openjdk.java.net/jeps/329

Thanks,
--Jamil

Re: RFR 8200468: Port the native GSS-API bridge to Windows

[Weijun Wang]

Hi Valerie

I updated the webrev at

  http://cr.openjdk.java.net/~weijun/8200468/webrev.01/

The only change is that I prepend "GSS_DLLIMP" to all gss_* functions in 
gssapi.h. The file has the following lines

 283 #if defined (_WIN32) && defined (_MSC_VER)
 284 # ifdef GSS_DLL_FILE
 285 #  define GSS_DLLIMP __declspec(dllexport)
 286 # else
 287 #  define GSS_DLLIMP __declspec(dllimport)
 288 # endif
 289 #else
 290 # define GSS_DLLIMP
 291 #endif

I added it so the exact same header file can be used to write a native GSS-API 
library which would export these functions.

Is this OK? Tests run fine with both MIT krb5 and Heimdal libraries.

Thanks
Max


> On Apr 4, 2018, at 10:19 AM, Weijun Wang  wrote:
> 
> Hi All
> 
> Please take a review at
> 
>  http://cr.openjdk.java.net/~weijun/8200468/webrev.00/
> 
> Like in *nix, native GSS-API bridge is turned on by setting 
> -Dsun.security.jgss.native=true. Please note there is no default native 
> GSS-API library on Windows and you need to supply your own, like this:
> 
> java -Dsun.security.jgss.native=true 
> -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ...
> 
> You can manually test the change with
> 
> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll 
> test/jdk/sun/security/krb5/auto/BasicProc.java
> 
> Thanks
> Max
> 
> p.s. You can get a gssapi64.dll from 
> https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html.