Re: A Method of Session Key Generation

New Message Reply About this list Date view Thread view Subject view Author view

mok-kong shen (mok-kong.shen@stud.uni-muenchen.de)
Mon, 01 Feb 1999 08:49:50 +0100


Jim Gillogly wrote:
>

> I said that the suggested system is no more secure against a known plaintext
> attack than (say) using a master key to encrypt a cleartext nonce to get the
> session key for that message.

How secure is then the (ordinary) messages encrypted with a session
key (with whatever method you employ) with respect to the same
type of attack? As I said, since the volume encrypted by the master
key is small and one can use a secure hash method, the master key is
highly secure (much more compared to the session key encryption).
Note that there is no perfect security, not even the public key
technology can offer that. (As mentioned, the intention is to
avoid public key.)

> In that if the recipient can read the current message, he's assured that
> he has the entire conversation on both sides? True enough, but that's
> a bug rather than a feature. Consider the following exchange:
>
> Msg ?->? Time Key Plaintext
> 1 A->B 0305 E(Init) Hi, here's my first message, with the key we agreed
> on.
> 2 B->A 0310 E(H(1)) Works great! Let's start a conspiracy or porno
> ring!
> 3 A->B 0312 E(H(1,2)) Good plan! Details to follow.
> 4 B->A 0314 E(H(1..3)) OK, I'll look forward to 'em.
> 5 A->B 0314 E(H(1..3)) You go buy the ammonium nitrate, and I'll get the
> girlz.
> 6 B->A 0316 E(H(1..4)) What? Please repeat?
> 7 A->B 0320 E(H(1..5)) Your last message garbled. Please repeat.
> 8 B->A 0325 E(H(1..4,6)) Hello??
> 9 A->B 0330 E(H(1..5,7)) Hello??
>
> Yes, there are ways to get re-synched, but (a) you need to specify them,
> and (b) you've gone to a lot of work to achieve something you really don't
> want to achieve... i.e. sensitive dependence on a shared idea of the complete
> plaintext exchange. One thing you <don't> want to do is put the burden on
> the lowly code clerk at each end to try a bunch of plaintext permutations to
> try to guess what key was used in the last message.

The session key can depend on plaintexts sent by one partner
alone. (Similarly the other way.) There is no protocol. All that can
be automated. I don't see the burden by the code clerk you mentioned.
One problem is that if one message is lost, then the following
messages can't be read. But it is in fact intended to check that way
that the communication is o.k. And if a message is lost, one can ask
for repeat. Since all is automated there can hardly be error due to
mistakes in retransmission that could be of concern. Further critiques
are sincerely solicited.

M. K. Shen


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:25