Microsoft files EU Android complaint

[James Knott]

D. Hugh Redelmeier wrote:
> Testing can never show the absence of bugs.

That applies to everything.

> The order of most IKE payloads is unspecified.  For a long time, we
> only accepted them in one order (that in which they were described in
> the RFC).  Never once did that cause a problem.  I would guess that
> many implementations would fail if they received payloads in another
> order.  This is an example where the spec gave an option that was
> worse than useless (at least it wasn't visible to the user).

That, of course, is an implementation issue, not an inherent problem 
with IPSec.

> I think that I'm the only one that implemented IKE authentication with
> bare public keys (i.e. not embedded in X.509 certificates).

StrongSWAN supports self generated certificates in the same manner as ssh.

> Lots of people want pre-shared keys but bare public keys are just
> about as easy, way more powerful, and easier to handle safely.

Pre-shared secret keys are easier, as you don't have to generate a 
public/private key pair, but creating the secret password can stand some 
improvement.  Like other passwords, people often choose a simple on that 
may have some connection to them.  When I created the secret passwords, 
I would generally use ps aux|md5sum to get a string of "random" characters.

> We fought for a long time to get DES eliminated (it had been mandatory
> to support it in IPSec).  Our sponsor even built the DES-cracking
> hardware to make the point that DES was too weak (up to then denied by
> NSA, even to the US Congress).

Yep, I recall reading about how easy it had become to break.  I also 
recall reading a book on encryption where they covered several methods, 
including 3DES.  What I found interesting was the way they'd take the 
168 bit key, split it into 3 56 bit keys then use the parts, in turn to 
encrypt, then decrypt and encrypt again.  This was done to maintain 
compatibility with 56 bit DES systems with the same 56 bits used in all 
three steps.  This would result in the decrypt stage canceling out one 
of the encrypt stages and providing the same effect as a single encrypt 
stage.





--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists