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
Mok-Kong Shen (mok-kong.shen@stud.uni-muenchen.de)
Mon, 01 Feb 1999 16:32:10 +0100
EKR wrote:
>
> Mok-Kong Shen <mok-kong.shen@stud.uni-muenchen.de> writes:
>
> > Jim Gillogly wrote:
> > >
> >
> > >
> > > M-K Shen wrote:
> > > > Brad Kemp wrote:
> > > >>
> > > >> If there is any data loss (i.e. lost packet or corrupted disk) the
> > > >> rest of the plaintext is lost.
> > > >
> > > > I have addressed this point in a response to Jim Gillogly. If
> > > > communication line is functioning, their protocol should take care
> > > > of lost packets and retrasnsmission. Certainly my scheme does not
> > > > address hardware problems on the side of communication partners. But
> > > > that is also not addressed by other schemes, if I don't err.
> > >
> > > Taking these in reverse order: You do. It is. True enough. Not
> > > relevant to your session key scheme. Not adequately.
> > >
> > > 'Nuff said... on this end, anyway.
> > >
> >
> > I don't understand. The above was addressed to Brad Kemp. It is
> > certainly o.k. that you answered in his place. But your answer does
> > not appear to have 'substance' and I don't yet see your answer
> > to the other of my response that was addressed to you. BTW, my
> > English is unfortunately not so good as to comprehend your last
> > sentence well. Perhaps you would be kind engough to employ simpler
> > plain English for correspondce to a foreigner.
> To expand Jim's rather terse, though correct error:
>
> 1. You do err:
> 2. A large number of other session key generation schemes cope
> with packet loss adequately and resynchronize. (IPSEC comes to mind.)
> 3. Your scheme doesn't address hardware problems on the side of
> communications partners. (Incidentally, believing that this
> is the only possible cause of data loss is monumentally naive.)
> 4. Retransmission isn't relevant (or at least shouldn't be) to
> your session key generation scheme. Note that at least one
> annoying consequence of your scheme is that even if you have
> retransmission, your scheme exhibits pathological behavior
> in the case of out-of-order delivery.
> 5. You haven't addressed Jim's original message adequately.
>
> Tbe quite frank, your response to Brad indicates fairly clearly
> that you aren't very familiar with much of the communications
> security literature and as a result, you're proposing inferior
> solutions to problems that are already fairly well solved.
> Read the literature.
I suppose I expressed quite clearly from the beginning that I do
not bring forth a scheme that is meant to be superior to the
existing schemes but merely as a potentially useful method (perhaps
with quite limited but some use).
Basically I intend to avoid public key, because that technology
may not be available in certain environments. So I attempted to
find what one could do if one is in some sense quite 'poor', i.e.
having only quite minimal software facilities available. That
means one is ready to accept loss of some or quite a lot of comfort,
elegance, etc. etc. Given the ISO 7 layer model, I don't think that
lost packages or synchronization are user's concern even in normal
circumstances. For the 'poor' environment, which I envisage, one
could certainly live with that (tolerate that). The same is with
one's own hardware. (What could/would I do if at this moment my
processor becomes defect? Do I need to take that into account too?)
Please be kind enough to point out what I have not yet adequately
responded. Thanking you very much in advance.
M. K. Shen
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:25