14

I believe that the accepted tactic to "prove" a system as secure is to allow the crypto-community to review it and if no vulnerabilities are found over a long period of time (5 or 6 years), then a new system can be accepted as secure until proven otherwise. Please correct me if I'm wrong.

That aside, are there any set of requirements a developer can proactively test their cipher system against before a public release?

I'm working on a large key (4096 bit), symmetric encryption system and I'm doing my best to be weary of the "anybody can make an encryption that they themselves cannot break" trick of believing that my cipher is unbreakable.

What kind of tests can I run on the process or the output? Are there good ways to measure entropy? What statistics should I expect after encrypting a section of data? I know there won't be some magic function that proves I'm secure, but I certainly don't want a public release followed immediately by being broken by a simple problem that some data analysis would have found.

Corey Ogburn
  • 851
  • 7
  • 18

4 Answers4

11
  1. Prove resistance to differential cryptanalysis.

    For example, this presentation: Provable security against Impossible Differential Cryptanalysis. Or this paper: ProvableSecurity Against a Differential Attack (1995)

  2. Prove resistance to linear cryptanalysis.

    For example: On Measuring Resistance to Linear Cryptanalysis

  3. Run a bunch of statical tests against the cipher.

    For example: Cryptographic Randomness Testing of Block Ciphers and Hash Functions

ЯegDwight
  • 101
  • 4
Ethan Heilman
  • 2,326
  • 2
  • 20
  • 40
7

A quite common way to actually prove something is building a system on already known components, and then proving the security of the composed system, given the security of the components.

Most often the paper has a theorem like

If the function F has property Y, then this new function G has property X.

The proof then shows that if someone can attack the property X of G, this gives an attack on the property Y of F.

Then we take for F a known cryptographic primitive, which was already studied by the community, and seems to have the necessary property.

Often this proof works even for whole families of algorithms at once. This way we can get a family of stream ciphers from a family of block ciphers (by a mode of operation), a keyed MAC from a hash function (HMAC), etc. And when the used base component is broken, you can simply switch to another one.

In some cases you can even build your composite system on more than one component, such that breaking only one of them will not help breaking your composed system (i.e. breaking your composite system means breaking all of the components).


Of course, this will most probably not help for a completely new system not based on anything.

Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119
6

The most important take-away is that if you are asking this question, you are almost certainly not qualified to design a secure cryptographic primitive. Sounds harsh, but I mean it in all earnestness.

You wouldn't trust someone who hadn't been to medical school to do surgery on you. Similarly, we wouldn't trust someone who doesn't already know the research literature on cryptanalysis to design a new cipher. More importantly, history shows that amateurs who try to design a new cipher without having spent year studying the research literature almost inevitably invent something useless -- either a cipher that is insecure, or a cipher that is hopelessly non-competitive with the state of the art.

As Bruce Schneier once wrote, "anyone can invent a cipher they themselves can't break". The hard bit is to design a cipher that no one else can break. Usually cipher designers have blind spots for the weaknesses in their own design; by definition, they design their cipher to defend against all the attacks they can think of – but it's easy for there to be other attacks the cipher designer didn't think of, and in that case the cipher designer is unlikely to be aware that their own creation is flawed.

On top of that, the world doesn't really need new ciphers. Our current ones are pretty good. I mean, I'm not saying they're perfect, I'm not saying it is impossible to improve upon them, but I'm saying they're for the most part good enough for all engineering purposes – a modern cryptographic primitive is almost never the weakest link in the security of a system. So working on this problem is in some sense likely to be working on the wrong problem.

So the best advice I can give you on how is: give it up. Don't expect your cipher to be any good. (If you really, really want to learn how to design a new cipher, you could start by studying the research literature on cipher design and cryptanalysis – but be prepared that this will take years of dedicated study.)

As far as how to vet a new cipher, here's how it tends to work. Confidence in the security of cryptographic primitives usually comes from the fact that a lot of really smart, knowledgeable people have tried really hard to break these algorithms, without making much of a dent at all. Of course, this is not a guarantee that no clever attack exists – it is always possible there is some incredibly sneaky mathematical shortcut attack that no one has been clever enough to find, but the more people who try to find one and fail, the less likely that looks. For practical purposes, it seems unlikely that a garden-variety attacker is going to discover an attack that dozens of really smart people tried to find and failed.

It is important to understand that this process does not provide a "proof" of the security of the cryptographic primitive. We have no proof that SHA256, or AES, or RSA are secure – it is widely believed that they are secure, but I could not give you a mathematical proof of that fact, and who knows, it is always possible that widespread beliefs are wrong. There are fundamental reasons why it is incredibly difficult to produce an ironclad mathematical proof of security for most cryptographic primitives.

It is also important to understand that vetting a new primitive is extremely expensive: it takes person-decades of effort from intensely-talented specialists. This is one reason why there is little or no demand for new ciphers, particularly from amateurs who don't already have a deep understanding of the field. The extremely high cost of vetting a new cryptographic primitive is one reason that smart users of cryptography generally try to use existing, vetted primitives, rather than inventing their own. If you invent your own scheme, it is extremely unlikely you'll be able to arrange for as much analysis and vetting of your own scheme as the standard ones have already received – so don't do that. Don't "roll your own". Instead, I advise people to use existing, standard, accepted primitives, like AES, SHA256, RSA, etc.

D.W.
  • 36,982
  • 13
  • 107
  • 196
3

In addition, NIST Statistical Tests and Diehard Battery of Tests of Randomness are good tests.Some tests proposed here and here for stream ciphers. Passing these tests is essential but does not enough. For more information see introduction of first link.
Also Provable security may be useful.

ir01
  • 4,092
  • 3
  • 22
  • 31