ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Ryan (JIRA)" <>
Subject [jira] [Created] (WSS-299) UsernameToken Salt Mac/Encryption Flag on Wrong End of Array
Date Mon, 04 Jul 2011 23:12:21 GMT
UsernameToken Salt Mac/Encryption Flag on Wrong End of Array

                 Key: WSS-299
             Project: WSS4J
          Issue Type: Bug
            Reporter: Patrick Ryan
            Assignee: Colm O hEigeartaigh

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

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

> "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:

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:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message