7
$\begingroup$

I run into some developers from time to time who sometimes try to modify crypto which I end up saying along the lines of "Don't modify crypto." Usually, the question I get is - "OK, tell me why is this bad? How can this be broken?"

My rule of thumb is usually that cryptographic primitives are supposed to be used they way they are told. A slight modification in those primitives or assumptions can break cryptography in a way that cannot be foreseen. However, I am not that really good with spotting flaws on spot. Plus, finding flaws every time I face such modifications is time consuming. I generally like to explain this to people using examples. How can I explain people that they should not modify cryptographic primitives?

Improve this question
$\endgroup$
7
  • $\begingroup$ The burden should be on them to prove that their modification is at least as secure as the original primitive. $\endgroup$
    – fkraiem
    Commented Jul 11, 2016 at 1:15
  • $\begingroup$ It should be, but it won't. Security and safety always seem to come after ease of use and ease of implementation. Not to mention "not invented here" syndrome. Safety third! $\endgroup$
    – SAI Peregrinus
    Commented Jul 11, 2016 at 2:31
  • $\begingroup$ EAX Prime is broken but pretty similar to EAX. (I don't know the details) $\endgroup$
    – CodesInChaos
    Commented Jul 11, 2016 at 7:23
  • 1
    $\begingroup$ Do they modify primitives themselves (like using custom s-boxes or something) or do they modify higher level constructions? $\endgroup$
    – CodesInChaos
    Commented Jul 11, 2016 at 7:27
  • $\begingroup$ How can I explain people that they should not modify cryptographic primitives? – As that depends on the individual, his/her knowledge range, the protocol and/or algorithm he/she modifies, the way he/she modifies things, etc. answers can be as numerous as the number of potential individual situations/scenarios you run into, where you want to educate him/her/them. That makes the Q “too broad”… with a high chance of also hitting the “primarily opinion based” flagpole. It’s even doubtable if a “one fits all” example for such cases exists. (Note: not saying the already provided examples are bad.) $\endgroup$
    – e-sushi
    Commented Jul 11, 2016 at 13:07

2 Answers 2

Reset to default
13
$\begingroup$

One of the best examples that I know of is "chained CBC" as used in SSL. This looks exactly like regular CBC. The only difference is that instead of sending a new IV with every message, the IV is taken to be the last ciphertext block of the previous message. This is much more efficient since for small packets you don't need to send a large IV each time. In addition, you don't need to generate new randomness for every message (and rely on the randomness on the machine). This looks just like CBC since a single long message exactly has the "chain" effect.

However, this minor modification (and major optimization) is not secure, and resulted finally in the BEAST attack on SSL.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I've seen the chained CBC used for smart card related protocols as well (DESFire? I'm not sure), but it might will be that they would be less vulnerable due to the limitations of the protocol streamed through the secure channel. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jul 11, 2016 at 15:55
3
$\begingroup$

Look at the S-boxes of DES. It turns out that if you choose them at random, you'll probably get an algorithm that's vulnerable to differential cryptanalysis, whereas if you use the NSA-approved ones, you'll get an algorithm that's highly resistant to it.

Improve this answer
$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.