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 Nikolas 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).
-