Any pitfals of my stream cipher?
- From: Captain Data <sorry@xxxxxxxxxx>
- Date: 24 Jan 2010 10:51:25 GMT
Any problems with this proposed setup?
Alice wants to send a message to Bob. In the past they have either
meeting each other to agree on a secret master key, or via an
asynchronous encryption system perhaps, so they have some shared secret
but it is no where near big enough to use as a OTP. Maybe it is just a
shared password or something.
Alice has a presumably-truly random number source, and wants to send
encrypted messages to Bob every so often.
1) Alice grabs a truly random number (probably doesn't have to be truly
random but it will be in this example)
2) Alice sends this value directly to Bob as cleartext
3) Now both Alice and Bob use this value as a salt, with which they use
their master password to derive the session key.
If the hash algorithm (WHIRLPOOL) isn't broken then this should be
perfectly safe. Random numbers *probably* mean no same value twice, at
least not predictably.
4a) Alice uses the first portion of this session key to seed a PRNG to
generate a keystream. The PRNG is presumed to probably not generate any
detectable patterns until maybe around 13kb of output or so.
4b) Another portion of the session key is used as a negative offset on
the default number of bytes to transmit before expiring the session key.
4c) Another 2 portions of the session key are reserved for the MAC.
4d) The final portion of the session key is an XOR mask for the
5) Once the final length is reached, a certain portion of truly random
data is added to the end of the message so far.
6) Now the transmission code is added, more on this soon.
7) Now Alice appendeds the MAC using the 2 session key portions, skp1,
skp2. MAC = hash(skp1.hash(skp2.message)), where "." means concantenation.
8) So now the MAC covers the portion of the message in this transmission,
the transmission code, and the truly random "salt" to generate the next
successive session key from, using the shared master key.
So on and so forth.
Normally the transmission code is just zero (after re-applying its XOR
mask from the session key), to indicate that this is not the final
However, when the transmission code is not zero, it is used as a negative
offset to separate what portion of the final transmission session is the
end of the message, and the rest is just junk.
I think that so long as the hash and the PRNG are not rubbish, then the
only way is to brute force the master key, and that a malicous guy
"Martin" cannot get anything out of sending bogus transmissions to Bob,
or by recording or altering the transmissions between Alice and Bob.
And that Alice and Bob can keep the same master key for as long as they
are comfortable with.
- Prev by Date: Re: New mode for AES: "Packet Mode"
- Next by Date: Re: Any pitfals of my stream cipher?
- Previous by thread: CryptoAnalysis Game4: Crack the attack plan ! (+machines)
- Next by thread: Re: Any pitfals of my stream cipher?