Encryption: keys

So we've decided that security by obscurity is not a good option for encoding our data. Essentially, it's not a good option because:

So instead, the vastly more practical and secure option is as follows:

For now, we can imagine that a "key" is just some specified number of random bytes. Roughly speaking, this is a sequence of bytes that we'll "mix in" when we encrypt a particular conversation or file. And the key can change for, say, every file or communication that we encrypt. But the actual encryption algorithm— which defines the way in which we "mix in" the key— will always be the same. Our premise is essentially that "with this algorithm and any permitted randomly-chosen key, the encrypted data will always be totally undecipherable without a key that is 100% correct". Then, we make our encryption system public and encourage the world's cryptography experts to deliberately try and find flaws in our algorithm. Without the specific key that encrypted a given piece of data, the algorithm by itself is not enough to decrypt that data, so it is of no security concern (quite the opposite, in fact) that the algorithm is public.

The AES process showed that organising a competition for a new standard (where the winning team gets fame/money beyond their hamster's wildest dreams) can help with this: participants then have an incentive to look for flaws in each others' submissions, and even for those outside the competition, there'd be enough kudos in writing a paper that identified a flaw in an emerging NSA standard that some experts would surely start looking. Previous examples of active incentives to guage the strength of cryptographic algorithms include the contest held by Dr Dobb's Journal to find flaws in Blowfish2, or RSA's previous competition to factor various large numbers.

After some time, we round up the resulting attacks and analyses of our algorithm, and assess how secure our system is. If in several years, none of the world's leading cryptanalysts has found a flaw (and we're sure they've been looking), then this gives a high level of confidence that our algorithm is "secure". If after 6 months, somebody publishes a paper showing how to break a 9-round version of our algorithm and our algorithm uses 10 rounds (see the section on block ciphers for the notion of rounds), then we should be much more worried.

Assuming that our algorithm is secure, then as a secure, key-based algorithm, it then has some desirable properties:

Now, our notion of "secure" actually implies a couple of extra things. In particular, we want decryption to be an "all-or-nothing" operation. It would be no good, for example, if the encrypted/decrypted output with key 01234567 was similar to the output with key 01234568 in any detectable way. If it were, then: (a) an attacker could eventually guess our key by just "trying lots of keys", using failures as a clue as to how "warm" they were, and thus which key to try next; (b) Person A might be able to use his/her supposedly unique encryption key to decrypt Person B's data without authorisation. The relationship between the key and the resulting encrypted text have to appear "random".

Guarantee of security?

Unfortunately, there's probably no practical encryption system whose security can be guaranteed: at any given time, we deem a system "secure" in the sense that the world's cryptanalysts have so far not found a flaw. But no mathematical proof will generally tell us that a flaw can't ever be found, or that one will even be needed with some future technology4.

Next: symmetric key encryption

On the next page, we begin looking at symmetric key encryption in Java. This is arguably the simplest case, where the key used to encrypt is the same as that used to decrypt, and is thus a secret between the parties involved.

1. Even if you think you can just "pay enough experts" to look at it while signing a non-disclosure agreement, it's extremely difficult to know that it's been seen by "enough" of the "right" experts. Think about how the Internet has made certain sites explode in popularity virtually overnight. Your home-grown scheme, or the one that you paid one expert to look at for one week, may appear to offer adequte security now. But if your program suddenly gains in popularity, that situation could be reversed too rapidly for you to do much about the insecurity before it's too late.
2. See Bruce Schneier's 1995 article: Blowfish: One Year Later.
3. Compared to most uses, we actually need to be careful about how to generate random numbers: see the discussion of SecureRandom.
4. For example, all of our estimates of the effort required to guess a key will be incorrect once quantum computers are mainstream.

If you enjoy this Java programming article, please share with friends and colleagues. Follow the author on Twitter for the latest news and rants.

Editorial page content written by Neil Coffey. Copyright © Javamex UK 2021. All rights reserved.