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:02
Mok-Kong Shen (mok-kong.shen@stud.uni-muenchen.de)
Mon, 11 Jan 1999 08:47:40 +0100
Jim Gillogly wrote:
>
> Mok-Kong Shen writes some text on how to construct stream ciphers
> that may or may not have useful cryptological properties. However,
> calling them Pseudo-OTP immediately puts the discussion into disrepute,
> because this is an attempt to carry the authority of OTP into a region
> where it doesn't apply.
>
> You're designing stream ciphers. These are not OTPs. Feel free to
> describe clever ways to come up with the keying material, but calling
> it anything to do with a OTP is -- sorry to be so blunt -- fatuous.
> That's the thing about a OTP: either it's a OTP or it's not. There's
> no such thing as a pseudo-OTP, a nearly-OTP, an almost-OTP, or any
> other qualifier.
>
> There's nothing wrong with designing stream ciphers and evaluating
> their properties, and I applaud the effort... as long as they aren't
> being flogged as snake-oil.
First of all, I don't think terminology is that extremely important.
Second, the term pseudo-random numbers is certainly well-established.
I can't see why the relation of pseudo-random numbers to (true)
random numbers would be of a different nature than the relation
of pseudo-OTP (a term I coined) to (true) OTP. (Note that a
psudo-random number sequence is 'deterministic', it is not 'random'
('stohastic') in the proper sense at all). The prefix 'pseudo'
should have conveyed enough of the proper, i.e. 'negative', meaning
to its readers. So I think its use is 'morally' justified.
>
> On a separate issue, he goes on to say:
> > I should appreciate your opinions on that
> > and suggestions of other ways of advantageously generating such for
> > applications in the future 56-bit environment.
>
> My opinion is that it has no bearing on the 56-bit environment, to
> the extent that the latter is actually going to happen; with the
> regs changing monthly, planning a long coding project based on today's
> regs would be poor time management. In any case, if the crypto presents
> NSA with a work factor greater than 2^56 it won't (today) get an
> export license from BXA, no matter how many weak components it contains.
> On the other hand, I'm working and developing as if there won't be a
> restrictive environment by the time my stuff is ready for prime time.
> Even if I put my stuff up on a controlled site, it won't be long
> before it gets overseas, thanks to anonymous remailers.
>
> Which reminds me, perhaps another good project would be a source code
> whitener, to sand off the characteristic coding fingerprints of known
> crypto export offenders.
I indicated already that if any crypto is simple enough so that
people outside of the 33 countries can easily implement themselves
(even though their average technical level is not yet as advanced
as in the 33 countries), then export regulations would have no
real effect on that. So I suppose a good guiding principle
counteracting the Wassenaar agreement is to develop easily implementable
(which presupposes easy understandability) algorithms that (either
singly or in combination) are sufficiently strong, despite the
fact that they don't exceed the 56-bit bound.
Your source code whitener, if I understood properly, is meant to
break the law without the authority being able to prosecute the
offender. My stategy is NOT to break the law at all.
M. K. Shen
> --
> Jim Gillogly
> Trewesday, 17 Afteryule S.R. 1999, 17:48
> 12.19.5.15.2, 2 Ik 15 Kankin, Fifth Lord of Night
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:02