>>Warning Sign #6: One-time pads. These days we can buy 128GB pendrives (i.e. very long pads) for $35.
This simple approach seems viable to me: https://www.codeandsec.com/Poor-Mans-Unbreakable-Encrypted-TCP-Tunnel Regards, q On Fri, Mar 20, 2015 at 10:42 AM, Michael Kjörling <[email protected]> wrote: > On 19 Mar 2015 16:10 -0400, from [email protected] (Kevin): >> On 3/19/2015 4:00 PM, Ben Lincoln (F70C92E3 - Cryptography ML) wrote: >>> There's no demo version available, but based on the screenshots and the >>> information on the site, it looks like it's using a "one-time pad" >>> generated using a PRNG or other sequence-generator seeded with a key >>> generated by the application, and it's the key that's exchanged. >> >> I assume it uses your hardware to generate the random value. > > It doesn't matter how the PRNG works. If it's seeded by a key, and the > pad is regenerable given the key (which it sounds like given the > description), then it's not an OTP, and you get _at the very best_ 2^k > bits security (where k is the number of entropy bits in the key) > rather than a proper OTP's 2^n bits security (where n is the length of > the message, in bits). > > The reason why a OTP is provably secure in theory (in the > confidentiality sense of secure) is that the key _is_ as long as the > message and completely random; thus you cannot tell whether a key you > just tried is valid without already knowing the plaintext message, in > which case there really is no point to the exercise to begin with. > > Combining a seeded PRNG with a simple operation on the PRNG output and > the plaintext or ciphertext is how stream ciphers work. > > Now, something like a decent KDF feeding a key into AES running in > counter mode to generate a ciphertext stream which is then used as a > key for encryption in a stream cipher-like construct is _probably > reasonably_ (_very heavy_ emphasis on "probably") secure, and not too > dissimilar from what is hypothesized above. But at that point, you > might just as well use the fairly well-proven AES directly; it will be > marginally faster given identical hardware and otherwise identical > software (since you avoid your extra algorithm, and AES is often > hardware-accellerated on modern CPUs) and it will be at least equally > secure (because the security of the ciphertext in the combined scheme > will be totally dependent on the security of the stronger algorithm > pass anyway -- see Kerckhoffs' principle -- and most people are > unlikely to come up with something that is _more_ secure than AES > against any type of attack, much less all types of attacks). And it > absolutely is _not_ a one-time pad. > > -- > Michael Kjörling • https://michael.kjorling.se • [email protected] > OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp > “People who think they know everything really annoy > those of us who know we don’t.” (Bjarne Stroustrup) > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
