Any pitfals of my stream cipher?

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
transmission code.
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
message.

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.
.

Relevant Pages

  • Re: Any pitfals of my stream cipher?
    ... Alice wants to send a message to Bob. ... Now the transmission code is added, ... using the shared master key. ...
    (sci.crypt)
  • Re: Any pitfals of my stream cipher?
    ... Alice wants to send a message to Bob. ... their master password to derive the session key. ... Now the transmission code is added, ...
    (sci.crypt)
  • Re: Any pitfals of my stream cipher?
    ... Alice wants to send a message to Bob. ... their master password to derive the session key. ... The final portion of the session key is an XOR mask for the transmission ...
    (sci.crypt)
  • What is insecure in this Authentication Protocol
    ... Use R as session key ... K_Ais TimeStamp encrypted using Alice's private key ... Alice decrypts this using Bob's public key and verifies Bob's identity ... later impersonate as one to the other of Alice and Bob? ...
    (sci.crypt)
  • Re: PGP Lame question
    ... >what exactly does Alice sign here that allows Bob to know that the ... >(the session key R encrypted to Bob ?) ... if Alice created the ciphertext or if Bob forged it. ...
    (sci.crypt)