NODE eddc3a5eA bold ssl idea ?
lyalc@ozemail.com.au (lyal collins)Sun, 3 Sep 95 04:45:46 PDT
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
NODE 334aa572Re: A bold ssl idea ?
Piete Brooks <Piete.Brooks@cl.cam.ac.uk>Sun, 3 Sep 95 08:25:01 PDT
> 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 :-))
NODE b1b68385Re: A bold ssl idea ?
jsw@neon.netscape.com (Jeff Weinstein)Sun, 3 Sep 95 15:20:24 PDT
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.