I've been tasked with building up some security exercises (basic CTF training kind of stuff) for work. This should contain a bit of crypto, but my knowledge in this space has been limited to using the right tools, not trying to roll my own, etc, so coming up with an example of bad crypto, but believably real, has been tough.

Specifically one of the flags would be encrypted, say a simple sentence, in a way that would be crackable, allowing for recovery of the plaintext with a bit of know how and some burned cpu.

Could someone point me to an example like that?

Thanks for any input.

-
What should we assume about the mathematical background of the readers? Believably real cryptography (even solved problems which are totally crackable) often involves at basic number theory and abstract algebra. –  Alexander Gruber Feb 23 '13 at 23:13
Sorry, background should be assumed to be typical intermediate software engineer. Some exposure to basic number theory in undergrad CS is probably safe, but nothing more than a passing familiarity with it. –  Peck Feb 24 '13 at 1:19
The first example that comes to mind is deterministic encryption (no IV) on a small piece of data. Looks impenetrable to the novice, but you can do lots of stuff with that (replay attacks, statistical attacks, etc..) –  Thomas Feb 24 '13 at 1:28
You could encrypt a string in CBC mode and provide a padding oracle. –  Stephen Touset Feb 24 '13 at 4:17
This video Crypto for pentesters covers some basic attacks against faulty block cipher uses. vimeo.com/41116595 –  u0b34a0f6ae Feb 25 '13 at 1:06

Start with the Caesar Cipher. It is important to know the flaws and important for students to know the history of it. It would be quite easy to break considering the background of the learners. You probably want to include the algorithm as well as the cipertext.

From here you can build more advanced problems since they have the basic understanding of what's going on.

Simple problems, but we must crawl before we can walk.

-

Take one AES mode of encryption and apply the model MAC then Encrypt is crackable in SSL-TLS. This hybrid model for authentication and confidentiality is vulnerable to padding oracles attacks and more recently even if with the mitigation of padding oracles attacks with constant time decryption or 1 error return instead of 2(bad MAC or bad pad) there are still side channel attacks as timing attacks

-

Some possibilities that come to mind:

• Really small and/or predictable key space (hash of n-digit PIN / process ID / IP / MAC address combo, etc);
• CTR mode encryption with no MAC, where the plaintext is very predictable;
• Some critical use of random number (e.g. key), where random number comes from e.g. rand(1) or rand(unix_time_resolution_in_seconds);
• Harder: re-use of key + IV in CTR mode for different (predictable) plaintexts;
• Harder: length extension attacks on naive macs like SHA-1(secret | data).
-

My favorite example of "doing something bad that isn't obvious" is this example of the Electronic Code Book mode of encryption.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29

Look at the accompanying picture. I've used this slide in talks (actually, I tailored it to my audience and used our corporate logo instead of Tux.) It really gets the audience's attention. I use it to reinforce the point that tiny details really matter. My hope is that they come away realizing they don't know enough, and that they need either more than a passing knowledge of cryptography, and to engage an expert.

It's related to the other point I try to make: one expert doesn't know everything. Seek out reviews of your systems from other experts. Take their advice gladly and willingly. You're trying to defeat a dark and powerful enemy, and they will have more resources than you can possibly imagine. Your ego is not a useful defense - on the contrary, hubris is often a lure.

-