On Mon, Mar 11, 2013 at 11:13 PM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
Hi guys,

I think we have a problem in the way we select the EncryptionType on the

The idea is to select the strongest supported EType by both the client
and the server. The client send a list (ordered) of ETypes it supports,
and the server check on its configured EType list to find one matching
EType (and it should be the strongest one).

The method that does this selection is the following :

    public static EncryptionType getBestEncryptionType(
Set<EncryptionType> requestedTypes, Set<EncryptionType> configuredTypes )
        for ( EncryptionType encryptionType : requestedTypes )
            if ( configuredTypes.contains( encryptionType ) )
                return encryptionType;

        return null;

As we can see, we iterate on the client provided ETypes, and if the
EType is present on the server set of EType, we are done. This is not
good : the test I have made shos that the client send such a list :

[des-cbc-md5 (3), des-cbc-crc (1), rc4-hmac (23), des3-cbc-sha1-kd (16),
aes128-cts-hmac-sha1-96 (17), aes256-cts-hmac-sha1-96 (18)]

As we can see, the weakest EType are on the left.

The server configured ETypes are :

[aes128-cts-hmac-sha1-96 (17), des3-cbc-sha1-kd (16), des-cbc-md5 (3)]

It's obvious that the selected EType will be des-cbc-md5, and not
aes128, as expected...

So first, we should invert the logic : iterate using the configured
ETypes, checking on the set of ETypes provided by the client, from teh
strongest to the weakest.

But I also think we should use a List to store the configured ETypes in
the server (even if the order is maintained, as we are using a
LinkedHashSet to store the ETypes), and not a Set. This is confusing.
For the client, we can still use a Set.

Thoughts ?

+1, but the existing logic shouldn't cause any authentication failure cause the server will send the selected EType in EncryptedData of AsRep
Emmanuel Lécharny

Kiran Ayyagari