Infinite One-Time Pad, is this product BS?
in [Cryptography]
|
Prev: Certificates
Next: Q: Kerchhoffs' principle
From: Vanessa on 29 Jan 2010 09:11 On Jan 29, 9:11 pm, Richard Herring <junk@[127.0.0.1]> wrote: > In message > <1c8e13fc-1ffb-4d34-8076-fc710364b...(a)z10g2000prh.googlegroups.com>, > Vanessa <vanessavertu...(a)yahoo.com> writes > > > > > > >On Jan 29, 7:09 pm, Richard Herring <junk@[127.0.0.1]> wrote: > >> In message > >> <5421171c-f6af-40f1-95af-4876a16ce...(a)m35g2000prh.googlegroups.com>, > >> Vanessa <vanessavertu...(a)yahoo.com> writes > > >> >> > QUESTION #3: How can you determine the Final Key? > >> >> > What particular cryptanalytic attack will you use? How? > > >> >> You take the cyphertext, run the same algorithms that the program uses > >> >> to decrypt it with your tentative password, until it results on a good > >> >> plaintext. > > >> >You can do such desperate attack on any cryptosystem > >> >as well. Unfortunately, in Infinite One-Time Pad, that is > >> >hopeless if you do not know the other protections (Secret File, > >> >Secret Modification, Secret Code). > > >> >You might be able to Brute Force the password of other > >> >cryptosystems but not in IO-TP. > > >> OK, a simple question for you: is the key (i.e. the "password" plus the > >> identity of the "Secret File", the "Secret Modification" and the "Secret > >> Code") as long as the plaintext? Yes or no? > > >The Plain Text changes in length after compression and transformation. > > Not relevant. > > >The Key is as long as the Transformed Text. > > I think you misunderstood. The key _stream_ of a stream cipher is > necessarily as long as the text it enciphers. I'm asking about the total > length of the secret information that the user has to remember. > It depends on the secret information. Better download the software to understand it well. > >You will be attacking the > >Transformed Text not the Plain Text. Password, Modification, Secret > >Code > >could be any length. > > So it's not required to be as long as the plaintext? The Plaintext is not as long as the transformed text. > > -- > Richard Herring- Hide quoted text - > > - Show quoted text -
From: Vanessa on 29 Jan 2010 09:32 On Jan 29, 10:02 pm, Bruce Stephens <bruce +use...(a)cenderis.demon.co.uk> wrote: > Vanessa <vanessavertu...(a)yahoo.com> writes: > > [...] > > > The Plain Text changes in length after compression and transformation. > > Other systems (such a GnuPG) also perform compression before encryption > (by default), so that's normal. > > This "transformation" idea seems useless. If it varies (using some key) > then it's just part of the encryption. If it's fixed by the software > then you should assume that an attacker knows what it is, so it's > useless. Your assumptions are wrong. Download a copy of the software, study it and you will know. > > > The Key is as long as the Transformed Text. You will be attacking the > > Transformed Text not the Plain Text. Password, Modification, Secret > > Code could be any length. > > Sounds like an unnecessarily complex system. Surely it's much safer > either to use OTP or to use AES. By all means add compression, too (as > most systems do, in practice), and you probably want to add in > authentication. So reasonable advice would be (as everyone has said), > use OpenPGP (implemented as GnuPG, probably). It's free, well-studied, > well-regarded. Nobody is forcing you to use Infinite One-Time Pad. Sure those cryptosystems can serve you well. But if you want extreme protection, use Infinite One-Time Pad. It has authentication system too. I think I have already presented how Infinite One-Time Pad works to the best of my knowledge. I hate keep on explaining things that I have already explained. I feel that we are moving in circles and achieving nothing. I shall leave this forum now. Okay, people in this forum, again, thanks for your time. Bye.
From: Jeroen Belleman on 29 Jan 2010 09:41 Vanessa wrote: > > The key and the password must be correct. If one is wrong, it > won't decrypt. So the key depends on the password by means of your famous transformations and you *still* need the password and the key together to transcrypt. Sounds pretty redundant. Redundancy is bad in cryptography. Anyway, you should realize that anyone sufficiently interested in your data can pick apart your algorithms. Therefore, security depends entirely on the entropy of the key stream. From what you told us previously, it looks like all these transformations destroy a sizable amount of this entropy. There is no way, short of actually taking the time and doing the work, by just how much. As I said previously, I do not have the incentive to do that. >> [...] Surely you do not pretend the transformation >> plain text -> transformed text or its reverse is secure too? >> >> Jeroen Belleman > > Sorry, I cannot get your point here. I think better download the > software to understand how it works before asking questions. There is no point. I feel safer relying on PGP, or some such. Jeroen Belleman
From: Paulo Marques on 29 Jan 2010 10:08 Vanessa wrote: >>> QUESTION #2: How can you determine the password? >>> What particular cryptanalytic attack will you use? How? >> Selective brute force, starting with more probable passwords. > I say again, the length of the password is not limited. The > password is up to the user. If the information is too critical, > then he should use a long and strong password. This is certainly not working, so I'll try a different approach. Imagine a different system: - the software generates a 1024 bit random public / private key pair using RSA. You type a passphrase and strengthen it by running a sha-256 over it 10000 times and use the result as a key to encrypt the private key using AES. - if you want to encrypt one file, the software just generates two random 256 bit keys, and use one key with AES to encrypt the file and the other to authenticate the file using some well tested MAC. Both keys are encrypted with the public key of your RSA step above and stored together with the encrypted file. - if you need to send a file to someone, just ask that someone for their public key, and use that to encrypt the file and send it to that person. The public key can be sent in the clear without compromising the system. Now I ask you the same question you've asked me: how can you break that system? The difference is, I already know the answer: _YOU_ CAN'T! And neither could any of the best cryptographers in the worldwide cryptographic community that tried it in the last years. The people that developed all the cryptanalysis tactics that you pointed us to, couldn't break this. In this system, you don't need to drag secret files around and you can send keys in the clear to third parties. Moreover, you need just one passphrase for _all_ your files. Reusing the same passphrase doesn't weaken the system, because the passphrase isn't used at all to encrypt the file. The way to attack it would be to brute force the password. This is under the same assumption that the attacker was able to steal the laptop that keeps your private key file, since without that is game over. However in this system, the resources needed to brute force the password are pretty well defined: you need to run 10000 SHA-256 in sequence to test one password. You can even increase this as trade off in security / speed. As you say: "bigger passwords are safer". Well, duh! The point is, for the same password, the amount of time it takes one attacker to crack it depends on how the algorithm uses it. If to try one password on IOTP it takes a few thousand clock cycles, and in this system it takes a few millions, then this system is safer with respect to brute force attacks on the password. And you know what? You can get this system for free! Just download GnuPG and use it. No cumbersome secret files, no cumbersome key transformations, nothing. Just one carefully selected passphrase to securely encrypt all of your files (and sign emails, etc.)! Of course, the attacks on GnuPG that are most likely to succeed (assuming you selected a high-entropy passphrase) are side-channel attacks: - what happens to your keys in memory when you turn off the power of your laptop? - are the keys placed in memory areas that can not be swapped to disk? - can another process running on the machine (like a virus) determine the key from the cache access patterns? - etc., etc. GnuPG is a mature software that already tries to minimize side-channel attacks, by locking the memory for the keys, clearing key material as soon as possible, etc. Since in this whole thread no one as ever mentioned any kind of effort on IOTP to avoid side-channel attacks, we can only assume that it is vulnerable to them, as the author wasn't even aware of the possibility. BTW, you keep saying: "just download the software and try it out". Do you have any idea of the risks you take when you download a random piece of software from the internet and run it on your computer? How can you be sure that the software is not a Trojan that opens a backdoor to your computer to make it become part of a bot-net? Yes, I could try it on a virtual machine, snapshotted and isolated from the network, but I haven't seen a single argument that makes me believe that it is worth the trouble... -- Paulo Marques - www.grupopie.com "667: The neighbor of the beast."
From: Richard Herring on 29 Jan 2010 11:11
In message <f47f7dc0-cc81-4a90-9736-4ab278c4f65c(a)p13g2000pre.googlegroups.com>, Vanessa <vanessavertudez(a)yahoo.com> writes >On Jan 29, 9:11 pm, Richard Herring <junk@[127.0.0.1]> wrote: >> In message >> <1c8e13fc-1ffb-4d34-8076-fc710364b...(a)z10g2000prh.googlegroups.com>, >> Vanessa <vanessavertu...(a)yahoo.com> writes >> >> >> >> >> >> >On Jan 29, 7:09 pm, Richard Herring <junk@[127.0.0.1]> wrote: >> >> In message >> >> <5421171c-f6af-40f1-95af-4876a16ce...(a)m35g2000prh.googlegroups.com>, >> >> Vanessa <vanessavertu...(a)yahoo.com> writes >> >> >> >> > QUESTION #3: How can you determine the “Final Key”? >> >> >> > What particular cryptanalytic attack will you use? How? >> >> >> >> You take the cyphertext, run the same algorithms that the program uses >> >> >> to decrypt it with your tentative password, until it results on a good >> >> >> plaintext. >> >> >> >You can do such desperate attack on any cryptosystem >> >> >as well. Unfortunately, in Infinite One-Time Pad, that is >> >> >hopeless if you do not know the other protections (Secret File, >> >> >Secret Modification, Secret Code). >> >> >> >You might be able to Brute Force the password of other >> >> >cryptosystems but not in IO-TP. >> >> >> OK, a simple question for you: is the key (i.e. the "password" plus the >> >> identity of the "Secret File", the "Secret Modification" and the "Secret >> >> Code") as long as the plaintext? Yes or no? >> >> >The Plain Text changes in length after compression and transformation. >> >> Not relevant. >> >> >The Key is as long as the Transformed Text. >> >> I think you misunderstood. The key _stream_ of a stream cipher is >> necessarily as long as the text it enciphers. I'm asking about the total >> length of the secret information that the user has to remember. >> > >It depends on the secret information. Better download the software to >understand it well. > >> >You will be attacking the >> >Transformed Text not the Plain Text. Password, Modification, Secret >> >Code >> >could be any length. >> >> So it's not required to be as long as the plaintext? > >The Plaintext is not as long as the transformed text. I don't care about that. Is the *secret information* as long as the plaintext? Yes or no? -- Richard Herring |