Cryptography-Digest Digest #51, Volume #9 Sun, 7 Feb 99 18:13:04 EST
Contents:
Re: Java random (Paul Rubin)
Intel's description of the Pentium III serial number (Anonymous)
Re: RNG Product Feature Poll (Michael Sierchio)
Rsa cryptology as a personal math project (MarcusOman)
Re: Rsa cryptology as a personal math project (Jim Gillogly)
Re: Intel's description of the Pentium III serial number (Nogami)
Re: Q: Obtaining session key (Michael Kjorling)
Re: MAC generation (Michael Kjorling)
Re: Block Cipher Test Vectors (Michael Kjorling)
Re: Practically unbreakable encryption for windows files/folders (Michael Kjorling)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Java random
Date: Sun, 7 Feb 1999 18:37:24 GMT
In article <79k3r3$qne$[EMAIL PROTECTED]>, Else <[EMAIL PROTECTED]> wrote:
>>Why do you need to generate entropy on the client? Is the client
>>trying to create a secret that it needs to keep away from the server?
>>If not, how about having a native RNG on the server side and have the
>>server send some initial PRNG state to the client over the SSL
>>connection?
>
>The Java clients is only one part of a much larger project. Clients generate
>RC4 session keys and pass them to the server encrypted with RSA - just like
>SSL does. We could not get acceptable SSL license on all platforms we have
>to support.
Well, ok, this surprises me, but without knowing more about your
situation I can't make concrete suggestions about SSL vendors.
>Besides, who said SSL generates better keys than this method?
Well, SSL normally runs at the native level, where it has access to
better sources of entropy. Whether it does a good job with them is
another matter (Netscape 1.0 had a famous bug relating to this).
>>I'm a little skeptical of this. If the counter goes to a few thousand
>>in 10 ms, what is the statistical distribution if you do that several
>>thousand times? Have you looked at that? You might be getting only a
>
>I've done preliminary analysis already. The distribution looks gaussian with
>the average around 10,000 and standard deviation of 1,500 - should be enough
>for 1 byte. The output looks completely flat. I am somewhat concerned with
>the performance on slower computers, though. More tests are planned.
That's interesting and encouraging. Please publish what you find.
Btw, what speed computer was that on?
Btw2, here's a thought that might be bogus. A gaussian distribution
often means that the variable is the sum of a bunch of other random
variables that are not gaussian. I wonder if counting for shorter
intervals might
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.intel
Subject: Intel's description of the Pentium III serial number
Date: 7 Feb 1999 19:42:59 +0100
<SNIP>
> Processor serial number technical notes
> Reading Processor Serial Number
>
> A software application can read the processor serial number if it
> executes the processor serial number read instruction and the processor
> serial number is enabled (MSR bit set to a '0'). The processor serial
> number is not an "active" element of the system - it does not broadcast
> itself to the operating system, applications, or across the Internet. The
> processor serial number is "passive" - available only if the operating
> system or application executes the processor serial number read
> instruction. This means that websites on the Internet cannot directly
> read a system's processor serial number. A website has to send the
> system a separate piece of software in order to read and return it's
> processor serial number. The following steps summarize this process:
>
> 1. User visits a website
> 2. Website wants to access the processor serial number of the
> user's system
> 3. Website typically asks user permission to access personal
> information, including processor serial number
Emphasis on the word 'typically'?
<SNIP>
> This method of controlling access to the processor serial number is
> consistent with safe behavior when accessing the Internet - never grant
> an Internet site permission to download software to your system unless
> you trust the source of the software. Trusting means that you believe it
> is both safe to run the software on your system and the website will use
> any information gathered in a appropriate manner, often outlined in the
> website's privacy policy or legal notice. For an example, see Intel's own
> privacy policy.
How many users would simple say yes without second thought?
<SNIP>
> Controlling Processor Serial Number
>
> There are two main ways for users to control the state of the processor
> serial number, whether it is enabled or disabled. The first is the Intel
> processor serial number control utility. The processor serial number
> control utility is a Windows* program developed by Intel to give users
> direct control and choice over whether processor serial number is
> enabled or disabled on their system. The second way is through the
> system BIOS.
<SNIP>
> The Intel processor serial number control utility can be obtained from
> Intel's website after the introduction of the Pentium III processor. Many
> PC manufacturers will also include the control utility with their systems
> or make the utility available via their web sites.
<SNIP>
> * ON when the processor first resets (hardware requirement)
> * ON when the BIOS executes (BIOS switch default is "enabled")
> * OFF when the control utility executes (control utility default
> turns processor serial number feature "OFF")
Lemme get this straight: these guys are with a straight face
claiming that the S/N defaults to off because of some stupid
piece of software that has to be downed from their friggin'
website? Quote:
> This default protocol ensures that the first time a user operates his/her
> system, the processor serial number is disabled. The processor serial
> number feature will then stay disabled until the user uses the control
> utility to enable it.
This is false information. The S/N defaults to on, and STAYS on,
until and after the user takes a little tour a'surfin' and goes
to Intel's website and download a piece of software (of course
they record your S/N when you do that)! Only THEN you can install
a *software* which, once installed, will default to having the
processor S/N off. The default protocol does NOT ensure that the
S/N is off. Shouldn't Intel be liable for this kinds of false
statements?
Intel - Outright Liars.
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: RNG Product Feature Poll
Date: Sun, 07 Feb 1999 11:06:33 -0800
Reply-To: [EMAIL PROTECTED]
"R. Knauer" wrote:
Knauer -- I think that you're either being disingenuous or stupid. Most
of your posts lead me to believe that you're intelligent, so I think
you're intentionally misconstruing the point.
> >Reasonable statistical properties are more than enough for cryptography,
> You will have to prove that assertion - I cannot take it on your word
> alone. In particular, I would have to see how indeterminancy comes
> from "reasonable statistical properties".
Herman will correct me, but statisticians regard a sequence of outcomes as
random if each outcome is independent of the previous ones. This is sufficient
for crypto, and explains why PNRGs are inadequate -- if you include choice of
initial conditions in "previous outcomes."
> The half life of a radioactive isotope is a measure of indeterminancy
> in time of when it will decay, and the spectral half width of the
> energy spectrum is a measure of indeterminancy in energy of what
> energy it will have when it decays.
Sorry, that's not only not a definition, it's wrong. A radioisotope's
half life isn't any kind of "measure of indeterminacy" -- it's
a "characteristic." It's of no value in determining the approximate
entropy in the series of decay events.
> >I did not quantify it; I gave an estimate on the best order of the
> >problem. How accurately can a counter measure a short interval of
> >time?
>
> Pretty damn accurately.
Oh, yeah -- and I suppose you find your way home by Brownian motion!
------------------------------
From: [EMAIL PROTECTED] (MarcusOman)
Subject: Rsa cryptology as a personal math project
Date: 7 Feb 1999 19:47:57 GMT
Hello,
I am studying in France as a somphmore and I have chosen to study cryptology,
and more specifically the way Rsa works.
My mathematics professor has explained to me the basic theorems involved in
cryptology, such as the Chinese Theorem and Fermat's little theorem, but I
would like to know if someone could explain to me what is really involoved in
cryptology, and what is the difference between a public and a private key.
I was also wondering if anybody had ever broken down a key and was therefore
able to "uncrypt" a message. Is it really true that the Russian army uses this
system to protect its nuclear codes?
Thank you very much,
Marc
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Rsa cryptology as a personal math project
Date: Sun, 07 Feb 1999 12:34:56 -0800
MarcusOman wrote:
> I am studying in France as a somphmore and I have chosen to study
> cryptology,
> and more specifically the way Rsa works.
A laudable goal. I suggest you get a copy of F. L. Bauer's book
"Decrypted Secrets" or the original "Enzifferte Geheimnisse" if
you're more comfortable in German. This will give you the
background of cryptography you need, as well as some
mathematical underpinnings to help you get started.
> would like to know if someone could explain to me what is really
> involoved in
> cryptology, and what is the difference between a public and a
> private key.
Bauer's a good choice for that. See also the FAQ at www.rsa.com,
or the FAQ posted monthly to this group.
> I was also wondering if anybody had ever broken down a key and was
> therefore
> able to "uncrypt" a message. Is it really true that the Russian
> army uses this
> system to protect its nuclear codes?
Yes, many keys have been broken. Since you're interested specifically
in RSA, you might check the RSA challenges at www.rsa.com. Most
recently RSA-140 was factored, the largest to date. A smaller
(384-bit) "live" PGP RSA key was broken in 1995 by Paul Leyland,
Arjen Lenstra, Alec Muffett, and Jim Gillogly, allowing the decryption
of messages sent to that key.
You might check with the Russian army for information on their
nuclear codes; write back if you find anything earth-shaking,
so to speak.
--
Jim Gillogly
Mersday, 17 Solmath S.R. 1999, 20:24
12.19.5.16.12, 6 Eb 5 Pax, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Nogami)
Crossposted-To: comp.sys.intel
Subject: Re: Intel's description of the Pentium III serial number
Date: Sun, 07 Feb 1999 20:44:09 GMT
On 7 Feb 1999 19:42:59 +0100, Anonymous <[EMAIL PROTECTED]> wrote:
>> 3. Website typically asks user permission to access personal
>> information, including processor serial number
>
>Emphasis on the word 'typically'?
I'm not terribly concerned about being able to disable the serial
number, or prevent it from being read...
What I AM concerned about is websites (and software authors) that just
block all access unless you enable it, thus forcing your hand.
N.
------------------------------
From: [EMAIL PROTECTED] (Michael Kjorling)
Subject: Re: Q: Obtaining session key
Date: Sat, 06 Feb 1999 11:18:33 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Your scheme looks pretty good, but the hash of all previously processed
plaintexts obviously has some problems. If you store the plaintexts, then what
is then the point of encrypting them?
I would suggest to concentate the current plaintext with the last two hash
values, then hashing the result. I'd say that this scheme is much better than
yours, but cryptography is a black art, so if anyone knows better, please let
me know.
//Michael
On Wed, 27 Jan 1999 16:26:13 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Hash all previously processed plaintexts. Encrypt the hash with
> a masterkey to obtain the current session key.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: PGP 6.0.2i executables: coming soon to a server near you
iQA/AwUBNrwMdiqje/2KcOM+EQJlJgCfTW5nwsJjNKv71lKoIVr7FXMdnwEAnjJ7
mc57X1lv5fso5TgXR10+20je
=COhN
=====END PGP SIGNATURE=====
_________________________________________
Mann mu� nicht Gro� sein, um Gro� zu sein
=========================================
Remove "no" in e-mail address to reply.
=========================================
PGP Key ID : 0x8A70E33E
Fingerprint: 95F1 074D 336D F8F0 F297
6A5B 2AA3 7BFD 8A70 E33E
------------------------------
From: [EMAIL PROTECTED] (Michael Kjorling)
Subject: Re: MAC generation
Date: Sat, 06 Feb 1999 19:35:07 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I'd suggest an (as far as I know) even better variant of this scheme:
H(K,M,K)
or even better than that
H(K1,M,K2)
Where H(M) is the hashing algorithm, MD5 in your case. According to Bruce
Schneier, Applied Cryptography, 2nd edition, page 459:
"The best approach is to concatenate at least 64 bits of the key with each
message block. This makes the one-way hash function less efficient, because
the message blocks are smaller, but it is much more secure [1265]."
Reference #1265, on page 726, reads:
"B Preneel, personal communication, 1995."
Perhaps selecting a different number of key bits to append to each message
block for each block would be even more secure. As long as this number remains
secret (it can even be calculated from the key), I can't see how that could
decrease security, and if the algorithm is fast, it wouldn't take so much
longer to do the processing.
Any comments on this scheme?
//Michael
On Fri, 05 Feb 1999 21:49:45 GMT, [EMAIL PROTECTED] (John
Savard) wrote:
>"Vadim Lebedev" <[EMAIL PROTECTED]> wrote, in part:
>
>>Hello i need an opinion on validity and possible weakness of following
>>approach to generate MAC for messages 20 to 200 bytes longs.
>>Assuming that S is the contents of the message the MAC will be
>> MD5(S+SecretPassPhrase)
>
>Probably MD5(SecretPassPhrase+S) is 'better', if your goal is to have
>a secret MAC to authenticate strongly. This way, your secret pass
>phrase, instead of just encrypting the MAC at the end, encrypts the
>initial value at the start, thus affecting everything that happens
>later.
>
>Actually, while both approaches are secure, though, for a keyed MAC,
>I'd like something even better. I'd like it to affect the process from
>beginning to end, in a nonlinear fashion!
>
>I think I may have to settle for MD5(SecretPassPhrase +
>SVigeneredBySecretPassPhrase ) or something like that for now. But
>you've started me thinking about how to design an algorithm
>specifically designed for keyed MAC use. (Panama already has that kind
>of capability too...)
>
>John Savard
>http://www.freenet.edmonton.ab.ca/~jsavard/index.html
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: PGP 6.0.2i executables: coming soon to a server near you
iQA/AwUBNrxZCCqje/2KcOM+EQKp/ACffedYSIh/j3o+PBdV4E2Pno9t/E4AnRhY
ukomlUm72EANScK9SrC5AaZa
=OmGf
=====END PGP SIGNATURE=====
_________________________________________
Mann mu� nicht Gro� sein, um Gro� zu sein
=========================================
Remove "no" in e-mail address to reply.
=========================================
PGP Key ID : 0x8A70E33E
Fingerprint: 95F1 074D 336D F8F0 F297
6A5B 2AA3 7BFD 8A70 E33E
------------------------------
From: [EMAIL PROTECTED] (Michael Kjorling)
Subject: Re: Block Cipher Test Vectors
Date: Sat, 06 Feb 1999 19:58:32 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Not as far as I know, but I've got my hands on some RC6 test vectors:
Test vectors for encryption with RC6
plaintext 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
user key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ciphertext 8f c3 a5 36 56 b1 f7 78 c1 29 df 4e 98 48 a4 1e
plaintext 02 13 24 35 46 57 68 79 8a 9b ac bd ce df e0 f1
user key 01 23 45 67 89 ab cd ef 01 12 23 34 45 56 67 78
ciphertext 52 4e 19 2f 47 15 c6 23 1f 51 f6 36 7e a4 3f 18
plaintext 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
user key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
ciphertext 6c d6 1b cb 19 0b 30 38 4e 8a 3f 16 86 90 ae 82
plaintext 02 13 24 35 46 57 68 79 8a 9b ac bd ce df e0 f1
user key 01 23 45 67 89 ab cd ef 01 12 23 34 45 56 67 78
89 9a ab bc cd de ef f0
ciphertext 68 83 29 d0 19 e5 05 04 1e 52 e9 2a f9 52 91 d4
plaintext 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
user key 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ciphertext 8f 5f bd 05 10 d1 5f a8 93 fa 3f da 6e 85 7e c2
plaintext 02 13 24 35 46 57 68 79 8a 9b ac bd ce df e0 f1
user key 01 23 45 67 89 ab cd ef 01 12 23 34 45 56 67 78
89 9a ab bc cd de ef f0 10 32 54 76 98 ba dc fe
ciphertext c8 24 18 16 f0 d7 e4 89 20 ad 16 a1 67 4e 5d 48
On 5 Feb 1999 23:18:12 GMT, [EMAIL PROTECTED] (Logi Ragnarsson) wrote:
>I've been looking around the web, but haven't found any collections of
>test-vectors for block-ciphers. Is there such a collection somewhere?
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: PGP 6.0.2i executables: coming soon to a server near you
iQA/AwUBNryQ0iqje/2KcOM+EQJasgCfY1eMLXTI4q2Dw7oirDjsMOLwR1sAnRrf
ny6eqQbmM52aMT4pgwfIKgUb
=97cH
=====END PGP SIGNATURE=====
_________________________________________
Mann mu� nicht Gro� sein, um Gro� zu sein
=========================================
Remove "no" in e-mail address to reply.
=========================================
PGP Key ID : 0x8A70E33E
Fingerprint: 95F1 074D 336D F8F0 F297
6A5B 2AA3 7BFD 8A70 E33E
------------------------------
From: [EMAIL PROTECTED] (Michael Kjorling)
Subject: Re: Practically unbreakable encryption for windows files/folders
Date: Sat, 06 Feb 1999 19:53:23 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I wouldn't trust this implementation of IDEA. Basicly, this is for two
reasons.
(1) They say "Do not be afraid of forgetting one of your passwords - you can
save your passwords on disk". This is a potential security risk
(2) There was a DES disk encryptor for the Macintosh (don't remember the
name), which saved the encryption key along with the encrypted information. As
Scheier writes in Applied Cryptography, 2nd edition, page XXX, "It doesn't
matter that the package is using DES; the implementation is completely
insecure."
Also, they say that it would take 149.745.258.842.898 years to crack an
128-bit IDEA key on a machine that can crack a 56-bit DES key in one second.
However, I can see nothing about one-way hash functions or anything such, so
I'd assume that the password simply *is* the key to the cipher. That decreases
the number of probable keys by many orders of magnitude, making the attack so
much easier. I mean, who's really gonna choose the password
yZ)I|p#(1B::-1]$
when they can choose
Flintstone, Fred
No, then I'd prefer PGPdisk. Perhaps I'll have to wait for an extra week or
two, but at least it's (1) free with source code availible, and (2) uses CAST,
which seems to be faster than IDEA, and public-key cryptography so that others
may access the files. Also, it (3) allows me to seamlessy integrate
military-grade encryption into virtually any application.
I wouldn't have a good time paying $55 when I can get exactly the same or even
better results for $0,50... (telephone charges)
//Michael
On Fri, 5 Feb 1999 00:07:30 +0700, "olympic" <[EMAIL PROTECTED]> wrote:
>Practically unbreakable encryption for windows files/folders can be
>downloaded from
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: PGP 6.0.2i executables: coming soon to a server near you
iQA+AwUBNryPliqje/2KcOM+EQKeBgCeNQB/HyM3fpGEwQVp2Q8tsyaRPS0AmM9i
NkgquTGcDaQb0jeowOBsE74=
=rprQ
=====END PGP SIGNATURE=====
_________________________________________
Mann mu� nicht Gro� sein, um Gro� zu sein
=========================================
Remove "no" in e-mail address to reply.
=========================================
PGP Key ID : 0x8A70E33E
Fingerprint: 95F1 074D 336D F8F0 F297
6A5B 2AA3 7BFD 8A70 E33E
------------------------------
** 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
******************************
