Not quite. There’s also the speed question – a physical source of real random data that only spits out a few thousand bits per second isn’t very good as a direct source, but can be used to provide a true-random seed for a good (and much faster) pseudorandom number generator.
Not even non-pseudo RNGs are always secure. There are some real RNGs that use things like noise from device drivers or other hardware to generate bits. This is normally rather secure, but it can be vulnerable depending on the devices providing the random numbers. Of note is routers, which tend to produce predictable noise at certain times (e.g. at boot), and their apparent noise can be manipulated by clever hackers.
One important rule of Cryptography is that you never ever send the “key” and “cipher” in the same message. If you want really safe encryption of the internet, you send the key in the post, or hand deliver it. Keeping the specific cryptographic algorithm secret is a good idea. If the evil NSA gets the key, they won’t know how to apply it (even though No Such Agency exists).
I’m wondering about this whole ‘randomness’ debate … wouldn’t a completely random seed from the transmitting machine be un-readable at the receiving machine? Doesn’t the receiver need something to latch onto so it can produce the proper key stream?
TDBCZ anyone?
Wrong. You send public keys anywhere and everywhere, and you don’t send private keys at all.
The main use of public key cryptography, SSL/TLS (Transport Layer Security - Wikipedia), uses public key crypto operations only to exchange symmetric keys that are then used by the endpoints for their actual communications. This is mainly because public key crypto operations are very computationally expensive compared to symmetric key crypto (see RFC 6101 - The Secure Sockets Layer (SSL) Protocol Version 3.0).
Public keys are for public information
http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?_r=0
Private keys are for private information.
There’s a balance between how much BS one would have to go through compared to just how bad it would be if the evil NSA got a hold of it. If you really don’t want the NSA to know, you probably shouldn’t use off-the-shelf encryption. Keeping the algorithm secret is as important as keeping the key secret.
A big rule of most modern encryption is “if your encryption method relies on the snooper to not know what you’re doing, you’ve failed.” One of the big reasons for this is that it’s very hard to write a cryptographically secure algorithm and also very hard to implement it correctly (there’s all sorts of snags like turning off compiler optimizations).
I mean, maybe if we’re talking military counter-intelligence stuff, where the US is literally going to dedicate an entire branch of its cryptography and espionage team to cracking your algorithm and getting your keys. Barring that, keeping the algorithm secret is largely going to hinder more than help. Usually protecting keys is plenty, even the Enigma machine was useless without that rotation’s code sheet.
I agree, protecting the key is vital. Yes, the NSA does have an entire branch for Cryptology, the science of breaking codes. There’s also a branch out there trying to buy codes, by far the easiest way and most effective. The news article seems to indicate the NSA is already in (and average hacks soon will be), that kinda has me thinking that there’s a problem with these encryption routines … and that maybe it has to do with how the random number generators are used. If it’s totally random, how does the receiver know what it is?
What the ???
You really need to read up about crypto before posting like this. I mean, seriously, read a couple dozen academic-level articles.
Anyway …
About the uses of streams of (pseudo) random numbers. The most important need for these are for generating keys (for things like SSL-keys, encrypting files, etc.) are one-off creation, multiple use. I.e., you need some randomish bits to secure something but then that private key is going to be used over and over. Any half decent PRNG with any useful size, unpredictable seed (last bits of a clock plus mouse motion) is going to generate a completely unpredictable key. It’s the re-use that’s the issue. The more something is used, the easier it is to exploit holes. This is why one-time pads are secure only when used one-time. Note that in this case the code breaker doesn’t have the advantage of seeing a stream of successive outputs from the random number generator.
There are situations, however, where successive outputs are used in encryption (as opposed to just generating random data for testing or some such). The encryption technique used in some WiFi systems does something like this. And of course it’s an exploitable hole.
There is an extensive field of research into randomness amplification. E.g., taking 1024 random bits to generate millions or pseudo-random bits. If done right, the result is practically indistinguishable from random. You don’t really need a random source to generate huge numbers of random bits. But you do need a pretty good starting amount. Plus some compute cycles.
It’s the later issue that is the topic here. People don’t want to spend the cycles to do things right (as well as making sure the code is correct) and are looking for easier outs. So buying a doo-dad that generates alleged high-quality PR bits is enticing. And that’s where exploits can be found. Cheap security is an oxymoron.
You can’t use public and private keys for different sorts of information, because they come in pairs, and are only usable when used together. If you want to send me something encrypted, then I tell you my public key (or more likely, you look it up in something equivalent to a phone book), use it to encrypt the information, and send it to me, and then I use my private key to decrypt it. If someone else finds out my public key, all that means is that they can send me information, too. Nobody else in the world ever needs to know my private key, no matter how much I trust them (and in fact, someone telling me that they need to know it is evidence that I cannot trust them).
Thank you Chronos, that makes better sense. I’m thinking this in an Enigma-style circuit, where both sides have to have the jumper wires set in the right connections generating the same keystream. If you keep your private key completely secret, how can anyone decrypt your message … unless you send a part of the key with the message, thus compromising the secrecy?
Or is this a case where such is good enough to foil the common hack?
Please read Public Key Cryptography before trying to respond any more. You clearly don’t understand the concept at all.
Enigma-style security is far obsolete, and used only by people who don’t know anything about security.
And this is the root problem with private key cryptography (e.g. enigma) that public key cryptography solves.
With private key crypto, there is a single key that will give you the ability to encrypt messages, and decrypt them. You and your counterparty need to share that key beforehand over some secure channel, and if you have a secure channel for sharing keys, why not just send your message over that channel and be done with it?
With public key crypto, there are two keys one that gives you the ability to encrypt messages, and another, separate key that can be used to decrypt messages, and it is “hard” to determine one key, given the other (there is some math involved that I’ll skip over). Each party creates his own key pair, and sends the encryption key out over whatever channel is available. It doesn’t need to be secured because the ability to encrypt messages without being able to decrypt them is not very useful. The decryption key never has to be transmitted to anyone ever, so you don’t have to worry about how to transmit it (although you should certainly worry about how to store it).
The concept of public key cryptography represented a sea change in the way cryptography was done and has been the standard since at least the 80s for any cryptography that matters.
I’m not sure exactly what you mean by “Enigma-style security” but from the thread it appears you mean symmetric-key cryptography (where two parties have a shared secret).
Symmetric cryptography is most certainly not obsolete, and in fact is generally used in the presence of asymmetric-key (public-private) cryptography. Asymmetric algorithms are quite slow and inefficient, and so the way they’re usually used is to safely exchange a dynamic session key, which is itself used for a symmetric algorithm. You end up with the best of both worlds: the speed of symmetric and the safety of asymmetric.
I’d read “Enigma style security” as “cryptography whose security depends on the availability of a more secure channel than the channel the messages themselves are being transmitted through”.
Even more, with Diffie-Hellman, both you and your counterparty can arrive at a session key without using a public key cryptosystem at all. (It doesn’t have the nice authentication benefits of the public key system, though).
Yep. I’m actually not sure how the numbers break down. SSL/TLS supports both RSA and D-H key exchange, but I don’t know which is most common.
At any rate, my point was just that symmetric-key is common, since we know of several techniques to exchange secret keys over an unsecured channel. Enigma would have been a lot more secure if they had those techniques at their disposal.
Yep. To encrypt a message or file PGP uses a symmetrical key which is then encrypted with the public key. The receiver decrypts the symmetrical or session key and then uses that key to decrypt the message. (All this is transparent to the user.)
As has been noted, symmetrical encryption is alive and well. But if by “Enigma-style” you mean “Enigma” then it is not used at all. Period. It would make no sense except as a toy or game.
Encryption serves two purposes: safe transmission and also safe storage. You do not need to transmit keys if you are just protecting stored information. You just need to safeguard the keys.
PGP allows both modes of encryption, symmetrical and asymmetrical, and I use both depending on the context and purpose. Using different asymmetrical keys each time for storage means that if one key is compromised it does not affect the others.
Suppose you are traveling with your laptop. Symmetrical encryption of the contents is fine because the key travels in your head with you and the laptop.
watchwolf49, you really need to learn more. Think of it this way: symmetrical encryption is like a safe box where you use the same key to put things in and to retrieve them while public key encryption is like a bank’s drop box where you use one key (public) to put things inside the box but then use a different key (private) from the inside to retrieve things.