Cryptography-Digest Digest #877, Volume #10 Mon, 10 Jan 00 13:13:02 EST
Contents:
Re: Intel 810 chipset Random Number Generator ("Trevor Jackson, III")
Re: Simple Encryption ... (David Wagner)
Re: 8-round Blowfish (David Wagner)
Re: How about this for a "randomly" generated bitstream? ("Trevor Jackson, III")
Password example encrypt/dycrypt! (Mark van den Broek)
AES & satellite example (DJohn37050)
Re: "1:1 adaptive huffman compression" doesn't work (John Savard)
Re: Intel 810 chipset Random Number Generator (Paul Koning)
Re: Domain name and properties for sale. (Paul Koning)
DH key derivation and Cryptoki(PKCS#11). ("Alex Givant")
Re: Intel 810 chipset Random Number Generator (James Felling)
Re: Intel 810 chipset Random Number Generator (Doug Stell)
Re: Password example encrypt/dycrypt! (doc)
Re: Cryptography in Tom Clancy (Shawn Willden)
Re: Questions about message digest functions (Shawn Willden)
Re: Wagner et Al. (Shawn Willden)
Re: Little "o" in "Big-O" notation (Bob Silverman)
Re: Little "o" in "Big-O" notation (Bob Silverman)
Re: Simple Encryption ... ("Derek Potter")
Re: WSO have really protected my home PC with Windows 98 ! (Tom St Denis)
----------------------------------------------------------------------------
Date: Mon, 10 Jan 2000 11:05:05 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Bradley Yearwood wrote:
> In article <859sqo$5go$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >
> >Apparently there is no reliable way of detecting the RNG.
> >You read 1 bit from a pre-defined memory location to see
> >it is there, and read from other locations to get the random
> >data. You are on your own to figure out whether the data is
> >really random enough that it is likely to be coming from
> >the RNG.
>
> Yes, but it is common sense to run some statistical tests on any
> claimed hardware random source before actually using it, and perhaps
> also concurrently with use. An advantage of having this source integrated
> onto a chip is that it seems less likely to fail than the components of and
> connections to some external device.
>
> >It warns about multi-threaded apps using the RNG, but
> >nothing about different apps using the RNG. Apparently
> >bad things can happen if 2 apps try to use it at once.
> >
> >This looks pretty brain-damaged to me.
>
> Not really brain damaged. This problem is intrinsic to any concurrent
> single-server multiple-consumers situation. You need an interlock and/or
> queueing to serialize access.
I believe you are making unwarranted assumptions. There are simple ways to eliminate
the contention problems inherent in the sharing of resources. Some solutions require
no interlock of queuing. Intel has been demonstrating ignorance of the simple answers
for many years.
>
>
> The hardware guys did OK in describing how to get to the raw registers. Their
> warning against simplistic multi-threaded use was unnecessary to anyone
> familiar with realtime software or OSs. These days, so much seems driven
> by avoidance of potential liability, and so little by common sense, that the
> presence of the warning is understandable.
The presence of the warning is only necessary due o the presence of the "hazard" their
design created. Had they actually considered the "hazard" hazardous they would have
eliminated it.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Simple Encryption ...
Date: 10 Jan 2000 07:59:24 -0800
In article <85cncq$5b7$[EMAIL PROTECTED]>,
Derek Potter <[EMAIL PROTECTED]> wrote:
> There are times when it would be cool (Ok, so
> you now know this is going to be one of *those*
> questions!) to be able to encrypt something not
> so much to stop it being read by third parties
> but to prove to the *recipient* that you have
> some information but you aren't prepared to
> divulge it *yet*.
The primitive you want is bit commitment. See Schneier for protocols.
Your proposal doesn't look secure to me. There's plenty of work which
shows that, given the sum of two plaintexts, you can often recover much
of the two texts. (Example technique: guess a probable word in one text;
for each possible offset, subtract it from the sum; see whether what
remains looks like part of the other text; if so, extend it forwards and
backwards, recovering more and more information as you go.)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: 8-round Blowfish
Date: 10 Jan 2000 08:00:42 -0800
In article <85cffp$imh$[EMAIL PROTECTED]>,
Thierry FALISSARD <[EMAIL PROTECTED]> wrote:
> Bruce Schneier says in his famous Blowfish paper :
>
> "It is probably safe to reduce the number of iterations from 16 to 8 without
> compromising security. The number of iterations required for security
> may be dependent on the length of the key. Note that with the current
> subkey generation procedure, an 8-iteration algorithm cannot accept
> a key longer than 192 bits."
>
> May I infer from this that 8-round Blowfish (192-bit key) is at least
> as strong as triple-DES (168-bit key) ? (or even stronger)
I doubt it.
(It certainly doesn't follow logically from Bruce's quote, and I don't
even think it's likely to be true.)
------------------------------
Date: Mon, 10 Jan 2000 11:16:01 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: How about this for a "randomly" generated bitstream?
Guy Macon wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (David Kessner) wrote:
> >
> >> In article <853ocm$[EMAIL PROTECTED]>, Guy Macon wrote:
> >> >One problem: an audio recording that is accurate to the LSB sounds
> >> >considerably worse than one with 1 LSB of random noise added. Because
> >> >of this, it is common to add 1 LSB of random noise. In the old days
> >> >this was usually resistor noise, but nowdays it is cheaper to write a
> >> >psuedorandom generator program on the DSP chip in your mixing board.
> >> >I doubt that the psuedorandom generator programs are at all suitable
> >> >for crypto. (At last! My membership in the Audio Engineering Society
> >> >finally paid off!)
> >
> >Ummm... I assume that you are talking about audio dithering. If
> >this is the case, then there should be a little clarification for
> >those non-audio people here.
> >
> >You don't add 1 LSB of random noise, you add "a small amount of
> >noise that is <1 LSB".
>
> Actually, the prefered method is a triangular probability distribution
> with the peak at the actual value and the skirts at +1 LSB and -1 LSB.
> This is often approximated by using 2 RNGs which generate random errors
> of up to 1/2 LSB with equal probability and multiplying them.
>
> >Further, this is only done when taking
> >audio from N bits down to N-M bits (I.E., from 24 bit audio to
> >20 bit audio).
> >
> >And in this case, the LSB is the last bit in the
> >N-M bit data, not the original N bit data.
>
> I beg to differ. You are confusing the common practice of using the
> discarded bits as a probabilistic dither to the new LSB with the
> equally common practice of adding noise to the LSB when the word length
> stays the same.
>
> >To put this into a practical sense, let's say that we're
> >converting 24 bit audio into 16 bit audio. And, for the
> >sake of discussion I will ignore what to do with the sign
> >bit(s).
>
> >When converting from 24 to 16 bit audio, we take the original
> >24 bit sample and add an 8-bit random number. Remember that
> >the "LSB" is the 16th bit (from the left), so our 8-bit random
> >number is <1 LSB. This produces our new sample. This is
> >repeated for every sample, but with a different random number
> >(obviously).
>
> O.K. You have a bunch of 24 bit samples with the top 16 actual
> measurements of the physical audio, the bottom 8 actual measurements
> of the physical audio modified by noise. Then you throw away the
> bottom 8 bits during your 24 to 16 conversion. What is the result?
> No change. You have to make changes in the remaining 16 bits to
> have any effect at all on the output.
No, he's _adding_ 8 bit data to 24 bit data, which will occasionally overflow the low
byte into bit 8. It's a form of probabilistic rounding of the 24 bit data to 16 bit
data
>
>
> >This has the effect of masking the quantanization noise. Under
> >some conditions the quantanization noise would sound very non-
> >random. But with this method of dithering the quanization noise
> >is basically white noise and thus less objectionable to our
> >ears.
>
> If you are listening to a CD (16 bit audio), the only possible way
> to mask anything is to make changes to one of those 16 bits, presumably
> the LSB. One can trade time for resolution by taking the bits in the
> 24 bit source and turning them into what amounts to pulse density
> modulation of the LSB, but that doesn't help you if your source is
> 16 bits, so it is common practice to feed the PDM with a triangular
> shaped RNG noise source.
>
> >This has a very different effect than "taking a 16 bit audio
> >stream and adding a random 1-bit stream to it". In that the
> >effect is much more subtle and much less noisy.
>
> >I should stress that this is only done when converting from one
> >word size to a lower word size. It is not done when going to a
> >higher number of bits or when the word size stays the same.
>
> What you described is indeed done when converting from one word
> size to a lower word size, but the LSB noise is often done when
> digitizing to a particular word size, and when going to a higher
> number of bits, the two most popular choices are filling the
> empty bit with pink noise or doing a curve fit that hits all of
> the data points that are actual audio samples.
>
> >What this means for the crypto guy is unclear.
>
> It means that the commonly voiced opinion that the LSB of digitized
> noise is random and not pseudorandom is suspect.
------------------------------
From: Mark van den Broek <[EMAIL PROTECTED]>
Subject: Password example encrypt/dycrypt!
Date: Mon, 10 Jan 2000 16:42:55 +0100
Reply-To: [EMAIL PROTECTED]
Hi,
I'm using Borland C++Builder and i'm looking for sample program
witch encrypt/decrypt passwords.
Anyone got any suggestions for me??
(p.s. I want to place a safe password procedure into my splashscreen)
any kind of help will be highly appriciated!!
regards,
Mark vd Broek
Netherlands
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: AES & satellite example
Date: 10 Jan 2000 16:33:27 GMT
I am writing a paper for 3rd AES and remember someone discussing in sci.crypt
that a reason for having multiple AES winners were situations where hardware
was used but was not able to be updated, as in satellites, Does anyone
remember who said that?
I want to give proper attribution.
Thanks,
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Mon, 10 Jan 2000 09:41:28 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>John Savard wrote:
>> However, it is possible, at least with a static Huffman code
>> (actually, there is no reason why this wouldn't work as well for
>> Adaptive Huffman compression), to represent the last symbol in a
>> message with fewer bits. This has to do with the fact that the Huffman
>> codes for symbols have the prefix property. The last symbol does not
>> need to have this property, since it doesn't have to contain the
>> information of how many bits it contains - the representation has to
>> stop when the message itself runs out of bits.
>But exactly here Scott would oppose. (In my understanding) for him
>any (correct) compression has to terminate in certain 'normal' way.
>Any 'abnormality' would mean some information exploitable by the
>analyst. Perhaps there is indeed some value, if your discussions with
>him could be carried to a proper end.
Well, there's no abnormality in the termination at this point: what
happens is I'm switching from the Huffman alphabet to one suited to
handling the last symbol: but a complete symbol is coded. This part of
the procedure is one where we are in agreement.
The dispute between us, as I understand it, concerns the next step.
The message, although shortened by a bit or two, still is contained in
an arbitrary number of bits. Since it will be transmitted in bytes, or
at least it is more convenient to encrypt in the form of whole bytes,
he has proposed a coding scheme where a message having an arbitrary
length can be represented efficiently by one that is made up of whole
bytes.
Since there are twice as many messages n+1 bits in length as there are
messages n bits in length, if the probability of an n+1 bit long
message were twice as high as that of an n bit message, there would be
no problem with schemes of this type.
Since, in actuality, the distribution of the lengths of messages
follows a bell curve, the appropriate typical distribution for lengths
from n to n+7 is a flat, uniform distribution of lengths. Thus, a code
representing the left-over bits after the last whole byte of the
message by a whole byte would have bias, since these left-over bits
don't have equal probability; the longer strings are less probable.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Date: Mon, 10 Jan 2000 11:30:04 -0500
seifried wrote:
> ...it really boils down to "do you trust an
> american company to generate your random data?".
It's not just american companies that have done sneaky
things in this area... Crypto AG was Swiss, if memory serves.
> ...
> If you want a real hardware RNG you can verify there are simple ones
> based of radio crystals/etc that plug into a serial or parallel port
Crystals? Not likely. Resistors, noise diodes, Zener diodes, all
those sound plausible, but crystals won't serve at all for this
application.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Domain name and properties for sale.
Date: Mon, 10 Jan 2000 11:31:41 -0500
Glenn Larsson wrote:
>
> IIRC, doesnt America have capital punishment?
Yes, but not enough. :-)
paul
------------------------------
From: "Alex Givant" <[EMAIL PROTECTED]>
Subject: DH key derivation and Cryptoki(PKCS#11).
Date: Mon, 10 Jan 2000 12:18:53 -0500
Hi, All!
I implementing Cryptoki (PKCS#11) support in our product and have some
problem with DH key derivation. When I call to C_DeriveKey() with template
that contains attribute CKA_KEY_TYPE equal to CKK_DES (8 bytes),
C_DeriveKey() produces 8 bytes key. But I have to derive 64 bytes key. So
the question is how to make it happens.
When I tried CKA_KEY_TYPE = CKK_GENERIC_KEY and CKA_VALUE_LEN = 64 (bytes) I
received error 0x0062 - CKR_KEY_SIZE_RANGE.
If somebody can help me, thanks in advance,
My e-mail is [EMAIL PROTECTED]
Alex Givant.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Date: Mon, 10 Jan 2000 11:22:33 -0600
My personal belief is as follows. The RNG generates a bit at fixed intervals , if
multiple apps are accessing it at the same time then they are each getting the same
value. If this is the case, then there are issues with more than 1 thread accessing
it at the same time. (i.e. if you are doing a montecarlo method of finding area, with
thread 1 picking the x coord, and thread 2 the y coord, you will get an
extreme bias toward values being on the line x=y. Ny guess is that it is indeed
intended as an entropy source for driving a /dev/random type randomness pool.
"Trevor Jackson, III" wrote:
> Vernon Schryver wrote:
>
> > How much would you like to bet that the Intel employees who designed the
> > facility expected that the operating system would mediate between the
> > application wanting random bits and the various concurrent threads of
> > execution that need random bits? I'm confident that they understand (and
> > understood) the issue well enough, even if their main design target was
> > software from Redmond. The odds are better than even that some of them
> > have heard of /dev/random and thought that their design should be used
> > within it.
>
> $100 says they didn't think about it at all. had they considered the usage of the
>device the interface would look considerably different. I suspect some engineer was
>handed a feature to implement and all the effort went into the quality of the data
>and none went into the quality of the interface. N.b., the interface would logically
>include the hardware device registers and any software needed to drive it.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: Intel 810 chipset Random Number Generator
Date: Mon, 10 Jan 2000 17:17:25 GMT
On 7 Jan 2000 14:13:16 -0800, [EMAIL PROTECTED] (Bradley Yearwood)
wrote:
>One interesting observation is that the device requires a variable
>amount of time to generate a new random byte. Availability of a new
>value is indicated by a status bit. They recommend a timeout of 4.5ms
>in polling this status, which appears to indicate a worst-case rate of
>random byte production of around 222 bytes/sec.
This doesn't sound very useful. A randomizer should be able to quickly
supply a random block the size of a symmetric key, a Diffie-Hellman
private key or a prime 1/2 the size of an RSA modulus.
By contrast, the Motorola Advanced INFOSEC Machine (AIM) supplies of
random data up to 1024 bits in length, organized as a buffer of 32
32-bit words. Blocks may be requested as often as every 146 usec.
Also, this is a true, NSA-certified randomizer, not a PRNG. The AIM is
dedicated to performing crypto, particularily high-grade crypto.
------------------------------
From: doc <[EMAIL PROTECTED]>
Subject: Re: Password example encrypt/dycrypt!
Date: Mon, 10 Jan 2000 12:33:22 -0500
You might try the Linux source code for this.
But that means that you now need to go looking through a
pile
of source for the getty/login stuff.
I had a similar need recently and decided to go with
the DES code from the book "Cracking DES". (published by
EFF)
DOC
Mark van den Broek wrote:
>
> Hi,
>
> I'm using Borland C++Builder and i'm looking for sample program
> witch encrypt/decrypt passwords.
> Anyone got any suggestions for me??
> (p.s. I want to place a safe password procedure into my splashscreen)
>
> any kind of help will be highly appriciated!!
>
> regards,
>
> Mark vd Broek
> Netherlands
------------------------------
Date: Sat, 08 Jan 2000 14:33:07 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Cryptography in Tom Clancy
Johnny Bravo wrote:
> On Wed, 05 Jan 2000 16:11:34 -0700, Shawn Willden <[EMAIL PROTECTED]>
> wrote:
>
> >I'm not sure which novel it was in (probably "Rainbow Six"), but there was
> >a section in one of Clancy's recent novels in which the NSA brute-forced a
> >128-bit key in a few hours. I don't mind some *minor* technical
> >inaccuracies, but I groaned aloud at that one.
>
> It is possible, the first key tried could decrypt the message.
Yes, with p = 1/(2^128). It would be a very poor plot that turned on such an
extreme coincidence. Not Clancy's style.
> The groaner is that they even tried to brute force a 128 bit key. Not
> unless the security of the nation or an entire city is at risk, then
> they don't have much to lose on such a long shot.
A loooooooooooonnnnnnnnnngggggggg shot.
> If he wrote that they routinely break 128 bit keys in three hours,
> then that is another story. <g>
That was clearly the idea. It wasn't a last-chance, desperate measure.
Shawn.
------------------------------
Date: Sat, 08 Jan 2000 14:36:33 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Questions about message digest functions
Tim Tyler wrote:
> However, if the hash size is small - as it will sometimes be practially
> constrained to be - a PRF is simply completely the wrong model for an
> ideal hash, if you care at all about avoiding hash collisions.
What is the correct model?
Shawn.
------------------------------
Date: Sat, 08 Jan 2000 14:44:01 -0700
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: Wagner et Al.
Guy Macon wrote:
> John E. Kuslich <[EMAIL PROTECTED]> wrote:
>
> > Security by software is total myth. Once resident in memory, any
> > software can be made to whistle Dixie or do anything at all by a
> > competent machine language programmer. Any executable or dll can be
> > loaded and then altered in arbitrary ways to achieve any desired result.
>
> I suggest that you try this under Windows NT 4.0 when your competent
> machine language programmer is logged on as an ordinary user instead
> of as an Administrator.
On a standard installation of Windows NT, he'd have no trouble.
Theoretically, a properly locked-down installation would be secure, but since
(1) there doesn't seem to be a large community of NT users who focus seriously
on security and (2) Microsoft's approach to security breaches is generally to
deny them for as long as possible, and quietly half-fix them when forced to, I
would depend on it too strongly.
Further, even the resistance of a locked-down NT box only holds while NT is
running. Boot off a floppy and all bets are off.
Shawn.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Little "o" in "Big-O" notation
Date: Mon, 10 Jan 2000 17:42:55 GMT
In article <8591f5$u8v$[EMAIL PROTECTED]>,
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>
> Jeff Moser <[EMAIL PROTECTED]> wrote in message
> news:858nb6$bdo$[EMAIL PROTECTED]...
> > What exactly does the little "o" in "Big-Oh" notation mean? For
example, I
> > know that o(1) becomes negiligible as the integer approaches
infinity. I'm
> > uncertain on how to define it.
>
> o(f(x)) = g(x) is true iff:
>
> lim f(x) / g(x) = 0
> x->oo
TWO corrections.
(1) You have the fraction reversed. It should be g(x)/f(x).
(2) It should be |g(x)/f(x)|.
--
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: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Little "o" in "Big-O" notation
Date: Mon, 10 Jan 2000 17:40:54 GMT
In article <858nb6$bdo$[EMAIL PROTECTED]>,
"Jeff Moser" <[EMAIL PROTECTED]> wrote:
> What exactly does the little "o" in "Big-Oh" notation mean?
A function f(x) is said to be o(g(x)) if |f(x)/g(x)| --> 0 as
x --> oo.
For example, I
> know that o(1) becomes negiligible as the integer approaches infinity.
Really? Then you know something noone else does!
an integer is a constant. The expression "as the integer approaches
infinity" is meaningless drivel.
no flame intended.
f(x) is o(1) simply means (from the definition!)
|f(x)/1| --> 0 as x--> oo. Note: as x--> oo. x is a variable!
--
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: "Derek Potter" <[EMAIL PROTECTED]>
Subject: Re: Simple Encryption ...
Date: Mon, 10 Jan 2000 17:56:41 -0000
"David Wagner" <[EMAIL PROTECTED]> wrote
> The primitive you want is bit commitment. See Schneier
for protocols.
Sorry, I'm quiet clueless about this as you
can probably tell. I just use the encryption
for non-serious stuff. I suppose Schneier
is the encryption Bible and it's all somewhere
in the FAQ ?
>
> Your proposal doesn't look secure to me. There's plenty
of work which
> shows that, given the sum of two plaintexts, you can often
recover much
> of the two texts. (Example technique: guess a probable
word in one text;
> for each possible offset, subtract it from the sum; see
whether what
> remains looks like part of the other text; if so, extend
it forwards and
> backwards, recovering more and more information as you
go.)
Yes indeed, I'd sussed that much out myself.
But this is the sum of three plaintexts, so
you'd have to step through two offsets with
a *pair* of probable words. The main thing
for my requirement is that it is impractical
to do by hand and yet you do need to be able
to recognise a fragment of text on each
iteration so most people will be stumped.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: WSO have really protected my home PC with Windows 98 !
Date: Mon, 10 Jan 2000 17:52:22 GMT
In article <85bng9$d7f$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > >Need to protect your compter? I did. That's why I wrote Windows
> > >Security Officer. It works with Windows 95 and 98 systems, and it
can
> > >do the following for you :
> >
> > Sounds potentially useful. Do you have it posted anywhere for
> > download, and do you have docs/ manuals online? Me wanna see.
> >
> > Steve K
> >
> You can get more info about Windows Security Officer on :
> http://www.mach5.com/wso/officer.html
> Also you can download it from :
> http://www.mach5.com/download/secoff38.zip OR
> http://members.xoom.com/winsecof/secoff38.zip
No source code? Hmm no thanks. :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
