[jira] [Closed] (WSS-299) UsernameToken Salt Mac/Encryption Flag on Wrong End of Array

["Colm O hEigeartaigh (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh closed WSS-299.
-----------------------------------


> UsernameToken Salt Mac/Encryption Flag on Wrong End of Array
> ------------------------------------------------------------
>
>                 Key: WSS-299
>                 URL: https://issues.apache.org/jira/browse/WSS-299
>             Project: WSS4J
>          Issue Type: Bug
>    Affects Versions: 1.5.11, 1.6.1
>            Reporter: Patrick Ryan
>            Assignee: Colm O hEigeartaigh
>             Fix For: 1.5.12, 1.6.2
>
>
> In UsernameToken Profile key derivation, the flag that indicates the use for the salt is being placed on the wrong end.  It should be at index 0 but is being placed at index 15.  See org.apache.ws.security.message.token.UsernameToken.generateSalt(boolean).
> The UsernameToken Profile 1.1 spec says
> > "The high order 8 bits of the Salt will have the value of 01 if the key
> > is to be used in a MAC and 02 if the key is to be used for encryption.
> > The remaining 120 low order bits of the Salt should be a random value."
> Java is big endian, which means the high order values come first (i.e. high byte is at index 0 of a byte array).  From http://en.wikipedia.org/wiki/Endianness
> > "The usual contrast is whether the most-significant or least-significant
> > byte is ordered first - i.e. at the lowest byte address - within the
> > larger data item. A big-endian machine stores the most-significant byte
> > first (at the lowest address), and a little-endian machine stores the
> > least-significant byte first. In these standard forms, the bytes remain
> > ordered by significance."
> Looking at other UsernameToken Profile implementations turned up this example: http://blogs.oracle.com/SureshMandalapu/entry/passwordderivedkeys_support_in_metro
> which clearly shows the salt flag is at index 0 of the byte array:
> > Absds/FHfgh/swderfa== decodes to 01bb1db3f1477e087fb3075eadf6
> (when printing the byte array in hex starting at index 0).
> And, in my discussion with Colm to confirm this issue, I asked what should be done about salt validation.  Here is what he said:
> > Hi Patrick,
> > 
> > > Doesn't that mean index 0 of an array should hold the most significant
> > > value?
> > 
> > Yes, I think you're right. Could you submit a JIRA and patch?
> > 
> > > * check both ends and if only one end is either 1 or 2,
> > >  then use that to validate the usage of the derived key
> > > * if both ends contain either a 1 or 2 then skip validation on
> > >  the usage of the derived key
> > > * if neither end has a 1 or a 2, then fail validation
> > 
> > That sounds reasonable to me. I think it could be extended so that we
> > validate that the correct flag has been set for signature
> > verification, or for decryption, when using a derived key - I don't
> > think the current code does this.
> > 
> > Thanks,
> > 
> > Colm.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org