<p dir="ltr"><br>
- Sent from my phone<br>
Den 5 mar 2015 18:56 skrev "Peter Fairbrother" <<a href="mailto:zenadsl6186@zen.co.uk">zenadsl6186@zen.co.uk</a>>:<br>
> On 04/03/15 17:18, Jerry Leichter wrote:<br>
>> Lessons to learn:<br>
>><br>
>> 1.  Modes and choices are bad in crypto protocols.<br>
>> 2.  Leaving holes to let "good governments" in will inevitably leave holes for others as well.<br>
>> 3.  In code, assume nothing ever really goes away.<br>
><br>
> Couldn't agree more :)<br>
><br>
> To which, add:<br>
><br>
> 4. Occam's razor applies to protocol design too - the simpler it is, the less points of attack there are.<br>
> 5. A system that's hard to use doesn't get used. Good user interfaces are essential. Users don't RTFM, so don't expect them to.<br>
><br>
><br>
> And we have the beginnings of a modern security software design philosophy.<br>
><br>
> Any additions?</p>
<p dir="ltr">6. Don't get too clever. </p>
<p dir="ltr">(Yes, it is partly related to 4, but still distinct as you can have clever and simple protocols, and vice versa).</p>
<p dir="ltr">I'm thinking of things like 3-shake here, the SSL session resumption MITM flaw - let a device initiate a session (which you MITM) to a server, connect yourself to the server, break all the connections, perform session resumption with both of them separately by using data from the previous connections to make them think they're talking directly to each other. Session resumption was supposed to reduce CPU load by reusing keys from previous connections with the same device. IMHO that's a bad type of optimization, and here it was done wrong as the authentication mechanism was flawed. </p>
<p dir="ltr">Any other good examples of supposedly clever but horribly insecure solutions? There has to be quite a few. </p>