I use a simple PRNG, and sum its state to produce an output byte, the sequence of which is xored with the plain to give the ciphertext. The PRNG has okay properties: 1M of output can't be compressed by gzip, xz, lzma or any other *nix compression tools I tried. But I haven't used the BigCrush, DIEHARD or NIST tests against this yet.
I use the RNG as the f function in a sponge construction ( like Keccak / SHA3 ) to produce a hash function. I have not tested this for avalanche property.
I use an entropy gathering method similar to that used by Keybase ( high res timing of floating point operations ) , to generate truly random bits, which I then hash to generate an IV.
My key scheduling method is the absorb component of the hash construction.
I schedule the key, encrypt the IV with the key, then schedule the IV, then encrypt the message, then append a hash of IV:plain and encrypt that.
Ignoring the problem of key exchange, I believe the strength of this symmetric stream cipher depends on the PRNG, and how hard it makes a know plain text attack to recover the PRNG's state from the recovered key stream.
The use case of this cipher is to encrypt short messages, less than 4K.
1 comment
[ 3.0 ms ] story [ 27.0 ms ] threadI use the RNG as the f function in a sponge construction ( like Keccak / SHA3 ) to produce a hash function. I have not tested this for avalanche property.
I use an entropy gathering method similar to that used by Keybase ( high res timing of floating point operations ) , to generate truly random bits, which I then hash to generate an IV.
My key scheduling method is the absorb component of the hash construction.
I schedule the key, encrypt the IV with the key, then schedule the IV, then encrypt the message, then append a hash of IV:plain and encrypt that.
Ignoring the problem of key exchange, I believe the strength of this symmetric stream cipher depends on the PRNG, and how hard it makes a know plain text attack to recover the PRNG's state from the recovered key stream.
The use case of this cipher is to encrypt short messages, less than 4K.