I would like to submit AES-GCM optimization for x86_64 architectures supporting
AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH
operations.
Performance gain of ~1.5x - 2x for message sizes 8k and above.
-
Commit messages:
- Merge master
- JDK-8267125: AES
> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher
> transformation.
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed
> to KeyWrapCipher
On Thu, 13 May 2021 23:53:18 GMT, Valerie Peng wrote:
>> Anyone can help review this somewhat trivial fix? The main change is inside
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
>> help better troubleshooting by reporting the type of unavailable attributes
>> i
> Anyone can help review this somewhat trivial fix? The main change is inside
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
> help better troubleshooting by reporting the type of unavailable attributes
> in PKCS11 exception message when C_GetAttributeValue(...) cal
I also think good developers will add these security features.
The problem is that Permissions are currently used to regulate access
control because this is how we've been told it should be done for over
20 years.
Now maybe people aren't using the Java FilePolicy provider (for reasons
stated
On Wed, 12 May 2021 21:58:13 GMT, Valerie Peng wrote:
>> Anyone can help review this somewhat trivial fix? The main change is inside
>> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to
>> help better troubleshooting by reporting the type of unavailable attributes
>> i
On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the following test code reviewed?
>
> The test SSLEngineExplorerMatchedSNI.java fails intermittently. I tried to
> run the test 500 times, but cannot reproduce the issue. The cause is unknown
> to me now. It wo
On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the following test code reviewed?
>
> The test SSLEngineExplorerMatchedSNI.java fails intermittently. I tried to
> run the test 500 times, but cannot reproduce the issue. The cause is unknown
> to me now. It wo
> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher
> transformation.
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed
> to KeyWrapCipher
On 5/12/21 5:41 PM, Peter Tribble wrote:
Let me give a concrete example:
Parsing and rendering a PDF file that may contain references to fonts or
other resources.
We know exactly where the files are installed, so wish to allow the
rendering routine access
to the fonts it will need. But not
Just to add another point to this. Today it is quite hard to use operating
system facilities like chroot/jails, security tokens, seteuid, dropping
priveledges or switching Security tokens which would allow to limit or escalate
priveledges in an OS enforced manor. If we would have a bit more supp
On 5/13/21 6:00 AM, Ron Pressler wrote:
On 13 May 2021, at 10:32, Peter Firmstone wrote:
So it targets 17.
I don’t know. I think that’s still TBD, but perhaps others know more.
At this point, yes, we are planning to target the JEP to JDK 17.
It would be nice to have certainty about
> This PR contains the API and implementation changes for JEP-412 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/412
Maurizio Cimadamore has updated the pull request
On Thu, 13 May 2021 10:52:35 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjd
On Tue, 4 May 2021 15:12:39 GMT, Fernando Guallini
wrote:
> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior
> when a server closes the socket connection during a handshake. The server was
> waiting a fixed 100ms before closing it, but there was no guarantee that the
> This PR contains the API and implementation changes for JEP-412 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/412
Maurizio Cimadamore has updated the pull request
> On 13 May 2021, at 03:11, David Black wrote:
>
>
> This seems somewhat more useful than 1 & 2 but imho it would be better to be
> able to perform checks/grant access on a call stack basis.
This is an important point we’re trying to get across. The very reason the
Security Manager was made
> On 13 May 2021, at 10:32, Peter Firmstone wrote:
>
> So it targets 17.
I don’t know. I think that’s still TBD, but perhaps others know more.
>
> It would be nice to have certainty about which release it will be removed
> from, for planning purposes. Again it would seem that this isn't a
On Mon, 10 May 2021 11:00:34 GMT, Julia Boes wrote:
> @fguallini I'm happy to sponsor this change once it's been reviewed by
> someone from security.
Thank you for sponsoring!. Rajan has reviewed the PR, it should be ready for
integration.
-
PR: https://git.openjdk.java.net/jdk/pu
So it targets 17.
Java 8 has planned support to 2030, longer than 17, it seems unlikely
the SecurityManager will still be present in an LTS release later than
17, given that 11 was the last, maybe 23 will be the next LTS version.
Of course these aren't OpenJDK considerations, maybe someone wi
> This PR contains the API and implementation changes for JEP-412 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/412
Maurizio Cimadamore has updated the pull request
Whatever version JEP 411 targets, it will *not* remove the Security Manager.
Even
if 411 targets 17, the Security Manager will still be in 17, precisely because
of the deprecation policy intended to give people time to adjust.
— Ron
> On 13 May 2021, at 01:44, Peter Firmstone wrote:
>
> Ron,
On Wed, May 12, 2021 at 10:49 PM Ron Pressler
wrote:
>
> > On 12 May 2021, at 22:41, Peter Tribble wrote:
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are installed,
23 matches
Mail list logo
