Although Tim and Matthew already mentioned the main points, I'd like to
voice my concerns as well -- in particular because I think that this is
*not* a philosophical argument: Security must always be more important than
the supposedly correct semantics of a class or method.
If you tried the same t
On 4/03/2014, at 12:49 pm, Valerie (Yu-Ching) Peng
wrote:
>
> I view this more as a major vulnerability in BC provider than
> javax.crypto.CipherInputStream class and this should be reported to
> BouncyCastle so they can fix their provider code.
>
> If you tried the same test with SunJCE pro
On Mon, Mar 03, 2014 at 05:17:04PM -0800, Valerie (Yu-Ching) Peng wrote:
> *Moreover, this class catches all exceptions that are not thrown by
> its ancestor classes.*
Then it should be able to throw an AEAD exception wrapped in an IOException,
should it not?
Matthew.
Well, this is just my speculation. But I think the reason that
CipherInputStream swallows BadPaddingException is as its javadoc class
description had:
*This class adheres strictly to the semantics, especially the failure
semantics, of its ancestor classes java.io.FilterInputStream and
java.
It's fair to say that returning unchecked data is a provider problem, but we
should also try to find the explanation why the JRE swallows important
cryptographic exceptions, as that's not usually recommended practice in Java.
Matthew.
On Mon, Mar 03, 2014 at 03:49:49PM -0800, Valerie (Yu-Ching)
I view this more as a major vulnerability in BC provider than
javax.crypto.CipherInputStream class and this should be reported to
BouncyCastle so they can fix their provider code.
If you tried the same test with SunJCE provider, you will find that none
of the decrypted data is returned to th
Hello everyone,
I apologize if this is not the right place so ask/report this. Please
direct me to the correct place if it isn't.
I recently noticed that that the current javax.crypto.CipherInputStream
implementation in OpenJDK 6/7/8 is insecure when AEAD modes are used, e.g.
Cipher.getInstance("
On 3/3/14 5:38 AM, Sean Mullan wrote:
On 02/28/2014 02:56 PM, Jason Uh wrote:
Could I please get a review of this change?
Looks fine to me, but the priority should be higher if this requires a
backport to 7u. Also, the bug should be labeled with "8-na" and "9-na"
since this is not an issue in
Just as you see, webrev is ugly. Here is the export changeset:
http://cr.openjdk.java.net/~xuelei/8032473/update.export
"hg import" should work. From the changeset, we can see the content
changes in renames files.
Xuelei
On 3/3/2014 9:38 PM, Wang Weijun wrote:
> Hi Xuelei
>
> Yes it's quit
On 02/28/2014 02:56 PM, Jason Uh wrote:
Could I please get a review of this change?
Looks fine to me, but the priority should be higher if this requires a
backport to 7u. Also, the bug should be labeled with "8-na" and "9-na"
since this is not an issue in 8 and 9.
--Sean
Just a simple fi
Hi Xuelei
Yes it's quite difficult to read the actual webrev so instead I try to apply
jdk.patch to my repo and see what happens. The patch file cannot remove the old
files so I cannot be sure the cleanup is clean. Is it possible you recreate the
webrev with a changeset (instead of jdk.patch).
webrev: http://cr.openjdk.java.net/~xuelei/8032473/webrev.00/
On 3/3/2014 1:54 PM, Wang Weijun wrote:
> As Brad mentioned in the comment, do you need to update the test/TEST.groups
> file?
>
Yes.
> Although not friendly to read, you do have a webrev somewhere?
>
Just made it ready. Please rev
12 matches
Mail list logo
