Java tutorials home Java cryptography Encryption intro Keys Symmetric encryption AES/block ciphers Block modes (ECB, CTR, OFB) Asymmetric encryption RSA in Java Comparison of algorithms Key sizes Hash functions
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...
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 technology3.
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.
Written by Neil Coffey. Copyright © Javamex UK 2012. All rights reserved.