Cryptography-Digest Digest #121, Volume #13 Wed, 8 Nov 00 12:13:01 EST
Contents:
Re: "Software TEMPEST" explained (Mack)
Re: "Software TEMPEST" explained (Mack)
Re: Random Number Newsgroup (Mack)
Re: Hardware RNGs (Alan Rouse)
Re: hardware RNG's (Alan Rouse)
Re: Hardware RNGs (Mack)
Re: Randomness from key presses and other user interaction (Mack)
Re: MORE THAN FULLY BIJECTIVE ! (SCOTT19U.ZIP_GUY)
Going to NESSIE (Mack)
Re: algorithms before 1939 (Erik Runeson)
Re: Randomness from key presses and other user interaction ("Frog2000")
Re: Updated XOR Software Utility (freeware) Version 1.1 from (Scott Craver)
Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile (Scott Craver)
Re: hacker...beware ("jdm")
Re: Purported "new" BXA Encryption software export restrictions ("CMan")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: "Software TEMPEST" explained
Date: 08 Nov 2000 13:58:09 GMT
>On Thu, 19 Oct 2000 13:09:05 GMT, [EMAIL PROTECTED] (John
>Savard) wrote:
>
>>On Wed, 18 Oct 2000 12:13:52 GMT, [EMAIL PROTECTED]
>>(John Savard) wrote, in part:
>>
>>>I've revised the page since this posting to point out that I'm
>>>discussing a very simplistic scheme, that falls far short of the
>>>sophistication of the measures discussed in the paper by Markus Kuhn
>>>and Ross Anderson.
>>
>>Having added a second illustration of my simplistic scheme, I'm now
>>starting to wonder if it has been actually used, as I vaguely recall
>>seeing a computer display that looked sort of like it, on some TV
>>science-fiction or gadget spy show.
>>
>>John Savard
>
> John,
>
> Went there, but nothing "Tempest" jumped out at me though
>much worthy there as well. Did I miss it?
>
> Andrew
>
>>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
>
>
>
>
>
>
Hey ... It is gone ...
It was there ... where did it go?
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: "Software TEMPEST" explained
Date: 08 Nov 2000 14:02:14 GMT
>On Thu, 19 Oct 2000 13:09:05 GMT, [EMAIL PROTECTED] (John
>Savard) wrote:
>
>>On Wed, 18 Oct 2000 12:13:52 GMT, [EMAIL PROTECTED]
>>(John Savard) wrote, in part:
>>
>>>I've revised the page since this posting to point out that I'm
>>>discussing a very simplistic scheme, that falls far short of the
>>>sophistication of the measures discussed in the paper by Markus Kuhn
>>>and Ross Anderson.
>>
>>Having added a second illustration of my simplistic scheme, I'm now
>>starting to wonder if it has been actually used, as I vaguely recall
>>seeing a computer display that looked sort of like it, on some TV
>>science-fiction or gadget spy show.
>>
>>John Savard
>
> John,
>
> Went there, but nothing "Tempest" jumped out at me though
>much worthy there as well. Did I miss it?
>
> Andrew
>
>>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
>
>
found it
It is listed as Hardware Security
which is kind of misleading
for software tempest protection
the full link is
http://home.ecn.ab.ca/~jsavard/crypto/mi0606.htm
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Random Number Newsgroup
Date: 08 Nov 2000 14:03:56 GMT
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>> Does anyone know how the new random number newsgroup is coming along? I
>>> haven't heard anything since I (and other voters) were notified that the
>>> vote was to establish a newsgroup dealing with random numbers.
>
>> We have since quite a time sci.crypt.random-numbers.
>
>It passed 134:12 on 29 March 2000, the control message was sent on 3
>Apr 2000. I wouldn't feel left out if you don't get it, however, it
>never showed up here, either.
>
>You should be able to have your isp add it painlessly though, by
>pointing out that it passed the vote and is in the isc active file.
>
>--
>Matt Gauthier <[EMAIL PROTECTED]>
>
>
deja.com also carries and archives it if you want to see
the old postings
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 13:56:33 GMT
Benjamin Goldberg wrote:
> This seems to be a very stupid thing to do; It would be far more
> intelligent to calculate the amount of bias...
So sorry to have disappointed you with my stupidity. I was merely
illustrating a point, not proposing a system design.
There are a lot of people who think that if you take something with
limited randomness(like a password, or a few bytes of digitized sound)
and generate a 160-bit message digest from it, you effectively have 160
bits of cryptographic security. I am not one of those people, and
apparently you are not either.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: hardware RNG's
Date: Wed, 08 Nov 2000 14:09:04 GMT
David Schwartz wrote:
> ...it's not difficult to conclude that the variation is, at least
> in part, due to the temperature change. That and the fact that nobody
> else could measure that temperature change is all you need.
Not necessarily. Actually, the question of who can measure the temp
changes is completely irrelevant to the question of whether those
changes are random (although it is relevant to usability of the
randomness for cryptography).
In addition to what you stated, one needs to know something about the
physics of temperature changes in a crystal oscillator, and the
relationship between those changes and changes in oscillator
frequency. If the oscillator frequency is determined by the
temperature, then the randomness of the frequency is completely
dependent on the randomness of the temperature. I really don't know
that the temperature is not correlated with time. Actually I strongly
suspect that the temperature at time n is correlated to the temperature
at time n+1, at least for some sampling rates.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Hardware RNGs
Date: 08 Nov 2000 14:20:22 GMT
>
>Mack wrote:
>
>> The LSB of the RDTSC are purely deterministic. It increments one for each
>> clock tick. I may not be able to 'guess' the bits of the RDTSC but I can
>sure
>> calculate them. In a multi-process environment this is a bit more
>difficult
>> but
>> not impossible. It is effectively measuring the combined process run
>times.
>
> You can't calculate them because the number of clock cycles it takes to
>do many things the CPU takes is non-deterministic. For example, I go to
>read a block from a disk controller. Which CPU clock cycle that read
>comes in at is non-deterministic because it relies upon the exact ratio
>of two real numbers (the CPU oscillator and the disk controller
>oscillator).
>
Hard drive access times are not the same as the RDTSC being random.
Many workstations don't have hard-drives of thier own. The network
traffic is very easy to monitor. It can often be done from outside of the
building. Tempest certainly works if the cables aren't shielded.
> You would need to know an awful lot of internal timing data from the
>computer that would normally be completely inaccessible to an attacker.
>And, of course, any attempt you made to measure the disk controller's
>performance would change the very numbers you are measuring. The net
>result is that there is certainly no practical way and arugably no
>conceivable way to predict the LSB of the TSC.
>
> DS
>
I agree that there is no practical way. But the arguement was
strictly are the LSBs random. By themselves no.
Measuring other sources of randomness using the LSB of
the TSC will certainly give randomness. But that is
far from the TSC being random.
On a side note there is also the matter of hard disk turbulence
which produces a very slight amount of randomness. There are
also misreads which happen occassionally.
Does anyone know which IDE drives have indpendent internal
clocks and which ones synchronize the clock to the system bus?
This tends to be a serious issue in overclocked systems.
Ie. if the bus is overclocked the drive stops working.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Randomness from key presses and other user interaction
Date: 08 Nov 2000 14:24:44 GMT
>
>Tim Tyler wrote:
>>
>> David Schwartz <[EMAIL PROTECTED]> wrote:
>> : Mack wrote:
>>
>> :> There seems to be some argument as to whether timing
>> :> keystrokes is a good source of randomness.
>> :>
>> :> So lets start a thread on that.
>> :>
>> :> 1) Key stroke timing is generally quantitized to about 20 ms
>> :> give or take.
>>
>> : It's the give or take in the 20 ms that contains the entropy.
>>
>> Well, *if* this is true, this is not "randomness from key presses and
>> other user interaction" - it's more randomness from clock signal drift.
>
> The question is whether timing keystokes is a good source of
>randomness. I'm arguing that it is. Some of the entropy comes from the
>human, some of it from the quantization of real values built into the
>hardware. I happen to have a pretty good idea of how much entropy comes
>from the fact that the two oscillators involved have uncorrelated
>frequencies. I'm not as knowledgeable about the entropy in the
>keystrokes themselves.
>
> DS
>
But the thread was about the user interaction. There was
already a thread on oscillators.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: MORE THAN FULLY BIJECTIVE !
Date: 8 Nov 2000 14:29:12 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>Matt Timmermans <[EMAIL PROTECTED]> wrote:
>
>: Not particularly useful, you mean -- a fixed IV doesn't preserve all
>: the nice properties of CBC mode. CBC after whitening is almost as
>: good as CBC, though, except that an attacker can detect repeated
>: messages sent with the same key [...]
>
>...there are also some different error extension properties.
>
>: David, in this message, says simply that a surjection would serve his
>: purposes just as well, and so an IV can be supplied.
>
>I can't see what the problem is with supplying a random IV, and tacking it
>onto the front of the file.
>
>Sure, many messages now decrypt to the same cyphertext - but if you
>consider the set of all messages + IVs, and the set of all cyphertexts
>with tacked on IVs, then there appears to be a bijection between them.
>This is "the normal bijection" applied once for each IV.
>
>David appeared to imply that there was some difficulty in doing this -
>but I can't see what it is.
I my not be sure what your saying. But I guess what I like is the
fact every possible file could be compressed encrypted file that
had an IV including files of one byte. I mentioned the shuffling of the
IV others wise most extremely short files would have decrypted to the
null input file in Matts Code. Why have it obvious what any decyrption
is but these are all minor concerns there are no real difficulties
in implimenting various ways to do this if one wants too.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Going to NESSIE
Date: 08 Nov 2000 14:42:25 GMT
How many people from the News Group are attending the NESSIE
conference?
I will be away until the 21st or so.
I will respond to any posts that are rebuttals of
my posts then.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Erik Runeson <[EMAIL PROTECTED]>
Subject: Re: algorithms before 1939
Date: Wed, 08 Nov 2000 14:35:21 GMT
In article <8u9tv0$sa6$[EMAIL PROTECTED]>,
"Michal z Sopotu" <[EMAIL PROTECTED]> wrote:
> Hi
> I`m looking for some internet pages,magazines, books (or other
sources) of
> cipher/decipher algorithms used before 1939.
Check out "The Code Book", by Simon Singh. It's an exellent history of
cryptography and should be available at a reasonable price in most
bookstores.
I had the pleasure of seeing the author a few days ago when he
presented the price for the books code-breaking contest to a team of
five swedish graduate students in Stockholm.
-Erik Runeson
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Frog2000" <[EMAIL PROTECTED]>
Subject: Re: Randomness from key presses and other user interaction
Date: Wed, 8 Nov 2000 10:02:00 -0500
NO, usesrs aren't that random...
--
http://welcome.to/speechsystemsfortheblind
"Mack" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >
> >Tim Tyler wrote:
> >>
> >> David Schwartz <[EMAIL PROTECTED]> wrote:
> >> : Mack wrote:
> >>
> >> :> There seems to be some argument as to whether timing
> >> :> keystrokes is a good source of randomness.
> >> :>
> >> :> So lets start a thread on that.
> >> :>
> >> :> 1) Key stroke timing is generally quantitized to about 20 ms
> >> :> give or take.
> >>
> >> : It's the give or take in the 20 ms that contains the entropy.
> >>
> >> Well, *if* this is true, this is not "randomness from key presses and
> >> other user interaction" - it's more randomness from clock signal drift.
> >
> > The question is whether timing keystokes is a good source of
> >randomness. I'm arguing that it is. Some of the entropy comes from the
> >human, some of it from the quantization of real values built into the
> >hardware. I happen to have a pretty good idea of how much entropy comes
> >from the fact that the two oscillators involved have uncorrelated
> >frequencies. I'm not as knowledgeable about the entropy in the
> >keystrokes themselves.
> >
> > DS
> >
>
> But the thread was about the user interaction. There was
> already a thread on oscillators.
>
>
> Mack
> Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from
Date: 8 Nov 2000 15:19:32 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>>
>> I, like you, marvel at how poor the programming had to have been such that
>> 1.0 couldn't open up files in 2 different directories. :-)
>With all your (all those in this news group) experience in
>programming and encryption and aesthetics, it is I and not most of
>you with the ideas and the software products and the strategy and
>the GOOD will to get these fully functional products out to the
>public.
You can't read. Others have already written this utility and
made it available to the public. I mean, even the source code.
And it's such a dinky little utility too. Who's going to download
hundreds of kilobytes of executable code to perform a simple XOR?
Could someone please submit Mr. Szopa's executable to bloatbusters?
It's not like 7MB large, but it is huge for its intended purpose.
And the fact that, somehow, the first version couldn't open files
in separate directories (despite all the functionality available
in file open dialogs) really makes it funny.
-S
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto
Subject: Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile
Date: 8 Nov 2000 15:15:20 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>"Trevor L. Jackson, III" wrote:
>>
>> Pointing out the limitations of your software is to amusement as Jerry Springer is
>> to entertainment.
>
>You said it: so what are the limitations of the XOR software
>utility?
We just *told* you. It's a huge binary, not open, and only runs on a
single platform.
-S
------------------------------
From: "jdm" <[EMAIL PROTECTED]>
Crossposted-To:
alt.lang.basic,alt.permaculture,alt.surfing,alt.surfing.europe.uk,aus.computers.linux,comp.os.linux.setup
Subject: Re: hacker...beware
Date: Wed, 08 Nov 2000 15:33:53 GMT
The only time I even get mildly annoyed by firewall alerts any more is
when I see a service like Netbus, Sun/RPC Portmap, Telnet, or
"Unknown". Then I just click the Block button and forget about it.
John M.
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Crossposted-To: alt.freespeech,talk.politics.misc,talk.politics.crypto,alt.hacker
Subject: Re: Purported "new" BXA Encryption software export restrictions
Date: Wed, 8 Nov 2000 09:16:29 -0700
At the time the White House held a news conference to announce that they had
"relaxed" the encryption regulations I was convinced that the White House
was again lying about what was being done re: encryption.
At that news conference Attorney General Janet Reno was asked if the new
regulations had changed anything. She at first avoided the question. Then
the reporter pointed out that she had not answered the question and
repeated, What has changed?" Her reply in a rare fit of honesty was "Nothing
has changed!"
The White House, staff putting on this incredible dog and pony show
involving that idiot Commerce Secretary Casey, was of course apoplectic at
this truthful answer.
I encourage anyone who has swallowed the lies put forth by the White House
on encryption policy to go to the BXA web site and read the regs.
NOTHING HAS CHANGED!!!!!!!
The encryption regulations HAVE NOT BEEN RELAXED!!!
Read the classification procedure. There is still unconstitutional prior
restraint!!! I'd rather fill out a thousand tax returns than try to comply
with these regulations. There is NO WAY anyone could become compliant
without expert legal counsel and then only if your code passes review and
meets unpublished requirements - like backdoors maybe - or "workfactor
reduction fields."
I can't believe they were able to pull the wool over the eyes of our famous
cryptographer friends who have written popular books on cryptography -
unless these guys now have corporations and big fat government contracts!!!
Hey BXA, give me a big fat government contract and I'll stop pointing out
the emperor's lack of clothing just like the rest of them!! C'mon, share the
wealth...
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Purported "new" BXA Encryption software export restrictions
>
> I have had time to look up these purported new BXA regs.
>
> But first let me digress.
>
> The OAR-L3 random number generation software is exactly the same
> software as OAP-L3: Original Absolute Privacy - Level3 encryption
> software except there is absolutely NO encryption or decryption
> capability.
>
> Not only have the encryption and decryption GUI forms, menus,
> buttons, etc. been deleted, but also, the encryption and decryption
> source code has been deleted, then the entire package recompiled.
> So there is no way to enable any encryption or decryption methods
> or capabilities using OAR-L3.
>
> You can download OAR-L3 Random Number Generation Software by
> going to http://www.ciphile.com
>
> Go to the Downloads Currently Available web page.
> Scroll to the bottom of the page.
>
> Click on the blue anchor tag: OARL3_41.zip and ReadMe_R.zip to
> download.
>
> There is a new XOR Software Utility (freeware) available at
> http://www.ciphile.com
>
> Go to the Downloads Currently Available web page.
> Scroll to the bottom of the page.
>
> Click on the blue anchor tag: CiphileXOR_11.zip to download.
>
> OAP-L3 encryption software uses the XOR process to encrypt messages.
>
> Now my comments and decision regarding these purported new BXA regs:
>
> Except for (I think) there are no longer any restrictions on key
> length and that the software can be exported immediately, there is
> one major proviso in any case:
>
> The exporter needs to file an encryption classification request by
> the time the encryption software is exported. Here is what the
> exporter must do:
>
> "For all classification requests of encryption items provide
> brochures or other documentation or specifications related to the
> technology, commodity or software, relevant product descriptions,
> architecture specifications, and as necessary for the technical
> review, source code. Also, indicate any prior reviews and
> classifications of the product, if applicable to the current
> submission. Provide the following information in a cover letter
> with the classification request:
> (a) State the name of the encryption item being submitted for
> review.
> (b) State that a duplicate copy has been sent to the ENC
> Encryption Request Coordinator.
> (c)For classification request for a commodity or software,
> provide the following information:
> (1) Description of all the symmetric and asymmetric encryption
> algorithms and key lengths and how the algorithms are used. Specify
> which encryption modes are supported (e.g., cipher feedback mode or
> cipher block chaining mode).
> (2) State the key management algorithms, including modulus
> sizes, that are supported.
> (3) For products with proprietary algorithms, include a textual
> description and the source code of the algorithm.
> (4) Describe the pre-processing methods (e.g., data compression
> or data interleaving) that are applied to the plaintext data prior
> to encryption.
> (5) Describe the post-processing methods (e.g., packetization,
> encapsulation) that are applied to the cipher text data after
> encryption.
> (6) State the communication protocols (e.g., X.25, Telnet or
> TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS standards)
> that are supported.
> (7) Describe the encryption-related Application Programming
> Interfaces (APIs) that are implemented and/or supported. Explain
> which interfaces are for internal (private) and/or external (public)
> use.
> (8) Describe whether the cryptographic routines are statically
> or dynamically linked, and the routines (if any) that are provided
> by third-party modules or libraries. Identify the third-party
> manufacturers of the modules or toolkits.
> (9) For commodities or software using Java byte code, describe
> the techniques (including obfuscation, private access modifiers or
> final classes) that are used to protect against decompilation and
> misuse.
> (10) State how the product is written to preclude user
> modification of the encryption algorithms, key management and key
> space.
> (11) For products that qualify as ``retail'', explain how the
> product meets the listed criteria in Sec. 740.17(b)(3) of the EAR.
> (12) For products which incorporate an open cryptographic
> interface as defined in part 772 of the EAR, describe the Open
> Cryptographic Interface.
> (d) For classification requests regarding components, provide
> the following additional information:
> (1) Reference the application for which the components are used
> in, if known;
> (2) State if there is a general programming interface to the
> component;
> (3) State whether the component is constrained by function; and
> (4) the encryption component and include the name of the
> manufacturer, component model number or other identifier.
> (e) For classification requests for source code, provide the
> following information:
> (1) If applicable, reference the executable (object code)
> product that was previously reviewed;
> (2) Include whether the source code has been modified, and the
> technical details on how the source code was modified; and
> (3) Include a copy of the sections of the source code that
> contain the encryption algorithm, key management routines and their
> related calls."
>
> IN EFFECT NOTHING HAS CHANGED.
>
> I am not able to go through all this hassle.
>
> I am sorry.
>
> AS
------------------------------
** 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
******************************
