Cryptography-Digest Digest #958, Volume #8 Sun, 24 Jan 99 03:13:03 EST
Contents:
Re: Pentium III... (Robert Yoder)
Re: 3DES in EDE mode versus EEE mode (Scott Fluhrer)
General Purpose DSP chips for Crypto in Hardware (Rayees Shamsuddin)
Re: Pentium III... (Terry Ritter)
Re: hardRandNumbGen (Terry Ritter)
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
application/x-pkcs7-signature (=?iso-8859-1?Q?Daniel_Gonz=E1lez_Gasull?=)
Sanity check on authentication protocol (Edward Keyes)
----------------------------------------------------------------------------
From: Robert Yoder <[EMAIL PROTECTED]>
Subject: Re: Pentium III...
Date: Sat, 23 Jan 1999 19:33:07 -0700
Guy Dawson wrote:
>
> fungus wrote:
> >
> > Intel has announced that the Pentium III will have a built in hardware
> > random number generator, and individual serial number on each chip.
>
> This makes it much easier (well, possible) to determine if a chip
> is one of a batch of stolen chips.
>
> There have been quite a number of raid on truck carrying Intel CPUs.
> They're currently easy to sell on the black market as they are
> commodity items that can't be traced.
>
> The rated CPU speed can also be recorded against the serial number
> and this used to determine if a supplier is re-rating CPUs. That is,
> taking a 333Mhz Celeron and passing it off as a 400MHz one.
According to:
http://www4.tomshardware.com/releases/99q1/990121/cpu-news-01.html
"The new identification number is not targeted against processor
remarking
and Intel is not planning to provide a list where each identification
numbers
refers to the proper CPU speed. This number is not meant to fight
overclocking,
it's only meant to improve network security."
The official Intel blurb is toward the end of this lengthy example of
handwaving:
http://www.intel.com/pressroom/archive/speeches/pg012099.htm
Do yourself a favor and search the page for the word "serial" and
begin reading from there to the end. Being forced to read the
whole thing is a violation of the Geneva Convention.
Apparently, Intel seriously wants us to believe that having a unique
number embedded in your CPU is a giant leap in network security for
user authentication. Well since the only thing that goes out on the
wire, is what the OS puts on that wire, and the OS is composed of
_SOFTWARE_, not _HARDWARE_, I submit that the whole thing has less
validity than cold fusion.
I suspect that the CPU ID was driven by large commerical software
vendors who wanted a way to node-lock their licenses, and Intel is
trying cover the whole thing with a sugar-coating and convince the
consumers that this is good for us.
Robert Yoder
--
[EMAIL PROTECTED]
"Unix: The Solution to the W2K Problem."
------------------------------
From: Scott Fluhrer <[EMAIL PROTECTED]>
Subject: Re: 3DES in EDE mode versus EEE mode
Date: Sun, 24 Jan 1999 03:12:11 GMT
In article <78dta9$sef$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>In article <78b7b0$tmg$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> [EMAIL PROTECTED] wrote:
>>
>>> When just one key is used in 3-DES EDE, key schedule cannot be simply
>>> repeated 3x in exaustive key search, which affords a slightly higher workload
>>> per searched key than EEE in specialized hardware (and in software, of
>>> course) that could pre-compute the key schedule just once for all 3x.
>>
>> Did I miss something? One key encrypt-decrypt-encrypt is equivalent
>> to a single encrypt. If I'm testing keys to break 1-key EDE, of course
>> I'm going to run encrypt, not encrypt-decrypt-encrypt.
>>
>
>Bryan:
>
>You are correct -- however *if* the attacker knows it is a one-key 3-DES that
>can be attacked as a 1-DES.
Actually, if he just suspects that it might be 1-DES, he'll try it. After all,
since the work effort against 1-DES is so much smaller (2**56 times smaller), it's
absolutely insignificant against the work effort required for 3-DES. So, given a
ciphertext that is probably 3DES, but has a 10**-6 chance of being single DES
(because somebody hasn't switched over yet), a cost efficient plan of attack
would be:
- Try to brute force it assuming it is 1-DES. If you break it, fine
- If that doesn't break it, re-evaluate the expected value of the message to see if
it's worth breaking it as 3DES
>But, as NIST proposes, 1-DES will be phased out and 3-DES will coexist with
>AES -- for a long time. However, if Bob and Alice negotiate a 3-DES protocol
>and Alice receives 3x the same key from Bob (encoded with AOEP-RSA under
>different seeds, so the three ciphertexts are different) then there is no way
>for an attacker to know that Bob and Alice can be attacked just with one-key
>1-DES (as you suppose). Effectively, the attacker must suppose that either
>one, two or three keys may be in use -- and devise an attack that is general
>enough to the perceived threat that 3-keys may be used. Then, the mentioned
>"slightly higher workload" would have an influence.
--
poncho
------------------------------
From: Rayees Shamsuddin <[EMAIL PROTECTED]>
Subject: General Purpose DSP chips for Crypto in Hardware
Date: Sat, 23 Jan 1999 20:03:55 -0800
Hi,
I am looking forward to your suggestions on the best General Purpose DSP
chips which can be used for cryptography in hardware.
rayees
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Pentium III...
Date: Sun, 24 Jan 1999 05:08:43 GMT
On Sat, 23 Jan 1999 20:08:45 GMT, in
<78da88$fco$[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED]
wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Terry Ritter) wrote:
>> and I dispute the idea that this is particularly "random." What it is
>> is "complex," but this is the complexity of digital logic state
>> machines whose structure is known.
>
>If the clock skew were the ONLY factor, this might not be such a good choice.
>I used the title of clock skew because people would recognize the
>implementation strategy. There are MANY other activities affecting the code
>path between each sample. For example, I/O activity causes the processor to
>execute code, and also may access memory via DMA, causing memory access wait
>state variations.
But I/O activity is programmed -- presumably we will be re-using the
same program, and can expect similar activity. And DMA activity is
also programmed.
If we have other tasks running, AND those tasks are actually doing
something *while* we take "random" samples, that would be more
complex. But if (as we expect) sampling is frequent compared to
task-changes, most samples will be related and unaffected within the
period of the sampling task, making the supposed increase in
complexity largely illusory.
>If you have methods to predict the time, within 3
>nanoseconds, of every network packet flowing into a device, there are some
>folks from Cisco who would want to talk to you.
So, basically, you recommend generating random numbers while actively
on line and communicating with a network. That may not be the best
approach.
If external communications are the key to randomness, we'd sure better
hope The Opponent is not monitoring that line (to say nothing of
actively *influincing* that timing). Can we be sure?
>As far as I know, the instant
>in time that someone in the world clicks a link on a web page, is a random
>event.
For a random person, for one click, yes.
But when that person makes repeated clicks, no.
>These events will influence the code path of the sample time on a web
>server, causing true randomness.
Producing cryptographic random values on a web server does not sound
like a great idea to me.
>For any computer that has a UI, every
>keystroke or mouse moment causes code path variations, triggered by true
>random events.
With respect to keystrokes, every keystroke is first sampled in the
keyboard by a scanning process. That scanning process occurs
periodically, typically under the control of yet another crystal
oscillator. Key strokes are thus quantized in time, which is hardly
"random."
This problem probably does not apply to a mouse. But for this to
work, we have to be using that mouse while we are actively producing
random numbers, and our failure to do so will affect the quality of
the results.
>The software generator I mentioned also had three algorithms, to deal with the
>potential that one (or even two) had a weakness. Stirring a less random soure
>together with a more random source gives the more random result.
It also means that all the discussion and handwaving about the less
random source is essentially irrelevant.
>Do you also
>believe disk seeks are highly predicatble?
I do *indeed* believe that disk seeks are highly predictable (which is
not to say that they can be predicted to the nanosecond, but that they
can be approximated to virtually arbitrary precision). If we know the
current rotational angle, and the number of tracks to cross, and the
characteristics of the particular drive, seek time is highly
predictable. And we know the rotational angle from the last seek and
read, and the time elapsed. Typically, disk rotation is yet another
crystal-controlled entity.
>Your also suggesting you can take the output from a cryptographic hash
>(assuming we hash the data from the original source generator), and exactly
>predict the patterns of the input, to analyze the patterns originally
>generated.
I have suggested no such thing.
But it was my understanding that you were talking about *real*
randomness, as opposed to a hashed or encrypted counter. If we are
willing to accept the latter, all we need is a simple polynomial
counter and a cryptographic hash or cipher, and we can avoid all this
hardware-software-randomness stuff.
>I've heard of some success in generating MD5 hashes with specific
>output bits at specific values, but haven't heard of a total breakdown in the
>integrity of either MD5 or SHA-1. Are you suggesting cryptographic hashes are
>reversable? That gives a hash, you can calculate the number and value of input
>bits?
>
>I agree that if you put a system in a lab under very controlled conditions,
>you may be able to predict or influence things better. The software I worked
>on and I believe software running on most peoples systems will not be under
>these conditions.
"Belief" is arguably the major problem in cryptography: Most people
who propose cryptographic systems *believe* that nobody could crack
their complex design. But upon what reality is such belief based?
>The topic of this thread is about the usefulness of a hardware random number
>generator in a Pentium III. My belief is anybody who is serious about
>security, will want some external hardware device anyway. So doing security
>on a PC without extra hardware only applies for 'low' security uses. I
>believe software generated random numbers are very sufficent for this.
"Software generated random numbers" will be sufficent for exactly as
long as it takes someone to efficiently solve the system and produce a
cracking routine. When cracking is trivial, the result is NO security
at all, not even "low" security. And they will not tell you when they
succeed.
>Really, I'd love to see some hardware support for security in PC's. I just
>don't think Intel's latest features improve things much. I don't believe the
>weakest link is in the quality of random number generators. I think a socket
>on motherboards for an iButton would be a lot better (and cost very little).
>For lowest security uses, just a serial number button with costs a buck. If
>users wanted better security, a crypto iButton could be popped in for a dozen
>or two bucks. Of course this would work just as well for Intel, AMD, and
>Cyrix processors, which may not be Intel's goal.
This particular discussion was about the recent announcement of a
serial number and RNG on the processor chip. But information from
Intel last month involves a BIOS storage chip with hardware public-key
type operations. The protected BIOS is more likely to be the source
of software security than the processor SN. So the other shoe has yet
to drop. And the other processor guys may not know what they will do
yet.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: hardRandNumbGen
Date: Sun, 24 Jan 1999 05:08:35 GMT
On Fri, 22 Jan 1999 23:24:52 -1000, in <[EMAIL PROTECTED]>, in
sci.crypt ".���`�..���`�..���`�..���`�..���`�..���`�."
<[EMAIL PROTECTED]> wrote:
>[...]
>it is the very regularity of our clock cycles and the very
>power of our conforming buses which threaten to impart a
>hideous regularity to our nonces, our IVs, our keys. The
>heartbeat of a computer is its clock, and a powerful hammerblow
>it is to any mere analog circuit which would dare to reside
>on our motherboards. This is why we cannot use sensitive
>amplifiers to boost the whispers of thermal noise.
"Cannot" may be a bit of a stretch. Doing low-level analog in a
digital environment is tough, there is no doubt about that.
Presumably we would employ appropriate techniques to pull it off.
Probably this would involve some form of power isolation and
filtering, perhaps even shielding. Once the signal is large enough,
it can compete with digital its own terms.
We note that the output of a CD player is supposed to be low-noise,
yet is produced in a digital environment. And sound-card inputs
amplify relatively low analog levels. Certainly, disk-drive magnetic
read heads produce very low-level signals, yet are made to work well
in a highly-digital environment.
>This is why
>Large Signal Sources are our refuge, our bounty, our provider
>of Hardware Random Number Generators. Oscillators, I tell you,
>OSCILLATORS, they are our main hope, and the pride modern
>civilization.
Unfortunately "oscillation" inherently seems to imply some amount of
saved and time-delayed energy. It is this accumulation of energy that
makes it difficult to change the oscillation, and that is normally an
advantage. Normally, an oscillator cannot detect quantum or molecular
phenomena, and we would not want it to do so.
A signal composed of many oscillators, each doing their own thing, is
admittedly complex. But complex relationships are not, by themselves,
cryptographically secure. We could even think to simulate such a
system numerically, in which case the system is clearly no more than
yet another pseudorandom state machine waiting to be exposed. And
while any such simulation might not be exact, it could be close, and
we could continually adjust the simulation to the reality we do see.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 24 Jan 1999 06:00:42 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
Date: Mon, 18 Jan 1999 11:53:32 +0100
From: =?iso-8859-1?Q?Daniel_Gonz=E1lez_Gasull?= <Use-Author-Address-Header@[127.1]>
Subject: application/x-pkcs7-signature
--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hi everybody.
I've seen that people that uses M$ Outlook sometimes
send me these attachments:
application/x-pkcs7-signature, Encoding: base64
I'd like to know if there is a program for Linux that
can manage these digital signatures. Can I
a) check a digital signature of a M$ Outlook user?
b) encrypt a message to her/him?
c) make readable to me a message encrypted to her/him
(like the +encrypttoselt=3Don option of PGP)?
BTW, how secure are these signatures?
Thank you in advance. Please reply me by email. I'll
sumarize.
Please reply me by email. I'll sumarize.
--=20
___ =20
Daniel Gonz=E1lez Gasull __|_|__ "Un s=F3lo muerto es
[EMAIL PROTECTED] (o o) ya demasiado."
PGP RSA key 1024/EEA93A69 ( - ) -- Nelson Mandela
( . ) =20
( . ) =20
(_________) =20
Fight Spam! Join CAUCE! =3D=3D http://www.cauce.org/
Outlaw Junk Email! Support HR 1748.
--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3ia
iQCVAgUBNqMSq8nE0dnuqTppAQEnxQP+Na5Sxv7ObBTCT58tTLspx1+sCJ5otYDx
si1oHl6m8dhmxWAIt82x1IEbnjNMbK7D2fTOJYOtyWjjFbhWBXBSxTObjkCshhlD
euHzDAyZctfsMRdOWmemPXk0BcXyVPHicyG1Bz+rOmn70tvWfj/4TMTZiXkh4jPZ
dFWORpSaUhE=
=7BVa
=====END PGP SIGNATURE=====
--0OAP2g/MAC+5xKAE--
------------------------------
From: [EMAIL PROTECTED] (Edward Keyes)
Subject: Sanity check on authentication protocol
Date: Sun, 24 Jan 1999 01:52:24 -0500
I'm trying to do a nice secure mutual authentication and session key
exchange using only symmetric ciphers (since public key algorithms are
too computationally intensive for the platform). Could someone please
tell me if I'm missing anything obvious in the following protocol?
It is assumed that Alice and Bob share a secret key prior to this.
1) Alice sends Bob her name and a random number.
2) Bob concatenates and encrypts [session key, Alice's random number,
and a new random number] with the known shared secret key, and
sends this to Alice.
3) Alice decrypts the message, verifies her random number, which
indicates Bob is who she thinks he is. She then encrypts Bob's
random number with the secret key, and sends it back.
4) Bob decrypts it, verifies his random number, which indicates
Alice is who he thinks she is.
5) Further communication is encrypted only with the session key
that Bob generated.
As far as I can tell, this is secure against packet sniffers,
man-in-the-middle attacks, and replay attacks. If there is an
obvious flaw, please take pity on a cryptographic novice and point
it out -- you may need to run my software one day... ;-)
Thanks.
+------------ Edward Keyes, [EMAIL PROTECTED] -------------+
|................ http://web.mit.edu/eakeyes/www/ ................|
|.... DaggerWare: "small, sharp, and with a heck of a point!" ....|
+- "A little inaccuracy saves a world of explanation." C.E.Ayres -+
------------------------------
** 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
******************************
