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?

$\endgroup$

closed as too broad by otus, e-sushi Jul 11 '16 at 13:01

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ The burden should be on them to prove that their modification is at least as secure as the original primitive. $\endgroup$ – fkraiem Jul 11 '16 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 Jul 11 '16 at 2:31
  • $\begingroup$ EAX Prime is broken but pretty similar to EAX. (I don't know the details) $\endgroup$ – CodesInChaos Jul 11 '16 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 Jul 11 '16 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 Jul 11 '16 at 13:07
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.

$\endgroup$
  • $\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 Jul 11 '16 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.

$\endgroup$

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