AES/GCM/NoPadding padding issue with CipherInputStream

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

AES/GCM/NoPadding padding issue with CipherInputStream

Ioannis Kakavas
I have been attempting to use AES/GCM/NoPadding in conjunction with javax.crypto.CipherInputStream and getting unexpected results. To be more specific, when reading bytes from a CipherInputStream backed DataInputStream, I seem to always be able to read fewer bytes than I had written in the corresponding output stream.

This seems to have something to do with padding since I can read all bytes in the case where the number of bytes satisfies the following

x = 12 + n * 16 with n : { 0,1,3,4....}

and I can always read exactly x bytes where x is the closest previous member of the sequence above to the actual length of the byte array I had written to the output stream.
The same code works as expected when using the SunJCE security provider.

Any ideas on what might be the issue here? I have a simple example with tests that reproduce this behavior : https://gist.github.com/jkakavas/ae47bf3c332756d6c2c4f7fd61e1ecb7

Best Regards,
Ioannis



Reply | Threaded
Open this post in threaded view
|

Re: AES/GCM/NoPadding padding issue with CipherInputStream

David Hook-3

I'd suggest revising the semantics of read() - there's no guarantee that a full array will be read and this is no exception. You need to keep going till you are sure you have reached the end of the stream.

Regards,

David

On 07/02/18 23:30, Ioannis Kakavas wrote:
I have been attempting to use AES/GCM/NoPadding in conjunction with javax.crypto.CipherInputStream and getting unexpected results. To be more specific, when reading bytes from a CipherInputStream backed DataInputStream, I seem to always be able to read fewer bytes than I had written in the corresponding output stream.

This seems to have something to do with padding since I can read all bytes in the case where the number of bytes satisfies the following

x = 12 + n * 16 with n : { 0,1,3,4....}

and I can always read exactly x bytes where x is the closest previous member of the sequence above to the actual length of the byte array I had written to the output stream.
The same code works as expected when using the SunJCE security provider.

Any ideas on what might be the issue here? I have a simple example with tests that reproduce this behavior : https://gist.github.com/jkakavas/ae47bf3c332756d6c2c4f7fd61e1ecb7

Best Regards,
Ioannis




Reply | Threaded
Open this post in threaded view
|

RE: AES/GCM/NoPadding padding issue with CipherInputStream

Eckenfels. Bernd
Hello Ioannis,

Just a reminder: Sun JCE provider generally follows the policy to not release any data before the authentication tags are checked (leading to large buffers) BC on the other Hand favor releasing information early (smaller buffers but untrusted data).

Expecting partial reads and never acting on data before the last byte was read is generally good practice but an especially strong requirement for BC providers.

--
http://www.seeburger.com
________________________________________
From: David Hook [[hidden email]]
Sent: Thursday, February 08, 2018 06:48
To: [hidden email]
Subject: Re: [dev-crypto] AES/GCM/NoPadding padding issue with CipherInputStream

I'd suggest revising the semantics of read() - there's no guarantee that a full array will be read and this is no exception. You need to keep going till you are sure you have reached the end of the stream.

Regards,

David

On 07/02/18 23:30, Ioannis Kakavas wrote:
I have been attempting to use AES/GCM/NoPadding in conjunction with javax.crypto.CipherInputStream and getting unexpected results. To be more specific, when reading bytes from a CipherInputStream backed DataInputStream, I seem to always be able to read fewer bytes than I had written in the corresponding output stream.

This seems to have something to do with padding since I can read all bytes in the case where the number of bytes satisfies the following

x = 12 + n * 16 with n : { 0,1,3,4....}

and I can always read exactly x bytes where x is the closest previous member of the sequence above to the actual length of the byte array I had written to the output stream.
The same code works as expected when using the SunJCE security provider.

Any ideas on what might be the issue here? I have a simple example with tests that reproduce this behavior : https://gist.github.com/jkakavas/ae47bf3c332756d6c2c4f7fd61e1ecb7

Best Regards,
Ioannis













SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: [hidden email]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.