Cryptography-Digest Digest #193, Volume #9 Sat, 6 Mar 99 02:13:04 EST
Contents:
Re: Clipper doubleplusungood...Your Honor, I plead the 4th ("Jay")
Re: Quantum Computation and Cryptography (Henry Lewsal)
Re: An export question... (Henry Lewsal)
Re: Securid Card (Loomis Farkle)
Good source for random bits ([EMAIL PROTECTED])
Re: An export question... (Kent Briggs)
Non linear dynamic systems random number generator (Stoned Nick Vlassopoulos)
Re: An export question... ("Tom")
Re: my algorithm (document) (Scott Fluhrer)
Re: Quantum Computation and Cryptography ("Douglas A. Gwyn")
Re: Intel/Microsoft ID (Mark McCutcheon)
Re: Good source for random bits ("Douglas A. Gwyn")
Re: Common meaning misconception in IT, was Re: Unicity of English, was Re: New
high-security 56-bit DES: Less-DES (rosi)
Re: My Algorithm ([EMAIL PROTECTED])
USENIX Security Symposium: Submission deadline extended to March 16 (Jennifer Radtke)
Re: Securid Card (Paul Rubin)
Re: Opinions on Microsoft's CryptoAPI? (Lincoln Yeoh)
Re: An export question... ("Tom")
----------------------------------------------------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Subject: Re: Clipper doubleplusungood...Your Honor, I plead the 4th
Date: Fri, 5 Mar 1999 19:17:45 -0500
Doggmatic wrote in message <7bpbe7$72k$[EMAIL PROTECTED]>...
>, how hard would
>it be to slip an Infinity transmitter into the set-up. Infinity
transmitters
>allow the affected phone to be called, but if the caller transmitted a
>certain frequency (the note 'C' on a harmonica was common), then the
affected
>phone would not ring, but would would act like it were off-hook, so that
the
>caller could hear whatever sounds the affected phone picks up.
Most current phones in the US at least use a physical switch in the body.
This cannot be bypassed remotely though I understand that the European phone
standard has provision (so far largely unimplemented) for that capability.
Jay
------------------------------
From: Henry Lewsal <[EMAIL PROTECTED]>
Subject: Re: Quantum Computation and Cryptography
Date: Fri, 05 Mar 1999 20:46:02 -1000
Douglas A. Gwyn wrote:
>
> Benjamin Johnston wrote:
> > I read somewhere, a while ago, that Quantum computers, if or when they are
> > created, will turn an otherwise difficult factorization into a trivial task.
> > Will all the current cryptosystems be outdated, the instant a stable and
> > practical quantum computer is created?
>
> Even if that dubious claim is accepted, it doesn't affect cryptosystems
> that are based on entirely different principles than RSA.
>
> > Does anybody have any personal opinions/predictions about the ramifications
> > of such new technology/s.
>
> There are no ramifications if they never get it to work.
It is likely that it will never be practical for ciphers like MARS.
" The first condition for any deterministic device
to be reversible is that its input and output be uniquely
retrievable from each other. This is
called logical reversibility. If, in addition to being
logically reversible, a device can actually
run backwards then it is called physically reversible and
the second law of thermodynamics
guarantees that it dissipates no heat. "
from
http://chemphys.weizmann.ac.il/~schmuel/comp/node2.html#SECTION00020000000000000000
Most of the quantum logic gates I read about that correspond to
boolean gates are XOR gates. XOR gates cannot be used to make NAND
gates. NAND gates are a basic gate type that can be used to make
digital computers with today's architectures. We cannot make
microprocessors using only XOR gates. XOR gates have a truth table
like a mirror, so reversibility is possible. NAND gates have
asymmetric output values which are less likely to ever be reversible.
Until reversible NAND gates are invented and demonstrated, I doubt
the general purpose capabilities of quantum computers. I hope someone
will show us who has built them, and not just a rumor, I want facts.
------------------------------
From: Henry Lewsal <[EMAIL PROTECTED]>
Subject: Re: An export question...
Date: Fri, 05 Mar 1999 20:56:08 -1000
Tom wrote:
>
> Jim Gillogly <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]>...
> > Tom wrote:
> > > What I've been unable to determine
> > > is if MD5 or any other strong hash is exportable from the US without a
> BXA
> > > review. .
> >
> > My assumption is that MD5 and SHA-1 do not require any export licensing
> > or review from BXA, based on Category 5 (Part 2) Section A:
SHA-1 can be used for data encryption. Therefore it is export controlled.
It is called "counter mode" and it makes a stream cipher. Your key
will be a 160 bit number that is hashed. XOR the plaintext with the
160 bit hash to get ciphertext. Send the ciphertext to someone who has
the key. The key is incremented to recover each 160 bit block of
plaintext using XOR between the ciphertext and the hash of the counter.
What is not export controlled is embedded SHA-1 that cannot be used
in this way due to its inaccessibility in embedded hardware.
This is not legal advice. I am not an attorney.
------------------------------
From: Loomis Farkle <[EMAIL PROTECTED]>
Subject: Re: Securid Card
Date: 6 Mar 1999 04:21:47 GMT
In article <[EMAIL PROTECTED]> Paul Rubin, [EMAIL PROTECTED] writes:
>>Does anyone know what the protocol is in these cards? Is it encrypting
>>my PIN with a public key and the server is decrypting it with a private
>>key and matching it to the password database? Is it symmetric with the
>>PIN being the key and the only real defense being the rapidly changing
>>plaintext/ciphertext in the card?
>
>Symmetric key with the key being inside the card (the server has to
>know the card's serial number).
>
That answers one question but brings up another: How does the server know
the card's serial number? When we first register these cards (via a PPP
connection, so no reader is involved), we are supposed to enter the
6-digit number on the card LCD and tell the server we are in New PIN
Mode. Does that number contain the card's serial number? What is the
time-based algorithm doing? Is it mixing the time with something
internal to the card (serial number?, symmetric key?) to produce a
time-varying symmetric key?
>>Since this system relies rather heavily on the card and the server being
>>in sync, what is the accuracy of the card's time function?
>
>Similar to a digital watch. The server notices as the card's clock
>drifts, and adjusts for this.
>
How would the server be able to notice the clock drift? There's a
potential of having several thousand users in this system -- would the
server really be deducing clock drift info from a 6 digit number that
also has to contain an authentication and keep a database on all the
users?
Sorry for all the questions. I don't often get crypto gear in my hands
(and they won't let me take apart the STU phone), so I like to know just
how the stuff works.
------------------------------
From: [EMAIL PROTECTED]
Subject: Good source for random bits
Date: Fri, 05 Mar 1999 23:41:33 GMT
I was thinking (yes it happens) about some good sources for random bits. I
read somewhere that the LS bits of audio is good, but wouldn't better be live
sources like radio? Since if you use white noise that isn't terribly random.
I was thinking has anyone ever made a 'kit' for this type of application? I
was thinking of making a 8051 system with a couple ADC's for sound,
temperature and other devices. It could plug only the 1-2 LS bits from each
ADC, and pseudo randomly switch between sources.
Wouldn't that be cool?
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: An export question...
Date: Sat, 06 Mar 1999 00:58:25 GMT
Tom wrote:
> Still, I wonder why the SHA-1 spec contains the
> "export restrictions may apply" clause. Perhaps it's just FUD. :)
Probably because a hash function could be used as a block cipher if implemented
in a certain way. Schneier talks about it in section 14.11 of "Applied
Cryptography".
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Stoned Nick Vlassopoulos <[EMAIL PROTECTED]>
Subject: Non linear dynamic systems random number generator
Date: Sat, 06 Mar 1999 02:02:50 +0200
Well, this is an idea i came up with recently ....
What if one uses a non-linear dynamic system as a random number
generator...
Take as an example a 3 or 4 bodies movement simulation in a closed 3d
space
("closed" means that everything that crosses the space bounderies is
mirrored
on the other side of the space)... One could use the initial conditions
(velocities &
positions) as a key and the resulting positions (or velocities or both)
as the random
numbers ... Any slight change in the initial conditions should result to
a completely
different way of movement, since the system diverges ...
I don't know ...
Any ideas ???
Nick Vlassopoulos
[EMAIL PROTECTED]
------------------------------
From: "Tom" <[EMAIL PROTECTED]>
Subject: Re: An export question...
Date: 5 Mar 1999 23:54:30 GMT
Jim Gillogly <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]>...
> Tom wrote:
> > What I've been unable to determine
> > is if MD5 or any other strong hash is exportable from the US without a
BXA
> > review. .
>
> My assumption is that MD5 and SHA-1 do not require any export licensing
> or review from BXA, based on Category 5 (Part 2) Section A:
Thanks... I did read this section and hoped that it wasn't going to be
contradicted elsewhere or that the rules had changed in another document.
> By way of warning, I've also been told that the State Dept., when
> it was in control of this stuff, did issue at least one export
> license allowing somebody to export SHA-1, which suggests that somebody
> there thought they had jurisdiction. That interpretation appears to
> violate the spirit of the EAR language, which appears to address the
> issue of crypto algorithms to provide confidentiality only.
This is where my confusion original came from. The SHA-1 spec refers to
export restrictions... yet I couldn't find ANY references to them anywhere.
I really wonder if there is a clear set of documents that exist on this
subject.
> My interpretation appears to be shared by Ron Rivest, whose Chaffing
> and Winnowing proposal is based on the assumption that authentication
> algorithms are explicitly not covered by the EARs.
Yes, I'm familiar with it... a very novel concept. Actually, this is one
of the reasons I was concerned that the "official" view of hash algorithms
may have changed. What was most interesting about his paper, however was
not so much the actual scheme he proposed but how creatively he molded and
shaped an incongrueous technology to surmount a given set of restrictions.
To me this seemed akin to rhyming poetry or lyrical songwriting where
complex thoughts must expressed using a severely limited subset of a given
language. Although they sometimes seem worlds apart, I suppose that
creativity is the uinversal currenty of both the arts and sciences.
>
> Disclaimers: Don't bet your freedom on legal advice you get free on
> the Net. This is not legal advice and I am not a lawyer. I resent
> having to put in all these weasel words. I am never heartbroken when
> somebody violates or circumvents the U.S. encryption export regulations
> in any way, but I don't explicitly encourage that naughty behavior.
I really apprecate all the information and comments you've taken time to
provide here... and your disclaimer! :)
Best regards,
Tom
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: my algorithm (document)
Date: Sat, 06 Mar 1999 01:31:31 GMT
In article <7bpmhm$h62$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>I wrote a small and simple text document to accompany it. I plan to update
>the text. I am still new (*please remember that*) so as I learn more I will
>update it. The basic algorithm is described. I would like to go more into
>depth of my algorithm.
Gee, that sounds neat. If you actually posted something about your algorithm,
someone might actually be able to comment on it...
--
poncho
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computation and Cryptography
Date: Sat, 6 Mar 1999 01:16:56 GMT
Benjamin Johnston wrote:
> I read somewhere, a while ago, that Quantum computers, if or when they are
> created, will turn an otherwise difficult factorization into a trivial task.
> Will all the current cryptosystems be outdated, the instant a stable and
> practical quantum computer is created?
Even if that dubious claim is accepted, it doesn't affect cryptosystems
that are based on entirely different principles than RSA.
> Does anybody have any personal opinions/predictions about the ramifications
> of such new technology/s.
There are no ramifications if they never get it to work.
------------------------------
From: [EMAIL PROTECTED] (Mark McCutcheon)
Subject: Re: Intel/Microsoft ID
Date: 5 Mar 1999 15:21:49 -0800
In Message <7bodiv$[EMAIL PROTECTED]> "Jay"
<[EMAIL PROTECTED]> writes:
| Roger Schlafly wrote in message <7bo56b$jdu$[EMAIL PROTECTED]>...
| >
| >Hmmm. NYTimes is free to everybody. You just have to
| >register.
| >
| Last I heard (maybe 6-8 months ago) it was only free to US residents. Non US
| residents had to pay for access.
That seems to have changed. I was able to register from a
Canadian site gratis as of about a month ago.
Mark
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Good source for random bits
Date: Sat, 6 Mar 1999 01:35:14 GMT
[EMAIL PROTECTED] wrote:
> ... Since if you use white noise that isn't terribly random.
Why is that? One would think white noise is pretty darned random.
------------------------------
From: rosi <[EMAIL PROTECTED]>
Subject: Re: Common meaning misconception in IT, was Re: Unicity of English, was Re:
New high-security 56-bit DES: Less-DES
Date: Fri, 05 Mar 1999 21:18:33 -0800
Peter Pearson wrote:
>
> In article <7bkvts$e6l$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> > Bryan Olson <[EMAIL PROTECTED]> wrote:
> ...[snip]...
> >
> >But, it is no surprise that you are again confusing issues before this list
> >-- instead of learning things first. It is fine to ignore basic facts and
> >perhaps you can learn a lot more just by reading and asking questions. I
> >believe you will receive a lot more attention and much improved answers once
> >you start to truly communicate. Just trust yourself a bit more, in a fair
> >dialogue -- if you do not understand something -- ask. By the current odds,
> >as in the archives, if you do not understand something then most ptobably the
> >problem lies at your side... so, give yourself a chance.
> >
> >Ed Gerck
>
> Please refrain from using this newsgroup to broadcast personal
> insults, particularly personal insults directed at one of our most
> scholarly contributors.
>
> - Peter Pearson
Dear Peter,
(I can be very wrong).
Read the first couple of this thread, then did not for days.
From what I read, everything so far seems to be quite scholarly.
The word 'insults' and 'personal insults' may not be quite appropriate.
People are addressing one another and saying what one thinks of what
another thinks.
'broadcast' is part of the purpose here.
Everybody can make his point and view known, perhaps in any manner
one wants. Some may be viewed better, some not so. Everybody is allowed
to make mistakes. (Am not saying any did)
Mathematics is for truth; and a mistake is no more just a mistake if
one knows it to be a mistake and persists in it. (Am not saying anyone
is like that, but the way the discussion is conducted seems to me
acholarly and acceptable).
I honor your point of view; just want to 'broadcast' mine as well.
Thanks
--- (My Signature)
P.S.
Believe (without much math background) that Shannon's is formal, so
interpretation should be one and not ambiguous.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My Algorithm
Date: Sat, 06 Mar 1999 01:36:08 GMT
First off, it's not that I am a idiot. I know the basics of crytology. I
just don't have the money to buy books. I wrote the algorithm because I
believe it solves many simple encryption problems. If you don't want to look
at the code, don't. But I believe given it's simplicity it may take an hour
or two at the most. I just want general ideas and impressesions.
Second, if I were to patent it I wouldn't ask for your help. But I don't plan
to patent things. I don't believe in patents (except for allowing free use).
'standard rates' for spending 20 minutes? I just wanted people to glance at
it.
You have a valid point in saying amateurs can't make drugs, but can't amateurs
make radios? computer games? music?. I am not trying to replace DES or
anything from AES, I would just like some people to look at my encryption
algorithm. Maybe it's been written before and it's been cracked....
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Crossposted-To: muc.lists.www-security,ocunix.mail.freebsd.security
From: [EMAIL PROTECTED] (Jennifer Radtke)
Subject: USENIX Security Symposium: Submission deadline extended to March 16
Date: Sat, 6 Mar 1999 01:34:33 GMT
8th USENIX Security Symposium
August 23-26, 1999
Washington, D.C., USA
Sponsored by USENIX in cooperation with The CERT Coordination Center
If you are working on any practical aspects of security or applications
of cryptography, the program committee urges you to submit a paper.
====================================================================
Dates for Refereed Paper Submissions
Paper submissions due: March 16, 1999 --Extended
Author notification: April 27, 1999
Camera-ready final papers due: July 12, 1999
====================================================================
Please find the Call for Papers at
http://www.usenix.org/events/sec99/
The Symposium brings together researchers, practitioners, system
administrators, system programmers, and others interested in the latest
advances in security and applications of cryptography. Two days of
tutorials will be followed by two days of technical sessions, offering
refereed papers, invited talks, works-in-progress, panel discussions,
and a product exhibition.
Invited Talk Speakers include:
Ross Anderson, Computer Laboratory, Cambridge University
Ed Felten, Princeton University
Susan Landau, University of Massachusetts
Peter G. Neumann, SRI
Paul Van Oorschot, Entrust Technologies
Marcus Ranum, Network Flight Recorder
====================================================================
USENIX is the Advanced Computing Systems Association. Our international
membership includes engineers, system administrators, scientists, and
technicians. Our conferences are recognized for delivering pragmatic,
technically excellent information in a highly interactive,
vendor-neutral forum.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Securid Card
Date: Sat, 6 Mar 1999 06:58:19 GMT
In article <7bqagr$2j6$[EMAIL PROTECTED]>,
Loomis Farkle <[EMAIL PROTECTED]> wrote:
>>Symmetric key with the key being inside the card (the server has to
>>know the card's serial number).
>>
>That answers one question but brings up another: How does the server know
>the card's serial number? When we first register these cards (via a PPP
>connection, so no reader is involved), we are supposed to enter the
>6-digit number on the card LCD and tell the server we are in New PIN
>Mode. Does that number contain the card's serial number? What is the
>time-based algorithm doing? Is it mixing the time with something
>internal to the card (serial number?, symmetric key?) to produce a
>time-varying symmetric key?
I don't know the details. I don't know if they're published.
I kind of remember you get a list of card serial numbers when
you buy a set of cards, and someone managed to figure out some
things from one of those lists.
>How would the server be able to notice the clock drift? There's a
>potential of having several thousand users in this system -- would the
>server really be deducing clock drift info from a 6 digit number that
>also has to contain an authentication and keep a database on all the
>users?
Yes, that's not a terribly large database by today's standards.
I've never administered one of these systems though, so I'm not
up on everything.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Opinions on Microsoft's CryptoAPI?
Date: Sat, 06 Mar 1999 06:58:07 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 01 Mar 1999 18:59:37 GMT, [EMAIL PROTECTED] (Paul) wrote:
>Are there any opinions on Microsoft's CryptoAPI?
>
>Paul
>
Peter Gutmann's page:
http://www.cs.auckland.ac.nz/~pgut001/
http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms.txt
http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms2.txt
http://www.cs.auckland.ac.nz/~pgut001/pubs/breakms3.txt
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: "Tom" <[EMAIL PROTECTED]>
Subject: Re: An export question...
Date: 6 Mar 1999 02:44:17 GMT
Kent Briggs <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> Tom wrote:
>
> > Still, I wonder why the SHA-1 spec contains the
> > "export restrictions may apply" clause. Perhaps it's just FUD. :)
>
> Probably because a hash function could be used as a block cipher if
implemented
> in a certain way. Schneier talks about it in section 14.11 of "Applied
> Cryptography".
That was enlightening... thanks again. I hadn't read that section and now
it's pretty clear where that "restrictions may apply" stuff came from.
I've seen SHA-1 used in this way before in a large package that I once
reviewed but I didn't know how secure the technique was. Appearantly the
encryption strength can be as good as the hash itself... so I can see where
a hash used in this way could easily create an export issue.
Nothing in my current project will be using the hash to encrypt data so,
from what I've read and heard, I don't think there would be any problems
should I decide to publically post my code when it's complete. As a double
check, however, I'm going to download some of the FreeBSD authentication
routines later and see if they contain an MD5 implementation. If so, it
will be a pretty positive indication that export of MD5 for authentication
is perfectly ok.
Best regards,
Tom
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
