Quantcast

BC 1.55 AESWrap is not JCE policy limited

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

BC 1.55 AESWrap is not JCE policy limited

Eckenfels. Bernd
Hello,

When I use the Oracle 8 JDK without the strong policy I get 128 as the result of Cipher.getMaxAllowedKeyLength("AESWrap"). And consequently it fails to wrap a secret with a 256bit Key with a “InvalidKeyException: Illegal Key Size” from the SunJCE provider in Cipher#init.

When I insert BCProv as the first provider the same limit is returned, however when I actually use the Cipher (from the first provider or explicitely from BC) the resulting Cipher does allow me to wrap with 256bit keys.

I must say I am happy that it is this way, however I wonder who is not compliant?

- should the JCE allow keywrapping with larger keys (as it is not data wrapping)?
- should BC return parameters which actually trigger the same (refused) CryptoPermision check as JCE (to avoid export law problems)
- is it fine that both implementations habe differently and should getMaxAllowedKeyLength in that case report the difference?

        int rc = Security.insertProviderAt(new BouncyCastleProvider(), 1);
        p = Cipher.getInstance("AESWrap").getProvider();
        System.out.println("After inserting BC: " + Cipher.getMaxAllowedKeyLength("AESWrap") + " " + p + " RC: " + rc);
        exerciseProvider(p); //RFC 3394 test vector


    private void exerciseProvider(Provider p)
    {
        try {
            Cipher c = Cipher.getInstance("AESWrap", p);
            c.init(Cipher.WRAP_MODE, key);
            SecretKey testdata = new SecretKeySpec(HexBin.decode("00112233445566778899AABBCCDDEEFF000102030405060708090A0B0C0D0E0F"), "AES");
            byte[] r = c.wrap(testdata);
            assertEquals("28C9F404C4B810F4CBCCB35CFB87F8263F5786E2D80ED326CBC7F0E71A99F43BFB988B9B7A02DD21", HexBin.encode(r));
            System.out.println("OK " + p);
        } catch (Exception e) {
            System.out.println("FaILED " + p + " :" + e);
            e.printStackTrace();
        }
    }

On the BC specification page there is no real information on behavior if the policy is not installed. In fact it lists 192bit as the default key length for AES and AESWrap engines and list 128-256 bit for both engines (with no foot note)..

Gruss
Bernd
--
Chief Architect (R&D), SEEBURGER AG, Germany
http://www.seeburger.com









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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BC 1.55 AESWrap is not JCE policy limited

David Hook

Bother. Okay, it's a bug in BC, it only applies applies to key wrap
though, you won't find the same works with regular ciphers.

It'll be fixed in the next release (I agree, it's nice that it works
like it does now, but if we leave it this way it may cause someone
embarrassment).

Thanks for the report.

Regards,

David

On 18/11/16 05:58, Eckenfels. Bernd wrote:

> Hello,
>
> When I use the Oracle 8 JDK without the strong policy I get 128 as the result of Cipher.getMaxAllowedKeyLength("AESWrap"). And consequently it fails to wrap a secret with a 256bit Key with a “InvalidKeyException: Illegal Key Size” from the SunJCE provider in Cipher#init.
>
> When I insert BCProv as the first provider the same limit is returned, however when I actually use the Cipher (from the first provider or explicitely from BC) the resulting Cipher does allow me to wrap with 256bit keys.
>
> I must say I am happy that it is this way, however I wonder who is not compliant?
>
> - should the JCE allow keywrapping with larger keys (as it is not data wrapping)?
> - should BC return parameters which actually trigger the same (refused) CryptoPermision check as JCE (to avoid export law problems)
> - is it fine that both implementations habe differently and should getMaxAllowedKeyLength in that case report the difference?
>
>         int rc = Security.insertProviderAt(new BouncyCastleProvider(), 1);
>         p = Cipher.getInstance("AESWrap").getProvider();
>         System.out.println("After inserting BC: " + Cipher.getMaxAllowedKeyLength("AESWrap") + " " + p + " RC: " + rc);
>         exerciseProvider(p); //RFC 3394 test vector
>
>
>     private void exerciseProvider(Provider p)
>     {
>         try {
>             Cipher c = Cipher.getInstance("AESWrap", p);
>             c.init(Cipher.WRAP_MODE, key);
>             SecretKey testdata = new SecretKeySpec(HexBin.decode("00112233445566778899AABBCCDDEEFF000102030405060708090A0B0C0D0E0F"), "AES");
>             byte[] r = c.wrap(testdata);
>             assertEquals("28C9F404C4B810F4CBCCB35CFB87F8263F5786E2D80ED326CBC7F0E71A99F43BFB988B9B7A02DD21", HexBin.encode(r));
>             System.out.println("OK " + p);
>         } catch (Exception e) {
>             System.out.println("FaILED " + p + " :" + e);
>             e.printStackTrace();
>         }
>     }
>
> On the BC specification page there is no real information on behavior if the policy is not installed. In fact it lists 192bit as the default key length for AES and AESWrap engines and list 128-256 bit for both engines (with no foot note)..
>
> Gruss
> Bernd
> --
> Chief Architect (R&D), SEEBURGER AG, Germany
> http://www.seeburger.com
>
>
>
>
>
>
>
>
>
> 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.
>


Loading...