[Survey] What is the most secure crypto algorithm?
-
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, I think key scheduling can solve the syncronization and distribution aspects of it. a predefined set of keys can be created ahead of time with the keys all being the maximum possible length of a message. This could be steganized into a dummy file, like a jpg or some such then posted on a public website. In reality, no one, but the recipient of the messages would know what file the keys were contained in. To anyone else, it would just appear as a bloated jpg. keys could simply be discarded after a single use and the next key in the sequence used to decrypt the next message.
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]
-
I've got my money on PGP. As long as you don't give out your private key...you're fine.
Hey, what can I say? I'm a chick magnet...a babe conductor...a logarithm for the ladies. -Strong Bad from HomeStarRunner.com Essential Tips for Web Developers
PGP can be brute forced a little two easily for my tastes, since the pure and simple fact is that they key length isn't symettric to the length of the unencoded message in most cases, it would simply be a matter of finding patterns in the encoded text. Once you match up a word in the encoded text, there goes your security.
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] -
no just a block of pure random noise as long as the text as a otp the fact that the noise is unreproducable and unguessable is the key u need a new block every time u encrypt a message of course and the recipient has to have the noise block as well
Hmm, that brings us to how to issue that we get a true block of pure random white noise. No random generation system is perfect. Often, they rely on the output of some external program which is used to seed the rand() call. 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]
-
Chris, I think key scheduling can solve the syncronization and distribution aspects of it. a predefined set of keys can be created ahead of time with the keys all being the maximum possible length of a message. This could be steganized into a dummy file, like a jpg or some such then posted on a public website. In reality, no one, but the recipient of the messages would know what file the keys were contained in. To anyone else, it would just appear as a bloated jpg. keys could simply be discarded after a single use and the next key in the sequence used to decrypt the next message.
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: 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:
-
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:
ya beat me to it! :)
Be very, very careful what you put into that head, because you will never, ever get it out. --Thomas Cardinal Wolsey
-
Hmm, that brings us to how to issue that we get a true block of pure random white noise. No random generation system is perfect. Often, they rely on the output of some external program which is used to seed the rand() call. 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: No random generation system is perfect. Correction: No purely software generated "random" sequence exists... but nature will do the job: http://www.fourmilab.ch/hotbits/[^]
Cheers,
Marc:beer: Click to see my *real* signature :beer:
-
Hmm, that brings us to how to issue that we get a true block of pure random white noise. No random generation system is perfect. Often, they rely on the output of some external program which is used to seed the rand() call. 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, 100% Random doesn' exist as we all know, but effective 100% does. Forget the rand seed() methods. Lets say we record 1 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:
-
ya beat me to it! :)
Be very, very careful what you put into that head, because you will never, ever get it out. --Thomas Cardinal Wolsey
Hmm, interesting point, and I'll rebuttal that by saying that sending out a plaintext messaged in steganized file basicly renders the message completely insecure because of the fact that the spy need only to de-steganize the file, that's even taking into account that they knew what they were looking for. By steganizing the keys into another file, the potential spy is now forced to gather both the message and the keys, making more work for him, and more of a chance that he'll simply loose interest. The idea is to make the task so daunting for him. 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]
-
Hmm, interesting point, and I'll rebuttal that by saying that sending out a plaintext messaged in steganized file basicly renders the message completely insecure because of the fact that the spy need only to de-steganize the file, that's even taking into account that they knew what they were looking for. By steganizing the keys into another file, the potential spy is now forced to gather both the message and the keys, making more work for him, and more of a chance that he'll simply loose interest. The idea is to make the task so daunting for him. 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 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:
-
I'm reading thru O'Rielly's "Perl in a Nutshell" book at the moment, and happened to run accross the page detailing the various functions of Perl operators. That started me thinking about their use in encryption/decryption and sparked the curiousity in my mind about what the most secure / strongest ( I'm using these terms interchangibly ) in existance is today? My answer to this question would have to rest with One Time Pad Encryption because of the fact that it can utilize a pad of length symmetrical to the data to be encrypted and the data cannot be decrypted without the original pad text. My question to you guys is, what is your personal belief as far as what the strongest / most secure algorithm is. Some of you may think that RC6 / DES / IDEA may be stronger than OTP. I'm interested in your responses. Let's get some good, clean debate going here
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
-
I've got my money on PGP. As long as you don't give out your private key...you're fine.
Hey, what can I say? I'm a chick magnet...a babe conductor...a logarithm for the ladies. -Strong Bad from HomeStarRunner.com Essential Tips for Web Developers
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'm reading thru O'Rielly's "Perl in a Nutshell" book at the moment, and happened to run accross the page detailing the various functions of Perl operators. That started me thinking about their use in encryption/decryption and sparked the curiousity in my mind about what the most secure / strongest ( I'm using these terms interchangibly ) in existance is today? My answer to this question would have to rest with One Time Pad Encryption because of the fact that it can utilize a pad of length symmetrical to the data to be encrypted and the data cannot be decrypted without the original pad text. My question to you guys is, what is your personal belief as far as what the strongest / most secure algorithm is. Some of you may think that RC6 / DES / IDEA may be stronger than OTP. I'm interested in your responses. Let's get some good, clean debate going here
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]
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
-
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!