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
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
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
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
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
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
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
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
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 #
