[Survey] What is the most secure crypto algorithm?
-
The whole point is that even if an attacker knows exactly how the "system" works (how keys are exchanged, what communication channels are used) and he interceps the encrypted message, he will not be able to retrieve the original content of the message. This makes it possible to transfer sensitive data over unsecure mediums (like the internet, radio communication, phone lines, etc) where the encrypted message can easily be intercepted.
Cheers,
Marc:beer: Click to see my *real* signature :beer:
Marc: Right. Steganizing just the plaintext message into another file, makes the system essentially worthless, because all the information he needed would be right there. I think for key sync that it's a fair option because like you said, it allows sensative data to be transfered over insecure mediums. Hell, government does it all the time. :suss: It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]
-
PGP isn't an algorithm, it's essentially a message format and software implementing that format. There are several different algorithms that can be used with PGP message format.
I wasn't refering to it as an algorithm, and if I mislead you to believe that I was, I apologize. I'm simply refering to the inherant lack of security in keys generated by PGP. What I'm saying is that PGP key length usually isn't symmetrical to the length of the messsage to be encrypted. Let's say for example, you have a 2048 byte message. Now let's say you have a 56 byte key. That key repeats 36.5714285714285714285714285714286 times over the course of the encrypted output from PGP. In essence to brute force crack the message, you only need to crack the key in 14 consecutive character increment in the encoded message which is 1/4 of the key. It's an easy task to figure out where to offset to decode other parts of the message since the key length is fixed which is moreover an easy job for a brute force cracker ( these things can be written in 15 minutes ). Assuming the message is in english, the first set of characters could be a word which could be run against a dictionary of common english words. assuming you get matches, the rest of the message can be extrapolated fairly easily, before needing to crack the rest of it.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers] -
The best Encryption algorithm is mine! I invented it, it's fully coded in VB6 and it's so big, slow and complicated that it can't be wrong! If you don't believe me, try to decrypt this message: adsfklnadJKLHAQOEIRUhjlkasre098745qowek\;zx.,c\xclakjdf908a723rknjmazdfc0987qwekmnc\szdx Did you all see how safe it is? Come on, people. Any encryption or compression post MUST have a reply like this :-O I see dumb people
-
Daniel Turini wrote: adsfklnadJKLHAQOEIRUhjlkasre098745qowek\;zx.,c\xclakjdf908a723rknjmazdfc0987qwekmnc\szdx Does it say "Hello World!"? ;P
That was my post... wonder how 'Anonymous' got in there :suss:
Cheers,
Marc:beer: Click to see my *real* signature :beer:
-
I wasn't refering to it as an algorithm, and if I mislead you to believe that I was, I apologize. I'm simply refering to the inherant lack of security in keys generated by PGP. What I'm saying is that PGP key length usually isn't symmetrical to the length of the messsage to be encrypted. Let's say for example, you have a 2048 byte message. Now let's say you have a 56 byte key. That key repeats 36.5714285714285714285714285714286 times over the course of the encrypted output from PGP. In essence to brute force crack the message, you only need to crack the key in 14 consecutive character increment in the encoded message which is 1/4 of the key. It's an easy task to figure out where to offset to decode other parts of the message since the key length is fixed which is moreover an easy job for a brute force cracker ( these things can be written in 15 minutes ). Assuming the message is in english, the first set of characters could be a word which could be run against a dictionary of common english words. assuming you get matches, the rest of the message can be extrapolated fairly easily, before needing to crack the rest of it.
It's good to see kids turning their minds to wholesum activities such as programming, instead of wasting their lives in the hedonistic disciplines of Sex, Drugs, & Rock & Roll... or Sex with Drugs, or Sex with Rocks while Rolling in Drugs, or whatever new-fangled perversions you little monsters have thought up now... [Shog9 on Kid Programmers]John Aldrich wrote: I'm simply refering to the inherant lack of security in keys generated by PGP. Eh? That totally depends on which algorithm you're using and which parameters you've fed it. John Aldrich wrote: Now let's say you have a 56 byte key. That key repeats 36.5714285714285714285714285714286 times over the course of the encrypted output from PGP. That's why the cryptoalgorithms are in feedback mode. It's not like they're using simple XOR pads (but I'm sure you could make PGP support it if you're really twisted) :P John Aldrich wrote: In essence to brute force crack the message, you only need to crack the key in 14 consecutive character increment in the encoded message which is 1/4 of the key. It's an easy task to figure out where to offset to decode other parts of the message since the key length is fixed which is moreover an easy job for a brute force cracker ( these things can be written in 15 minutes ). You're totally missing the point. The time it takes to write a brute force program is not linearly proportional to the time it takes to actually find the key. If you're really obsessed about security, use RSA keys with 4096+ bits of length. That won't take 15 minutes to crack, I promise you. Maybe, just maybe in the advent of quantum computing, but we're not even close to quantum computing. Hell, they're not even sure if quantum computing will ever work! Much less if it's going to trivialize crypto cracking. All they have are guesses at best. A good keyring has several keys, each used for different purposes. You need at least one strong DSA or RSA key for signatures. I'd recommend 2048 bits at the very least. Then you should have a few more keys ranging from 512 to 4096 bits of length (in steps of 2n). Use each key for different levels of wanted security. Also, keep your private key ring out of reach. I'd say that the weakest link in PGP is how the users store their private keys. If you manage to obtain a copy of that part of the key ring, then all you have to do is to start cracking it. That will be a lot easier than to crack any RSA 2048+ bit encrypted messages. Plus, the best part is that if you manage to crack it, you'll be able to decrypt all past messages using that key ring, and possibly many future messages as well - that's why you should let them expire in a not too far away future. Also, never lose your keys, because if you find
-
OTP is perfectly secure1. but, the problems are: * you can only use the key/pad once * the key/pad must be as large as the data * the key must be random * synchronization and distribution of the key can be difficult 1 - Applied Cryptography, Page 15 -c
Be very, very careful what you put into that head, because you will never, ever get it out. --Thomas Cardinal Wolsey
Chris Losinger wrote: synchronization and distribution of the key can be difficult This part is impossible right now. You'd need quantum computing for that, which is still just theories. :) Hell, warp speed is possible too, given that we find dilithium crystals. ;) -- Yeeeeehaaaaawwwwd!
-
John Aldrich wrote: could be steganized into a dummy file, like a jpg or some such then posted on a public website. :omg: That's not really security! You might as well put your plaintext message in the jpg file!
Cheers,
Marc:beer: Click to see my *real* signature :beer:
You're absolutely right. Steganography is about obscuring information. It's mostly used for covert channels where privacy is of highest priority, not security itself. Every body knows (should know at least) that security by obscurity is not security. :) As a side node, steganography is a pretty cool thing though. I wrote a simple app that would store a bunch of information into images, without visually distorting the image. I had lots of fun doing that. :) It's amazing how much data you can store unnoticed. -- Yeeeeehaaaaawwwwd!
-
I'd like to hear an argument that another form could be stronger than OTP. Other methods have advantages over OTP like portability and verifiability but in sheer strength OTP is it. Regardz Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign' Rob Manderson wrote:
I'm not math wiz, but I'm sure you can prove that OTP is the most secure encryption algorithm. Just take two random bytes, XOR them together and compare the result with the original text. Can you deduce anything without peeking at the "key"? :) My gut feeling is that it's provably most secure way to scramble data. Especially since true randomness is involved (you can't make any estimations about the key either). -- Yeeeeehaaaaawwwwd!
-
Security really encompases several aspects. You can have the most secure system in the world (OTP) but if it becomes difficult to disseminate the key in a secure way, it's insecure. Someone mentioned placing the key in a jpg and posting it on the internet. This is a false sense of security and relies on security through obscurity (ie, if someone in your organization leaks the method of conveyance, you're screwed and you have to find a new method of conveyance. compared to public key encryption where you can simply change the key). Public key encryption allows you to make the public key public to anyone, but without the private key, it's useless. Thus, I can encrypt a message to you using your public key, but only you can decrypt it using your private key. Conversely, you can encrypt a message with a private key and decrypt it with the public key to verify it's source if the data is not sensitive, but you want to make sure it's credible. Public key encryption can be brute forced, and is susceptible to certain kinds of attacks (such as the random number generator used), but then so is something like a OTP. It's difficult to come up with a truly random source. I dislike using the term "unbreakable", because it's used way too often to mean "nearly unbreakable" or "infeasible to break". Even a one time pad is breakable, since it's possible (just astronomically unlikely) to guess the pad. Of course you can just guess the message as well with equal likelihood, which makes a OTP "effectively unbreakable". Most public key mechanisms are based on factoring prime numbers or something similar, which means that if new math, or a new kind of hardware is developed to make this task easier, your security disappears quite quickly. In my opinion, you might as well come up with your own unique algorithm over using a OTP, unless you have an extrmely secure way to deliver pads, which case you might as well just deliver the message unencrypted. A unique algoithm can also be effectively unbreakable, especially if combined with other unique algorithms. The key to making a unqiue algorithm difficult is to never use a repeating cipher, or one with a predictable pattern. Dictionary look ups are often good for this (the dictionary need not be an actual dictionary, but something like a newspaper or phone book) While this may seem, on the surface to have the same problem as issuing a pad through a public means, such as the aforementioned jpg on the internet, it has the advantage that the algorithm is not known, s
I agree with 100%. Well written! :) Erik Funkenbusch wrote: I dislike using the term "unbreakable" Unbreakable in polynomial time is my favorite. :) -- Yeeeeehaaaaawwwwd!
-
I'm not math wiz, but I'm sure you can prove that OTP is the most secure encryption algorithm. Just take two random bytes, XOR them together and compare the result with the original text. Can you deduce anything without peeking at the "key"? :) My gut feeling is that it's provably most secure way to scramble data. Especially since true randomness is involved (you can't make any estimations about the key either). -- Yeeeeehaaaaawwwwd!
Jörgen Sigvardsson wrote: Just take two random bytes, XOR them together and compare the result with the original text. Can you deduce anything without peeking at the "key"? Unless I misunderstnd ?? I don't consider that to be OTP. The method I use for OTP involves having a PAD that is as long or longer then the message. Or have I confused something ? Regardz Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign' Rob Manderson wrote:
-
Jörgen Sigvardsson wrote: Just take two random bytes, XOR them together and compare the result with the original text. Can you deduce anything without peeking at the "key"? Unless I misunderstnd ?? I don't consider that to be OTP. The method I use for OTP involves having a PAD that is as long or longer then the message. Or have I confused something ? Regardz Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign' Rob Manderson wrote:
Colin Davies wrote: Unless I misunderstnd ?? I don't consider that to be OTP. The method I use for OTP involves having a PAD that is as long or longer then the message. Or have I confused something ? Well, in this case the key (1 byte) was as long as the message (1 byte). :) I used 1 byte for simplicity :) -- Chatai. Yana ra Yakana ro futisha ta?
-
Colin Davies wrote: Unless I misunderstnd ?? I don't consider that to be OTP. The method I use for OTP involves having a PAD that is as long or longer then the message. Or have I confused something ? Well, in this case the key (1 byte) was as long as the message (1 byte). :) I used 1 byte for simplicity :) -- Chatai. Yana ra Yakana ro futisha ta?
Ok Understood now. :-) Regardz Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign' Rob Manderson wrote:
-
You're absolutely right. Steganography is about obscuring information. It's mostly used for covert channels where privacy is of highest priority, not security itself. Every body knows (should know at least) that security by obscurity is not security. :) As a side node, steganography is a pretty cool thing though. I wrote a simple app that would store a bunch of information into images, without visually distorting the image. I had lots of fun doing that. :) It's amazing how much data you can store unnoticed. -- Yeeeeehaaaaawwwwd!
AFAIK, Wave files should be great for that purpose too :)
Cheers,
Marc:beer: Click to see my *real* signature :beer: