Why is it that *everything* uses some sort of public-key encryption algorithm for storing sensitive data? It's stupid!
OK, it's brilliantly useful for sending data across the internet and so on but for storing one's own sensitive data it is entirely pointless as far as I can see.
For example if I want to store a file with some sensitive data in it and only only want to be able to decrypt it myself then surely anything *but* a public key encryption algorithm makes sense. Essentially a public key algorithm means that there is always a brute force way of getting at the data, it may take more computing power/time than is available but it is in principle possible. Other ways of encrypting can be made essentially uncrackable if you want.
Are there any encryption experts here who can persuade me that I'm being silly?
On Sun, May 21, 2006 at 04:27:49PM -0500, chrisisbd@leary.csoft.net chrisisbd@leary.csoft.net wrote:
Why is it that *everything* uses some sort of public-key encryption algorithm for storing sensitive data? It's stupid!
OK, it's brilliantly useful for sending data across the internet and so on but for storing one's own sensitive data it is entirely pointless as far as I can see.
For example if I want to store a file with some sensitive data in it and only only want to be able to decrypt it myself then surely anything *but* a public key encryption algorithm makes sense. Essentially a public key algorithm means that there is always a brute force way of getting at the data, it may take more computing power/time than is available but it is in principle possible. Other ways of encrypting can be made essentially uncrackable if you want.
Well, isn't it that case that with any form of encryption you're going to have to store either some meta data to be able to decrypt it (as in the case of gpg --symmetric, which needs no public key...), how does that make it any less easy to crack?
Just because it's called a "public key" doesn't mean that you have to expose it to the wild, if you're only using it yourself, then where's the problem? Anyway - what it boils down to is this, all encrypted data is essentially crackable, it's just the timescale involved. I'm not convinced that the timescale becomes any less insane for public key encyption as apposed to anything else. Of course, the safest encryption methods are immutable, it's a one off shot, you can't get the data back. Oh, and guess what, that's crackable too, by feeding data through the same algorithm until you get a match. Takes some time, yeah, but then if you're doing that style encryption maybe you didn't like your data after all?
Are there any encryption experts here who can persuade me that I'm being silly?
Not an expert, but I'd say that a 2048 bit pgp public key encrypted file would take "quite some time" to decrypt without being given the secret key, and generating the secret key would take "rather a while" from just the data that you can get from things encrypted using the public key.
Cheers, Brett.
On Sun, 2006-05-21 at 22:57 +0100, Brett Parker wrote:
Not an expert, but I'd say that a 2048 bit pgp public key encrypted file would take "quite some time" to decrypt without being given the secret key, and generating the secret key would take "rather a while" from just the data that you can get from things encrypted using the public key.
When posting to the list please use tangible units to measure space/time
You don't make it clear whether you are referring to a metric "quite some time" or the imperial one...Therefore is this longer than "rather a while" or not ?
Specifically we are looking for libraries of congress, Volkswagen beetles, surface of the sun, time since the big bang...that sort of thing :-)
On Sun, May 21, 2006 at 11:31:09PM +0100, Wayne Stallwood ALUGlist@digimatic.plus.com wrote:
On Sun, 2006-05-21 at 22:57 +0100, Brett Parker wrote:
Not an expert, but I'd say that a 2048 bit pgp public key encrypted file would take "quite some time" to decrypt without being given the secret key, and generating the secret key would take "rather a while" from just the data that you can get from things encrypted using the public key.
When posting to the list please use tangible units to measure space/time
You don't make it clear whether you are referring to a metric "quite some time" or the imperial one...Therefore is this longer than "rather a while" or not ?
OK OK... let's do a bit of googling and find some random figures :) http://www.linuxjournal.com/article/8732 - mostly talks about symettric encryption, has some figures and a disclaimer saying "but hardware keeps getting cheaper" http://www.math.utah.edu/~beebe/PGP-notes.html#reading-list - a reading list full of useful links and book titles etc etc. probably worth reading to know more :) http://lists.gnupg.org/pipermail/gnupg-users/2004-June/022768.html - a relatively interesting post on the gnupg mailing list http://www.usatoday.com/tech/columnist/andrewkantor/2004-03-19-kantor_x.htm - much more interesting read. basically says "yeah, well, you have x keyspace, the timing comes down to how quickly you can generate and test keys."
But no one's going for hard and fast times. So, if we make an assumption of a 2048 bit key, and half the address space (it's a quick way of getting the average number of attempts across multiple keys of cracking the key)... so we get a possible key space of... ~3.2317 * 10^616 (that's a lot of keys!), now then... half of that is... 1.6159 * 10^616 keys... making an assumption of, say, lets be insane and go for 1000 keys a second... that will take 1.615 * 10^613 seconds, or, if you like... 5.1344 * 10^605 *YEARS* to brute force it ;) OK - so there might be less intensive ways to break it than brute force... but I haven't found any references to them yet.
Specifically we are looking for libraries of congress, Volkswagen beetles, surface of the sun, time since the big bang...that sort of thing :-)
*BOOM*! (or something like that).
If I get bored tomorrow I might look in to it further :)
Cheers, Brett.
On Sun, May 21, 2006 at 10:57:41PM +0100, Brett Parker wrote:
On Sun, May 21, 2006 at 04:27:49PM -0500, chrisisbd@leary.csoft.net chrisisbd@leary.csoft.net wrote:
Why is it that *everything* uses some sort of public-key encryption algorithm for storing sensitive data? It's stupid!
OK, it's brilliantly useful for sending data across the internet and so on but for storing one's own sensitive data it is entirely pointless as far as I can see.
For example if I want to store a file with some sensitive data in it and only only want to be able to decrypt it myself then surely anything *but* a public key encryption algorithm makes sense. Essentially a public key algorithm means that there is always a brute force way of getting at the data, it may take more computing power/time than is available but it is in principle possible. Other ways of encrypting can be made essentially uncrackable if you want.
Well, isn't it that case that with any form of encryption you're going to have to store either some meta data to be able to decrypt it (as in the case of gpg --symmetric, which needs no public key...), how does that make it any less easy to crack?
You don't have to store *any* data in order to be able to decrypt it surely. Apart from a knowledge of the password/key used and how it was used (i.e. the encryption algorithm) which can be kept in one's head or somewhere totally inaccessible from where the encrypted data is stored I don't see how one would need any "meta data". Or do you mean the decryption algorithm by "meta data"?
Hopefully with a good alogorithm or something like a single use key it doesn't matter if the algorith is available, it's still impossible to decrypt without the key.
Just because it's called a "public key" doesn't mean that you have to expose it to the wild, if you're only using it yourself, then where's the problem? Anyway - what it boils down to is this, all encrypted data is essentially crackable, it's just the timescale involved. I'm not convinced that the timescale becomes any less insane for public key encyption as apposed to anything else. Of course, the safest encryption methods are immutable, it's a one off shot, you can't get the data back. Oh, and guess what, that's crackable too, by feeding data through the same algorithm until you get a match. Takes some time, yeah, but then if you're doing that style encryption maybe you didn't like your data after all?
I suppose that's right, if neither public nor private key are exposed it comes to the same thing as other methods. However you can *only* use machine methods to decrypt something if you know some part of the data can't you? Otherwise how do you know when you have got the right answer?
On Mon, 2006-05-22 at 02:50 -0500, chrisisbd@leary.csoft.net wrote:
However you can *only* use machine methods to decrypt something if you know some part of the data can't you? Otherwise how do you know when you have got the right answer?
Reminds me of the ultimate weakness of the Enigma, it never cyphered a character as itself.
So when using a machine to brute force it you just rotate the key until every character in the decoded text is different to the same position in the encoded text and then you know there is a very high chance you have the correct key.
That and the Germans cyphering the same block of text (the header) of their weather reports every time they sent them.
On Sun, May 21, 2006 at 04:27:49PM -0500, chrisisbd@leary.csoft.net wrote:
Why is it that *everything* uses some sort of public-key encryption algorithm for storing sensitive data? It's stupid!
OK, it's brilliantly useful for sending data across the internet and so on but for storing one's own sensitive data it is entirely pointless as far as I can see.
For example if I want to store a file with some sensitive data in it and only only want to be able to decrypt it myself then surely anything *but* a public key encryption algorithm makes sense. Essentially a public key algorithm means that there is always a brute force way of getting at the data, it may take more computing power/time than is available but it is in principle possible. Other ways of encrypting can be made essentially uncrackable if you want.
Are there any encryption experts here who can persuade me that I'm being silly?
The only thing that's provably secure is a one time pad. Even a symmetric key algorithm can be brute forced. The key is to ensure that the algorithm and key length you choose is not feasibly brute forceable before universe heat death.
Most public key implementations these days use the public/private key to encrypt a symmetric key that's then used for the session/instance. PGP and SSH both work this way for example.
The example you give of a file encrypted on your hard drive is probably one where the extra properties of public key cryptography don't really add much; PKI's real strength is about the fact you anyone who can encrypt stuff to you can't also decrypt anything to you; you can distribute the public key far and wide, which you can't do with a symmetric key.
(Disclaimer: I'm knackered and it's many years since I did any crypto related mathmatical proofs.)
J.
On Mon, May 22, 2006 at 10:11:11PM +0100, Jonathan McDowell wrote:
On Sun, May 21, 2006 at 04:27:49PM -0500, chrisisbd@leary.csoft.net wrote:
Why is it that *everything* uses some sort of public-key encryption algorithm for storing sensitive data? It's stupid!
OK, it's brilliantly useful for sending data across the internet and so on but for storing one's own sensitive data it is entirely pointless as far as I can see.
For example if I want to store a file with some sensitive data in it and only only want to be able to decrypt it myself then surely anything *but* a public key encryption algorithm makes sense. Essentially a public key algorithm means that there is always a brute force way of getting at the data, it may take more computing power/time than is available but it is in principle possible. Other ways of encrypting can be made essentially uncrackable if you want.
Are there any encryption experts here who can persuade me that I'm being silly?
The only thing that's provably secure is a one time pad. Even a symmetric key algorithm can be brute forced. The key is to ensure that the algorithm and key length you choose is not feasibly brute forceable before universe heat death.
You can *only* brute force surely if you know a significant chunk of the result of decrypting the data before you start, otherwise how does the brute force approach know when it's got a hit?
On Mon, 2006-05-22 at 16:22 -0500, chrisisbd@leary.csoft.net wrote:
You can *only* brute force surely if you know a significant chunk of the result of decrypting the data before you start, otherwise how does the brute force approach know when it's got a hit?
There are a few ways I could think to do this...
Once is the enigma approach that I mentioned in a previous message, but that won't work against modern encryption.
If we are talking about files, then you just keep rotating until you see what looks like a valid common file header (of course here, knowing what sort of file you are dealing with would help).
If we are talking about encoded text then working against a simplified dictionary might do the trick.
If we are talking about a whole filesystem, then is there any filesystem structure or checksums that might help ?
On Mon, May 22, 2006 at 04:22:54PM -0500, chrisisbd@leary.csoft.net wrote:
On Mon, May 22, 2006 at 10:11:11PM +0100, Jonathan McDowell wrote:
The only thing that's provably secure is a one time pad. Even a symmetric key algorithm can be brute forced. The key is to ensure that the algorithm and key length you choose is not feasibly brute forceable before universe heat death.
You can *only* brute force surely if you know a significant chunk of the result of decrypting the data before you start, otherwise how does the brute force approach know when it's got a hit?
Known plain text attacks are a specific type of cryptographic attack, but aren't the only one. All you need for brute force is the ability to know when you've succeeded; this may be because you actually know some plain text (eg a file header) or it may be because you can do statistical analysis of the output (eg you expect English, so when what you're getting out looks like English text you've probably got somewhere).
J.
On Tue, May 23, 2006 at 10:28:17AM +0100, Jonathan McDowell wrote:
On Mon, May 22, 2006 at 04:22:54PM -0500, chrisisbd@leary.csoft.net wrote:
On Mon, May 22, 2006 at 10:11:11PM +0100, Jonathan McDowell wrote:
The only thing that's provably secure is a one time pad. Even a symmetric key algorithm can be brute forced. The key is to ensure that the algorithm and key length you choose is not feasibly brute forceable before universe heat death.
You can *only* brute force surely if you know a significant chunk of the result of decrypting the data before you start, otherwise how does the brute force approach know when it's got a hit?
Known plain text attacks are a specific type of cryptographic attack, but aren't the only one. All you need for brute force is the ability to know when you've succeeded;
Exactly! So if I send my encrypted messages in French or Polish for example you can brute force attack for ever and you'll never break it.
this may be because you actually know some
plain text (eg a file header) or it may be because you can do statistical analysis of the output (eg you expect English, so when what you're getting out looks like English text you've probably got somewhere).
That "statistical analysis" will surely add a huge amount of time to the testing as you try each key though won't it? It would make a nonsense of the oft-quoted figures for breaking given algorithms, all those (I assume) depend on the assumption that you have an exact and instant test available to see if you have a 'hit'.
On Tue, May 23, 2006 at 04:37:32AM -0500, chrisisbd@leary.csoft.net wrote:
On Tue, May 23, 2006 at 10:28:17AM +0100, Jonathan McDowell wrote:
On Mon, May 22, 2006 at 04:22:54PM -0500, chrisisbd@leary.csoft.net wrote:
On Mon, May 22, 2006 at 10:11:11PM +0100, Jonathan McDowell wrote:
The only thing that's provably secure is a one time pad. Even a symmetric key algorithm can be brute forced. The key is to ensure that the algorithm and key length you choose is not feasibly brute forceable before universe heat death.
You can *only* brute force surely if you know a significant chunk of the result of decrypting the data before you start, otherwise how does the brute force approach know when it's got a hit?
Known plain text attacks are a specific type of cryptographic attack, but aren't the only one. All you need for brute force is the ability to know when you've succeeded;
Exactly! So if I send my encrypted messages in French or Polish for example you can brute force attack for ever and you'll never break it.
They'll still look more like text than garbage though.
plain text (eg a file header) or it may be because you can do statistical analysis of the output (eg you expect English, so when what you're getting out looks like English text you've probably got somewhere).
That "statistical analysis" will surely add a huge amount of time to the testing as you try each key though won't it? It would make a nonsense of the oft-quoted figures for breaking given algorithms, all those (I assume) depend on the assumption that you have an exact and instant test available to see if you have a 'hit'.
I've no idea about the effort required for the statistical analysis of data; I'd imagine it depends somewhat on the data. I wouldn't want to trust the security of something I was planning to encrypt on how resource intensive I thought analysing the plain text was....
J.
-
Brett Parker -
chrisisbd＠leary.csoft.net -
Jonathan McDowell -
Wayne Stallwood