Hi again,
> That implies multiple threads using 1 selector ...
It definitely looks like we are talking about different things. You seem to
be talking about *how to use a Selector and encrypt/decrypt ssl and do it
in an efficient way in order to build some server or so*. I am talking
about *provid
Hi Tony,
Source change looks fine.
For the regression test GCMLargeDataKAT.java
1) typo on line 42, "has" -> "hash".
2) Line 128, we should also check result.length to be the expected
value, i.e. data.length - GCM_TAG_LENGTH.
3) Currently, the test continues even if enc check failed (line149-15
I am not clear on what would „preferred in current default context“ mean. Does
that mean it preferred the PFS ciphers anyway.. for suggested order in client
handshake? as server? And what would be the non-Default context. Is this „TLS“
context?
Gruss
Bernd
--
http://bernd.eckenfels.net
___
Hi
Can I get a review of a simple fix to the previous GCM change that got
the lengths wrong on large data sizes. I thought I covered this in my
original testing, but I guess not. So with this I created a test to
check larger data sizes and different byte lengths
http://cr.openjdk.java.net/
On 3/6/19 4:55 AM, Severin Gehwolf wrote:
On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04.
Is there any reason why JDK-8214418 is not public?
"You can't view this issue"
There are internal hostnames
Hi Xuelei,
In the Specification section, I think it would be useful to note which
cipher suites are forward secret and which are not. Otherwise, it is
difficult to see what has changed, since there are so many supported
suites. Perhaps in parentheses, ex:
TLS_AES_128_GCM_SHA256 (forward secr
On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
> It looks like this is JDK-8214418 - which has been fixed
> in 12.0.1 b03 and 13-ea b04.
Is there any reason why JDK-8214418 is not public?
"You can't view this issue"
Thanks,
Severin
