[Cryptography] What to put in a new cryptography course

Natanael natanael.l at gmail.com
Thu Jun 23 05:26:19 EDT 2016


Den 23 juni 2016 08:31 skrev "Phillip Hallam-Baker" <phill at hallambaker.com>:
>
> 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.

* What's your threat model?
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.
You need well defined threats, and make sure you're addressing them
correctly (and that it is possible at all!
). What would hurt you, how likely is it, and how much effort does it take
to prevent?

* 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?)

* 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: https://xkcd.com/1181/

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.

* 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.

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.

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.

* 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160623/086d023c/attachment.html>


More information about the cryptography mailing list