A bold ssl idea ?
Having watched the discussions of recent of the SSL bruting, it occured to me that a variation could also be useful. I understand that setting up RC4 keys is slower that testing for the correct key (I may have misuderstood this bit). As a company using SSL can ahve all it's SSL traffic sniffed, from multiple people accessing, a log can easily be built of message/keys. Is it considered practical to modify the brutessl code to have multiple message data, and test each against a key from allocated key space ? If so, this may mean that perhaps 3 message can be tested against a single in the time two single keys could be tested against one message. An an attack scenario, this is a hell of a lot more "efficient" than current trials have been. I realise this could also be considered a bit of target for the main purpose of demonstrating weaknesses, and improving techiquess. My thoughts, anyway - i hope they make sense. lyal
In article <199509031145.VAA12843@oznet02.ozemail.com.au>, lyalc@ozemail.com.au (lyal collins) writes:
Having watched the discussions of recent of the SSL bruting, it occured to me that a variation could also be useful. I understand that setting up RC4 keys is slower that testing for the correct key (I may have misuderstood this bit). As a company using SSL can ahve all it's SSL traffic sniffed, from multiple people accessing, a log can easily be built of message/keys. Is it considered practical to modify the brutessl code to have multiple message data, and test each against a key from allocated key space ? If so, this may mean that perhaps 3 message can be tested against a single in the time two single keys could be tested against one message. An an attack scenario, this is a hell of a lot more "efficient" than current trials have been. I realise this could also be considered a bit of target for the main purpose of demonstrating weaknesses, and improving techiquess.
This technique has been discussed before. It will not work because the 40-bit export version of SSL actually uses 128 bit keys, with 88 of the bits transfered in the clear. The extra 88-bits act as a "salt" to the key. This defeats attempts to do a single key space search for multiple messages. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
I understand that setting up RC4 keys is slower that testing for the correct key (I may have misuderstood this bit).
For pure RC4, Yes. However, SSL is not pure RC4.
Is it considered practical to modify the brutessl code to have multiple message data, and test each against a key from allocated key space ?
You are the third person I've heard think of this. [ The first did quite a lot of calculations before spotting the problem ! ]
If so, this may mean that perhaps 3 message can be tested against a single in the time two single keys could be tested against one message.
Well, the original suggestion I heard was to try 64K at a time :-))
participants (3)
-
jsw@neon.netscape.com -
lyalc@ozemail.com.au -
Piete Brooks