[cryptography] Unbreakable crypto?

Enrique Soriano esoriano at lsub.org
Fri Mar 20 07:02:28 EDT 2015


>>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 <michael at kjorling.se> wrote:
> On 19 Mar 2015 16:10 -0400, from kevinsisco61784 at gmail.com (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.semichael at kjorling.se
> 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
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography


More information about the cryptography mailing list