Bug 54057 - call to javax.crypto.Mac.init() with 5 character password produces java.security.InvalidKeyException: Key too short
Summary: call to javax.crypto.Mac.init() with 5 character password produces java.secur...
Status: UNCONFIRMED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.98
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-20 21:07 UTC by Patrick
Modified: 2017-06-14 16:55 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
KeySample.java (247 bytes, application/octet-stream)
2012-07-20 21:07 UTC, Patrick 		Details
classpath-0.98-KeyTooShort.patch (317 bytes, application/octet-stream)
2012-07-20 21:08 UTC, Patrick 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick 2012-07-20 21:07:21 UTC 
On my Mac, running the Oracle JRE, when I call javax.crypto.Mac.init() with a 5 character password I get no complaints. With classpath on my embedded device it throws a java.security.InvalidKeyException: Key too short. 

I'm including the sample code along with output below.

==Oracle JRE==
$ java KeySample
Done
$ java -version
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720)
Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)
$ 

==classpath==
# jamvm KeySample
Exception in thread "main" java.security.InvalidKeyException: Key too short
   at gnu.javax.crypto.mac.HMac.init(HMac.java:148)
   at gnu.javax.crypto.jce.mac.MacAdapter.engineInit(MacAdapter.java:119)
   at javax.crypto.Mac.init(Mac.java:349)
   at javax.crypto.Mac.init(Mac.java:328)
   at KeySample.<init>(KeySample.java:14)
   at KeySample.main(KeySample.java:8)
# jamvm -version
java version "1.5.0"
JamVM version 1.5.4
Copyright (C) 2003-2010 Robert Lougher <rob@jamvm.org.uk>

This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2,
or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

Build information:

Execution Engine: direct-threaded interpreter with stack-caching
Compiled with: gcc 4.4.6

Boot Library Path: /usr/lib/classpath
Boot Class Path: /usr/share/jamvm/classes.zip:/usr/share/classpath/glibj.zip
#
Comment 1 Patrick 2012-07-20 21:07:54 UTC 
Created attachment 27849 [details]
KeySample.java
Comment 2 Patrick 2012-07-20 21:08:36 UTC 
Created attachment 27850 [details]
classpath-0.98-KeyTooShort.patch
Comment 3 Patrick 2012-07-20 21:08:59 UTC 
I attached a patch that fixes the problem for me.
Comment 4 Andrew John Hughes 2012-07-23 14:53:30 UTC 
Commenting the code out isn't a solution.

If you set the attribute gnu.crypto.hmac.pkcs5 to true, the test will be skipped as you wish.
Comment 5 Patrick 2012-07-23 21:38:00 UTC 
The code calling Mac is part of a third party library. How do I set the attribute you described?
Comment 6 Guillermo Rodriguez 2017-06-14 16:55:00 UTC 
Why does (In reply to Andrew John Hughes from comment #4)
> Commenting the code out isn't a solution.
> 
> If you set the attribute gnu.crypto.hmac.pkcs5 to true, the test will be
> skipped as you wish.

Why does gnu.crypto.mac.HMac try to enforce that the key size is >= the output block size of the underlying algorithm? In general there is no such requirement for HMAC algorithms and while this test may make sense in some cases, in others obviously it does not.

I think that this test should be removed.