Re: When RSA is better than ECC...



Oleg Khovayko <"[my_last_name]"@gmail.com> wrote:

In your scenario, following way mostly effective:

[OTP-based solution]

All solutions presented so far place assumptions on the adversary's
cryptographic knowledge or their intentions, including this one. It
assumes that the adversary has little to no knowledge about
cryptography. Even if the assumption is met, an innocent-looking
decryption will likely make them suspect that this is not the real
plaintext.

I agree with Ilmari that not getting into this situation in the first
place, is the best strategy. If you're in a situation where a key is
demanded from you, you have already failed, and in many cases your fate
will be imprisonment or death anyway.


How to generate good KEY?
Most easy way -- generate file by system rand() function, and
thereafter encrypt it with any good cryptoalgorithm, like 3des/CBC, on
random key. Thereafter, cut out ~256 head and tail bytes of your file,
since many encryption programs can store in there some service
information.

Firstly, generating the key this way will not give you an OTP.
Secondly, this is a mixture of overkill and underkill. Just take output
from '/dev/random'. Although it's questionable whether this is really
an OTP, for most attackers it effectively is, because /dev/random is
(supposed to be) information-theoretically secure. I'll call this an
almost-OTP. You may choose to prefer '/dev/urandom', with which you
give up the almost-OTP properties of the system, but get much greater
speed.

If you don't have the above device files, CBC- or CTR-encrypt a stream
of zeroes. With this approach, you will give up the almost-OTP
properties, too. By the way, I recommend AES over 3DES for both speed
and security.


Greets,
Ertugrul.


--
nightmare = unsafePerformIO (getWrongWife >>= sex)

.