Cryptography-Digest Digest #264, Volume #12 Fri, 21 Jul 00 12:13:01 EDT
Contents:
Re: New Idea - Cipher on a Disk ([EMAIL PROTECTED])
Re: Defeating the RIP bill ([EMAIL PROTECTED])
Re: Miller-Rabin-test (Bob Silverman)
Re: Has RSADSI Lost their mind? (Sander Vesik)
Re: microwave cd (Richard Herring)
Re: md5 uses, questions (Arthur Dardia)
Re: Random numbers and online-gambling (Sander Vesik)
Re: Has RSADSI Lost their mind? (phil hunt)
Re: md5 uses, questions ("matt")
Re: md5 uses, questions (John Myre)
Re: md5 uses, questions ("\"Ismo\"")
Re: md5 uses, questions (Ichinin)
Re: Miller-Rabin-test (Lynn Killingbeck)
Re: how strong is my own encryption? (MagiconInc)
Re: SSL CipherSuites in Netscape & Internet Explorer ("Nelson B. Bolyard (At Home)")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: New Idea - Cipher on a Disk
Date: Fri, 21 Jul 2000 12:53:52 GMT
On 19 Jul 2000 17:32:45 -0600, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] writes:
>> On 16 Jul 2000 05:47:48 GMT, [EMAIL PROTECTED] (Mack) wrote:
>> It is quite feasible to construct the card so that it is
>> tamper proof.
>
>Nope. Not only is this hard, it's so hard that no one knows how to do
>it, and moreover it's almost certainly impossible.
So it is infeasible to make a private key held in a smart card
undetectable? Are you thinking of physical attack, or reading
electromagnetic emissions from the card, or some other form of attack?
If emissions, can a card not be constructed with shielding in the
card?
>However, cards can be made to be tamper resistant, and they can be
>difficult enough to penetrate that very expensive people and equipment
>are required. If your enemy is a government, and they really, really
>want to get you, don't rely on a smart card keeping secrets from them.
Is there a security technology of any kind that is proof against a
very determined attack with very large resources?
>> Embedding a standard method into the OS security model is the critical
>> development. I have suggested it to Microsoft. I'll be surprised if
>> they dont produce something like this. Mind you the Linux crowd could
>> do it pretty quick, although someone would have to produce the
>> smartcard. That would put the heat on the proprietary OS mob to catch
>> up or lose market share.
>
>A standard method for what? Windows 2000 already includes a standard
>method for smart card-based login. AFAIK nothing like this has been
>done for Linux, but it could be done very quickly, as you say.
Standard method for OD to recognise user using smart card
authentication based on strong public key encryption.
>> >The best security would require a passphrase, a fingerprint and
>> >a token. After all if your opponent is an oppresive police force
>> >they may not have any compunction about cutting off a finger to
>> >get a good fingerprint.
>>
>> I believe the biomechanics used for fingerprint recognition will not
>> recognise the finger if the person is dead or the finger is detached.
>> But this doesn't stop someone (eg a mugger) forcing you to use the
>> card.
>
>Some biometric devices attempt to detect whether or not the finger (or
>retina, or hand, or face, or ...) is alive, via body heat, pulse, etc.
>Any system one engineer can build another can fool, however.
>
>Also, biometric authentication is trivially vulnerable to replay
>attacks. The data must be digitized to be passed to the card, which
>means that all an attacker needs to do is to get you to stick your
>finger (or whatever) in some device that they've managed to subvert.
>Once they have the data they can reuse it at will (a significant
>problem with biometrics, IMO -- you can always make up a new password,
>but you only have 10 fingers, two eyes, two hands, one face, etc.).
>
>There do exist card-embeddable fingerprint readers, so the biometric
>data never needs to leave the card, but card-embeddable readers must
>be simple, low-power devices, making them easier to fool.
I believe there is one in commercial use in Europe for a health
insurance card, which will not respond to a dead finger.
>> I suspect finger print recognition on a card is the easiest, but one
>> could use a 4 number pin, and simply code the card so that it locks up
>> after 4-5 failed attempts.
>
>And one could use more than four digits, as well. Card locking
>introduces its own issues, but this is the standard approach.
I am proposing the card as a common use authentication
device/universal key. I suspect it would be considerably harder to
'pick' than most physical locks, on which people rely for their
securing their houses, cars etc. If ones security needs are higher
then presumably one would resort to other tech.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Defeating the RIP bill
Date: Fri, 21 Jul 2000 13:04:07 GMT
As I understand it RIP bill specifically excludes people from being
held accountable for encryted files in unsolicited email. This has
been discussed in a prior thread, regarding sending Jack Straw and
encrypted email.
On Sat, 15 Jul 2000 19:03:06 +0100, "Michael Tickle"
<[EMAIL PROTECTED]> wrote:
>"Kad" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>: I just thought I would make a suggestion as to how easy it
>is
>: to write a crypto program which makes the RIP bill the
>lame duck
>: it already is
>
>I am new to this group, so I don't want to seam out of
>place, but... Would it not be easier set up hotmail
>accounts or similar in the names of all the people evolved
>with RIP. Then send encrypted data to them. Tell the
>police the data transferred is of interest to them. Then
>the police will ask to see the decrypted data. The
>receivers can not do this and are thus sentenced to 2 years
>in prison. I know this idea is a little rough around the
>edges, but you get the idea
>
>
>
>Mike
>
>
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Crossposted-To: sci.math.num-analysis,sci.math
Subject: Re: Miller-Rabin-test
Date: Fri, 21 Jul 2000 13:24:03 GMT
In article <[EMAIL PROTECTED]>,
Thomas Nordhaus <[EMAIL PROTECTED]> wrote:
> Do there exist estimates that measure the probability, that a number
is
> NOT prime, given that it is b-probable prime, depending on b? What
about
> "independence". Do these probabilities multiply?
See:
Damgard, Landrock, & Pomerance Average Case Error Estimates for the
Strong Probable Prime Tests, Math Comp. Vol 61, 1993
See the discussion in the Handbook of APplied Cryptography, Chapter
4
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Date: 21 Jul 2000 14:16:53 GMT
Roger Schlafly <[EMAIL PROTECTED]> wrote:
> Sander Vesik wrote:
>> It would be a rather sad occurence if RC6 was to become unavailable
>> just because it didn't make AES. At least it is 'yet another US only
>> patent' I hope?
> Why? The other 4 finalists are all patent-free, and arguably
> superior. If RC6 does not make the cut, then presumably
> the AES winner will be preferable anyway.
The patented part affects the usability of the cypher only in areas where
it is patented. It is *IMHO* not clear how picking one of the finalists
means that it is a "better" cypher in the long run. And at any rate I consider
the availability of a number of cyphers of roughly equal strength and
support for similar block/key sizes advantageos.
If RC6 remains unavailable / costly in certain areas, there is just one
such less in practice.
--
Sander
FLW: "I can banish that demon"
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: microwave cd
Date: 21 Jul 2000 14:11:17 GMT
Reply-To: [EMAIL PROTECTED]
In article <8l7vnh$t5t$[EMAIL PROTECTED]>, Paul Rubin ([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Rush <[EMAIL PROTECTED]> wrote:
> >>Probably the most convenient and effective thing to do, especially if
> >>you have a lot of CD's to destroy, is take them to the city dump and
> >>toss them into a high temperature incinerator.
> >
> >Are there any municipal garbage incenerators still operating in the USA? I
> >thought the EPA banned them years ago.
How about a crematorium? Or somewhere else where biological waste
is destroyed?
> I don't know. I was kind of wondering that when I made that post.
> The only time I saw one was many years ago. It was impressive. I
> could have easily jumped in or thrown someone else in, and no remains
> would have ever been found. So I wondered whether municipal
> incinerators might have been closed off to the public for liability
> reasons. I hadn't really been thinking of the EPA angle.
> >Throw something in the garbage now, and it goes into a landfill.
> >
> >If you have too many CDs to conveniently use a torch, find a place where open
> >fires are permitted and build a bonfire.
> I had thought that incenerators ran at much higher temperatures than a
> bonfire could, and that the effluent was scrubbed, so most of the
> pollutants were eliminated that way.
> I wouldn't want to actually melt/burn the discs with a torch; just
> slag the metal layer that contains the data.
On CD-R and CD-RW, yes. But on mass-produced CDs the data is in the
top surface of the plastic; the metal is just a reflector.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: md5 uses, questions
Date: Fri, 21 Jul 2000 10:28:46 -0400
Joseph Ashwood wrote:
> It's not that we're anti-AOL, it's that we get tired of saying the same
> things ad infinitum. As I've said (many times) before, you can't depend on
> the protocol to verify the integrity of the client (or server) program, so
> any attempts by AOL to do that would be, quite frankly, stupid. As to the
> second one, there's a very distinct consequence that it is quite easy to
> change the hash at the same time as the message, so using an un-verified
> hash function for message integrity is foolish. As to what else they could
> use MD5 for, the uses are ennumerable only in the same sense that the set of
> all programs is ennumerable (which is to say that they can use it for
> whatever they please and it would work in some fashion).
> Joe
>
> "Arthur Dardia" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Any reason why my other post was ignored? Is sci.crypt anti-AOL?
> >
> > ---
> > By going to Help-->About, you can see that portions of AOL IM implement
> > MD5 Hash algorithm. How does it use this? I could see it being used
> > to:
> >
> > a) verify a valid client program
> > program opens and connects to served, sends an md5 of itself or of some
> > registry keys it installs, etc. and then AOL either lets it connect or
> > it refuses it
> > b) to verify messages
> > how could md5 be used to make sure messages are authentic and valid.
> > wouldn't user A have to send the message along with the MD5 for that
> > message? couldn't a man-in-the-middle just change the message,
> > calculate the md5 and then sent that along with it? albeit, it would be
> >
> > difficult to do by hand because of the spur-of-the-instant involved with
> >
> > instant messaging, but a program to do such a feat would not be
> > difficult.
> >
> > any other ways aol might implement it?
> >
> > --
> > Arthur Dardia Rensselaer Polytechnic Institute [EMAIL PROTECTED]
> > PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
> >
> >
That wasn't my question (sorry if this sounds rude). I was wondering how AOL
uses MD5 and in which areas of their program. I don't understand why it can't
be used to verify the client program's validity (making sure it wasn't
modified). Wouldn't this scheme work?
a) client generates an md5 output based on adding all of the registry keys that
would be common among all users (not the usernames, for example), the program
itself, etc.
b) client sends this hash to server during connection/password verification
sequence
c) if this hash matches the server's, the server lets the user connect, else
refuse connection
--
Arthur Dardia Rensselaer Polytechnic Institute [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Random numbers and online-gambling
Date: 21 Jul 2000 14:39:23 GMT
zapzing <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
>> On Thu, 13 Jul 2000 15:30:02 GMT, [EMAIL PROTECTED] wrote,
>> in part:
>>
>> A news story appeared in the local newspapers about a week ago. An
>> Edmonton man had discovered a flaw in electronic slot machines.
>>
>> Instead of using it to rip them off, he notified Alberta gaming
>> authorities.
>>
>> Yet, he is still facing a $15 million lawsuit from the slot machine
>> manufacturer.
>>
>> This, of course, has significant implications for "white hat" hacking.
> He doesn't really sound like
> someone who would have fifteen
> million lying around, does he??
> :)
Well, if his attack was good, he just needs to take the money out of
the machines. 8-)
On the other hand, it can easily mean that people will do less of
publishing of the finds and even less taking credit for the cases
that do get published, one way or the other.
> --
> If you know about a retail source of
> inexpensive DES chips, please let
> me know, thanks.
In-System Programmable FPGA-s won't do?
--
Sander
FLW: "I can banish that demon"
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Subject: Re: Has RSADSI Lost their mind?
Date: Fri, 21 Jul 2000 14:35:39 +0100
Reply-To: [EMAIL PROTECTED]
On 20 Jul 2000 18:44:34 GMT, Sander Vesik <[EMAIL PROTECTED]> wrote:
>Paul Koning <[EMAIL PROTECTED]> wrote:
>> Bill Unruh wrote:
>>>
>>> That letter is incredible. Absolutely everything there sounds like
>>> algorithms, which cannot be patented.
>
>> What country are you speaking of? Certainly that isn't correct
>> in case of the USA...
>
>Just about anything - and most probably even 'operation of an entity
>called PTO' is patentable in the US.
Especially if you include the words "using the Internet".
Someones should patent the idea of an organisation making a living for itself
by issuing stupid patents. Because this is an absurd idea, the patent is
bound to be granted. Then sue the USPTO for breach of that patent -- it
should hold up in court because the USPTO granted it in the first place.
--
***** Phil Hunt *****
------------------------------
From: "matt" <[EMAIL PROTECTED]>
Subject: Re: md5 uses, questions
Date: Fri, 21 Jul 2000 22:58:03 +0800
"Arthur Dardia" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> a) client generates an md5 output based on adding all of the
registry keys that
> would be common among all users (not the usernames, for example),
the program
> itself, etc.
> b) client sends this hash to server during connection/password
verification
> sequence
> c) if this hash matches the server's, the server lets the user
connect, else
> refuse connection
Why can't a modified client just send the correct hash value (from the
genuine client), without bothering to calculate the md5 sum? Thats the
fatal flaw with untrusted client authentification.
There's no way around it.
Matt.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: md5 uses, questions
Date: Fri, 21 Jul 2000 09:01:36 -0600
Arthur Dardia wrote:
<snip>
> Wouldn't this scheme work?
>
> a) client generates an md5 output based on adding all of the registry keys that
> would be common among all users (not the usernames, for example), the program
> itself, etc.
> b) client sends this hash to server during connection/password verification
> sequence
> c) if this hash matches the server's, the server lets the user connect, else
> refuse connection
This would work well to detect random/accidental modifications to
the client software. It would be trivial, however, for someone to
modify the software to deliberately fool the server: include in the
modification sending the hash the server wants, instead of the hash
of the modified program.
JM
------------------------------
From: "\"Ismo\"" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: md5 uses, questions
Date: Fri, 21 Jul 2000 17:13:39 +0200
matt wrote:
> Why can't a modified client just send the correct hash value (from the
> genuine client), without bothering to calculate the md5 sum? Thats the
> fatal flaw with untrusted client authentification.
> There's no way around it.
What about appending a random one-time session value to the data
that is about to be hashed?
/Ichinin
.SE
_______________________________________________________________
- "You can't beat the system, but you can edit the registry"
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: md5 uses, questions
Date: Fri, 21 Jul 2000 17:19:09 +0200
|oO -"DOOH!"
An apollogy, The previous-post came from me.
(Just showed a friend how easy it is to make
faked email and how to trace it using the SMTP
headers, forgot to change it back - Sorry)
------------------------------
From: Lynn Killingbeck <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.math.num-analysis,sci.math
Subject: Re: Miller-Rabin-test
Date: Fri, 21 Jul 2000 10:35:09 -0500
Thomas Nordhaus wrote:
>
> Hi,
> if the Miller-Rabin test shows that an odd number N is a b_i-probable
> prime for k "randomly chosen" numbers b_i, 1 < b_i < N then the
> probability that N is NOT prime can be bounded by (1/4) ^(-k).
>
> This fact is well known.
>
> On the other hand: "Most" base-2 probable primes are prime, and also
> "most" base-3 probable primes are prime (I guess). Therefore my question
> is:
>
> Do there exist estimates that measure the probability, that a number is
> NOT prime, given that it is b-probable prime, depending on b? What about
> "independence". Do these probabilities multiply?
>
> Thankful for any helps and hints,
> Thomas Nordhaus
I don't know about multiplying the actual probabilities (as opposed to
the 1/4 worst-case), but there is material on the www giving some
combinations. Try searching for pseudoprimes, then strong pseudoprimes.
Out of my files, 1,373,653 is a both 2 and 3-SPRP (strong pseudoprime),
the smallest one.
25,326,001 is a 2, 3 and 5-SPRP.
2,152,302,898,747 is a 2, 3, 5, 7 and 11-SPRP.
3,474,749,660,383 is a 2, 3, 5, 7, 11 and 13-SPRP.
341,550,071,728,321 is a 2, 3, 5, 7, 11, 13 and 17-SPRP.
The first three of these are due to Pomerance, Selfridge and Wagstaff,
... and all others are due to Jaeschke. (Note: this
comment about attribution is an edited cut-and-paste from my web source.
Wish I still had the URL for your reference, but it's gone from my
bookmarks, somehow.)
Lynn Killingbeck
------------------------------
From: [EMAIL PROTECTED] (MagiconInc)
Subject: Re: how strong is my own encryption?
Date: 21 Jul 2000 16:01:16 GMT
In article <[EMAIL PROTECTED]> Paul Koning <[EMAIL PROTECTED]>
wrote:
> Read all about it
> in David Kahn's "The Codebreakers" (highly recommended,
> provided it's the hardcover).
I have the hardcover. What's wrong with the paperback?
Paul Magnussen
Magicon Inc.
Making software simpler
------------------------------
From: "Nelson B. Bolyard (At Home)" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: SSL CipherSuites in Netscape & Internet Explorer
Date: Fri, 21 Jul 2000 16:09:18 GMT
Peter Kwangjun Suk wrote:
> I've been searching for the answer to this for awhile, and can't seem
> to get a straight answer. What SSL ciphersuites are in Netscape 4.7
> and Internet Explorer 5.0?
>
> Pointers to docs are appreciated the most.
In Communicator, click on the little lock icon in the lower left hand
corner of any window. In the security window that appears, click on
the link "Navigator" in the frame on the left side. Next, on the
right side, click the button that says "Configure SSL v3" for the
complete list of SSL v3 ciphers. You can even disable the ones you
don't like. SSLv2 is similarly configurable.
/Nelson
(Speaking only for myself, as always.)
------------------------------
** 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
******************************
