<p dir="ltr"><br>
Den 23 juni 2016 08:31 skrev "Phillip Hallam-Baker" <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>>:<br>
><br>
> I am giving a course on cryptography starting tomorrow at the Somerville Artisan's Asylum. The plan is to give 8 modules of roughly an hour, two per week. The whole point being to film the presentation and publish it as free YouTube videos.</p>
<p dir="ltr">* What's your threat model?<br>
Running on an unprotected computer in the hands of an adversary (DRM, untrusted hosting services, etc)? No point with crypto, in that case good old obfuscation is your only chance.<br>
You need well defined threats, and make sure you're addressing them correctly (and that it is possible at all! <br>
). What would hurt you, how likely is it, and how much effort does it take to prevent? </p>
<p dir="ltr">* Language security. Heartbleed, anyone? No point in using perfect algorithms if your implementation leaks your secrets when sent unexpected inputs. (extension of your point on complexity?) </p>
<p dir="ltr">* Key management matters. Perfect crypto and perfect implementations means nothing if your system trusts all keys equally, including random ones (extension of your point on endpoints?). Reference: <a href="https://xkcd.com/1181/">https://xkcd.com/1181/</a></p>
<p dir="ltr">It also doesn't matter if you leak your keys, or lose your keys (back to data loss). Also try to use independent keys for separate purposes, instead of one key for everything. </p>
<p dir="ltr">* Semantics, replay attacks, various creative MITM attacks used to create crypto oracles out of naive software - What does your securely authenticated messages actually mean? And can I forward messages you sent to me to somebody else when I shouldn't? See TLS triple handshake. </p>
<p dir="ltr">Each message should have only one purpose and only be usable in one context. Every step of every protocol should be designed with the full environment in consideration. </p>
<p dir="ltr">A security proof within one instance of an algorithm / protocol is useless if it is running next to another algorithm / protocol where the pair are decryption oracles for each other (I've seen examples of this before, but can't remember the source). Context separation is important. </p>
<p dir="ltr">* Sidechannels and metadata. Sometimes it will leak your entire message if it is predictable enough. Always encrypting Yes to 3 letters and No to 2 is a trivial example. Sources of sidechannel leaks and metadata can also sometimes act as oracles (see the point above). </p>