Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #14Tue, 3 Apr 01 01:13:00 EDT
Contents:
Re: Public Domain MARS Implementation Source Code ("Roger Schlafly")
Re: Idea - (LONG) (Nicol So)
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: AES VS. DES ("Douglas A. Gwyn")
Re: keys and random (Brian D Jonas)
FTP Server - AES C++ Implementation + Sourcecode ("James Wyatt")
Re: keys and random ("Tom St Denis")
FTP UP ("James Wyatt")
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Data dependent arcfour via sbox feedback (Terry Ritter)
Re: Avoiding bogus encryption products: Snake Oil FAQ (Ichinin)
Re: Data dependent arcfour via sbox feedback (Ichinin)
simple libdes question ("Sean Kelly")
Re: simple libdes question ("Douglas A. Gwyn")
PK Algorithm Idea ("Tom St Denis")
Re: simple libdes question (Jim Gillogly)
rational PK? ("Tom St Denis")
Re: simple libdes question (Paul Rubin)
From: "Roger Schlafly" [EMAIL PROTECTED]
Subject: Re: Public Domain MARS Implementation Source Code
Date: Tue, 03 Apr 2001 00:42:24 GMT
"Eric Lee Green" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
On Mon, 02 Apr 2001 22:12:31 GMT, Nathan J. Yoder [EMAIL PROTECTED]
wrote:
This may sound like a trivial/stupid question, but I am looking for
an
implementation of MARS that has been released in the public domain. I
have
Note that MARS may be covered by several IBM patents. You may wish to
contact an intellectual law expert prior to using MARS in any design.
IBM has granted royalty-free license to use its Mars patents to implement
Mars, regardless of whether or not it won the AES contest. (Mars didn't win,
but you are free to use it anyway.)
--
From: Nicol So [EMAIL PROTECTED]
Subject: Re: Idea - (LONG)
Date: Mon, 02 Apr 2001 21:12:09 -0400
Reply-To: see.signature
Mok-Kong Shen wrote:
Nicol So wrote:
It's actually quite simple. Consider a source that outputs a sequence of
8-bit characters of even parity. Now a message of N characters consists
of N*8 bits, but the amount of entropy needed to transmit the message
with perfect secrecy is only N*7 bits. You don't need to expend 8 bits
of shared randomness to perfectly mask a plaintext symbol--you can use
an random even-parity character with only 7 bits of randomness.
The point is: source characteristics affect the amount of key entropy
required for perfect secrecy.
... But how about the case where he
doesn't have that knowledge? Does it help anything in
security? Thanks.
If you don't know the exact amount of entropy in the plaintext, and
still want to have perfect secrecy, you may be able to use a safe
overestimate, depending on how much partial knowledge you have. In some
cases, that may mean assuming the source to be potentially of maximum
entropy, as a practical necessity. However, practical necessity is not
what this (sub)thread is about.
In a previous message, you wrote:
If one has r bits of truly random bits (never mind how to
get this), one can *only* encrypt r bits with perfect
security in the sense of Shannon.
[emphasis added]
And Douglas Gwyn, apparently sensing a misappreciation of Shannon's
result, responded and wrote:
Well, no, it depends on the source characteristics.
Judging from your follow-ups, you didn't seem to get the point of the
comment.
What I've been doing was trying to clarify the point Douglas Gwyn made,
and not trying to address issues with practical application of OTP.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
--
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Tue, 03 Apr 2001 02:35:31 GMT
Ken Savage wrote:
Bryan Olson wrote:
I'm not sure it's been stated, so I'll note an obvious
defect in the proposed scheme: If we grant the attacker
multiple known plaintexts from the same starting state, he
can easily discover the state.
Forgive the list of questions...
1) By 'state', are you referring to the sbox/x/y/c values,
or are you referring to the random stream's contents which
are xor'ed with the plaintext?
The sbox/x/y/c values.
In the first case, you would
be able to continuously predict the PRNG, but the latter
would be squashed by the length of the longest plaintext.
Right.
2) How would this be any different from standard RC4?
With RC4 getting the sequence is automatic from one known
plaintext
Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #13Wed, 1 Nov 00 05:13:01 EST
Contents:
Re: Psuedo-random number generator (David Schwartz)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: Really Strong Cipher Idea? (Mok-Kong Shen)
Re: On introducing non-interoperability (Mok-Kong Shen)
Re: Give it up? (Mok-Kong Shen)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: XOR based key exchange protocol - flawed? (Mike Connell)
Re: how i decode this? (Paul Schlyter)
Re: Rijndael file encryption question. ("Brian Gladman")
Re: Newbie about Rijndael (Dido Sevilla)
Re: 3-dimensional Playfair? (Daniel)
From: David Schwartz [EMAIL PROTECTED]
Subject: Re: Psuedo-random number generator
Date: Tue, 31 Oct 2000 23:54:43 -0800
David Schwartz wrote:
By the way, you can find example code demonstrating this technique at
http://youknow.youwant.to/~djls/entropy.c
DS
Below is the middle of 10 seconds of jitter measured by sending the
same corrupt DNS query to a name server on the LAN right next to my
machine (the query is obviously invalid and the name server will send
back a failure message immediately). Both machines were quiet at the
time and the logging was done to memory and then dumped to eliminate
other sources of randomness. The offsets are against the machine's
600Mhz TSC (from the program in the URL above):
75c559f4420cf64c2cb03d370aae1e805e5b0e0a1382fb2c34c223ad3f65f9c560d2b9b786b7546b
d8566d8e66205168e39a386d9f6e33830ba6e4d2df2e666475dbabc881413b8ac4f9d8262f9e2bb6
8af21283583e307c64a7bb951905860dbdfb01ece4c48f1f8447256ce3db272c3f86af0fa0afddad
436010788be030687ec28501749565a103eb0a5fda18e4801199d5e2c576e7fa3f3f5203a453d5b8
f12f8ac17e3a2121aececb360e95dca5297ccd929531493becb94afecfb822bde4a8e85960d8dce5
999a9e159c65624487b8476fc550aaef9c6bfe44f7b8bca0df7452626a4812925383376d956e1fec
51cb4c6658a82ca0b7633b6b435104b51583177666132742cb5ee3e071c85eb2b1fdf78dcfe8a66a
b2aeb6689e6608df953320510a960d068ebe8c44dc5414d46474d5b786b9ba3911d11a1f834e3677
1e0a36262eaf7318cadf0a746ecfcd94c9651bb3b600420e0681b239b301810d4425dc645abc026c
cf07328b7b909edb1d8c13c5e8d3602373a3508d65b7ceed343b96bcbc13526be7e34b6840c0b55c
While not unbiased, the data is unpredictable.
DS
--
From: Mike Connell [EMAIL PROTECTED]
Subject: Re: XOR based key exchange protocol - flawed?
Date: 01 Nov 2000 09:28:47 +0100
Benjamin Goldberg [EMAIL PROTECTED] writes:
David Wagner wrote:
Mike Connell wrote:
Pa, Pb are RSA public keys. (X)Pi means data X encrypted under key
Pi. Xa, Xb are random blocks of data of the same size as the public
keys.
1. a - b : Pa
2. a - a : Pb
3. a - b : (Xa)Pb
4. a - b : (Xb)Pa
Then a and b compute the XOR of Pa,Pb,Xa,Xb.
I don't understand the "MITM attacks" others are posting on your
scheme.
If you don't have any way to validate the public key that the other
guy is using, then any authentication protocol you use will be
susceptible to a MITM attack. That's just unavoidable, and is not
a flaw of the authentication protocol.
The point is that secure authentication protocols tell you, at the
end of the protocol run, who you are talking to. An attack is where
the malicious guy Mallet can get you to think you are talking to Alice
when in fact you are really talking to Mallet.
It is NOT an attack if at the end of the protocol you think you are
talking to Mallet and you are correct in this belief. If you send
secrets to Mallet, knowing that it is her that you're sending them to,
well, that's not the fault of the authentication protocol.
In this case, when the protocol completes, I think you always know
the public key of the other person you are talking with. There are
other issues (like replay attacks), but I don't think MITM attacks
is one of them.
Am I missing something?
Yes. Since the public keys are transmited *as part of the protocol*,
this implies that they are ephemeral, and were generated for this
session only. You therefor can't know who they actually belong to. If
the protocol said that, at some earlier time, a and b had exchanged
public keys, and b trusts that the owner of "public key a" is a, and a
trusts that the owner of "public key b" is b, then what you said would
be absolutely 100% correct.
Both cases might apply. The keys might have been exchanged previously,
in which case both parties know that the key represents an actual
person.
If that wasn't the case, all the user knows about the "person" is what
they have said to the user, and what the user has said to them. I
think the MITM implications have been done to death now ;)
best wishes,
Mike.
--
Mike Connell [EMAIL PROTECT
Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #12 Mon, 19 Jun 00 19:13:00 EDT
Contents:
Re: Extended Euclidean Algorithm (Mok-Kong Shen)
Re: Forgot ZIP File password. (Simon Johnson)
Re: Small compression/encryption problem (Rickman)
Re: Random sboxes... real info (tomstd)
Re: Forgot ZIP File password. (tomstd)
Re: Random sboxes... real info (Roger Carbol)
Re: Extended Euclidean Algorithm (Simon Johnson)
Re: Extended Euclidean Algorithm (tomstd)
Re: Forgot ZIP File password. (Simon Johnson)
Re: Encryption on missing hard-drives (Paul Rubin)
Re: Random sboxes... real info (michael)
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Cipher design a fading field? ("Douglas A. Gwyn")
Re: Weight of Digital Signatures ("Douglas A. Gwyn")
Re: Extending LFSR.. ("Douglas A. Gwyn")
Re: oneway encryption for password (David P Jablon)
Re: Extending LFSR.. ("Douglas A. Gwyn")
Re: quantum cryptography at nytimes.com ("Douglas A. Gwyn")
Re: small subgroups in Blum Blum Shub (Secret Squirrel)
Re: Encryption on missing hard-drives ([EMAIL PROTECTED])
Re: Extended Euclidean Algorithm (Anton Stiglic)
Re: Extending LFSR.. (Joaquim Southby)
Re: MD5 Expansion (Arthur Dardia)
Re: Extending LFSR.. (Joaquim Southby)
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Extended Euclidean Algorithm
Date: Mon, 19 Jun 2000 22:19:51 +0200
Simon Johnson wrote:
It would seem very logical that the Extended Euclidean Algorithm
is an *extension* of the euclidean algorithm. What is this
nature of this extention? - No source code please, all in
prose. :)
Also: i'm told it can solve the following problem:
6y + 7x + 14z mod n - where n is known
How do i go about this?
See Knuth, The Art of Computer Programming. Vol. 2.
M. K. Shen
--
Subject: Re: Forgot ZIP File password.
From: Simon Johnson [EMAIL PROTECTED]
Date: Mon, 19 Jun 2000 13:12:14 -0700
Isn't there an attack that requires less than 100 bytes of known
plain-text and has a complexity of about 2^40..
Or is that what that cracking program does?
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
--
From: Rickman [EMAIL PROTECTED]
Crossposted-To: comp.compression
Subject: Re: Small compression/encryption problem
Date: Mon, 19 Jun 2000 16:16:49 -0400
Guy Macon wrote:
Rickman wrote:
What you suggest could do the job well. But I can give you what should
be a simpler approach. Take your input data (uncompressed text string of
any form) and compress it by any of the conventional and redily
available means. PKZIP will do nicely. Generate a bit pattern using a
LFSR or other simple pseudo random number generator. XOR the compressed
data with the bit pattern. This is your compressed, encrypted data. You
may need to group it into 6 bit characters which are mapped to 64
printable ascii characters. I would bet that with a little searching on
the web for the random bit stream generator, you could reduce your
programming effort to almost nothing.
This may not provide NSA level security, but it will be more than useful
enough for your application and you don't need to do a lot of coding.
This looks like a near ideal solution. I wouldn't go for 64 characters
on the basis of making things easy for the typist. I would use 16,
(specifically abcdefghjkprstuv) presented in groups of 4 characters.
That is a good point. It might also be a good idea to add one of the ECC
methods that others have mentioned before encrypting. Since the
characters will be very random, the typist will have problems
transcribing this text and an error correcting code will help with this
problem. One or two wrong characters (or missing or repeated) will still
give you the data you intended.
I am not real busy at the moment. If you are interested, I can work on
this for you. Drop me an email or call if you are interested.
--
Rick Collins
[EMAIL PROTECTED]
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
Internet URL http://www.arius.com
--
Subject: Re: Random sboxes... real info
From: tomstd [EMAIL PROTECTED]
Date: Mon, 19 Jun 2000 13:16:31 -0700
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
The point is Mr BS and Mr Wagner have written posts attacking
my
SCOTT19U as snake OIL and he even bragged I was incapable of
makeing
a safe cipher. They made fun of my cash contest which lasted
much longer
than the BS contest. They gloat how they feel no ameuter can
wrot
Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #11Mon, 7 Feb 00 17:13:01 EST
Contents:
Re: Prior art in science (wtshaw)
Re: Prior art in science (Mok-Kong Shen)
Re: How secure is this method? (Mok-Kong Shen)
Message to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Hill Climbing ("Tony T. Warnock")
Re: Combining LFSR's ("Trevor Jackson, III")
Re: Factorization ("Tony T. Warnock")
Anti-crack (CJ)
Re: Prior art in science (Mok-Kong Shen)
Re: Merkle hash tree patent expired (Anton Stiglic)
Re: Anti-crack (Arthur Dardia)
Re: Need help for security program (Arthur Dardia)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: NIST, AES at RSA conference (Terry Ritter)
Re: Prior art in science (Terry Ritter)
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: Anti-crack ("Kurt Van Nuggat")
Re: Hill Climbing ("Douglas A. Gwyn")
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Prior art in science
Date: Mon, 07 Feb 2000 12:53:47 -0600
In article [EMAIL PROTECTED], Mok-Kong Shen
[EMAIL PROTECTED] wrote:
(That an employee at the patent office may not have the incentive or
energy to perform similar tasks is well understandable.) So in some
sense it appears paradoxically that, while we acquire more knowledge
every day, we know less at the same time.
Those that pretend to be protected from the internet revolution simply
because it is not convenient for them are not to be sheltered.
To classify as published to only journals which you have is some dusty
warehouse, which many do not have, is simply to qualify yourself as inept,
which is the result of the internet revolution aspect in different degrees
to many of us.
Things that might be getting ahead of us are best attacked with methods
from the same technology, search engines, whose capabilities become by
definition those of their users.
--
Life is full of upturns and downturns, with varying periods of
stabilty mixed in. It is a fool's errand to assume that what is
happening any one day predicts the same as a constant future.
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Prior art in science
Date: Mon, 07 Feb 2000 21:12:25 +0100
Paul Koning wrote:
Mok-Kong Shen wrote:
The issue of 'prior art' is not only relevant in patent applications
but also of interest by itself in general in science, I suppose.
Recently in a thread it has been pointed out that what has been
published in newsgroups and similar forums possibly may not
qualify as 'prior art' because of limited possibilities of being
found in searches.
That's nonsense.
First of all, of course you can find it in searches. But
whether or not it's easy to find doesn't change whether it
is "prior art".
Perhaps the cited opinion (not mine!) could nevertheless be
defended somewhat. If some information is very troublesome to be
retrieved, then it will normally not be found, either because the
searcher becomes impatient or because his resources (time, etc.)
are exhausted. It is known, for example, that decades ago lots of
Russian scientific results were barely known to western scientists
because either the journals concerned were simply not subscribed
by the libraries or that the scientists couldn't read them. Nowadays
the situation has changed to such an extent that one friend of mine
once remarked that there have been much too much translations of
Russian journals (meaning that even the second-classed ones get
translated into English).
The patent office may not spot it, of course; these days,
almost anything seems to be accepted as a valid patent application,
in spite of the "non-obvious and novel" requirement. :-(
In Germany the situation is a little bit better. There is a
public review period for all patent applications. However, only
large firms that can afford to maintain special patent departments
regularly keep an eye on the patent office bulletins that solicitate
public reviews and the public itself is unfortunately generally very
much less attentive of materials contained in such publications.
M. K. Shen
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: How secure is this method?
Date: Mon, 07 Feb 2000 21:12:33 +0100
Sandy Harris wrote:
[EMAIL PROTECTED] (Erik) spake thus:
and is the linear congruence algorithm sufficient for this purpose?
Absolutely not, even if you combine outputs from several of them.
I have incidently published on my web page a couple of years ago
a compound PRNG scheme with a (special case) implementation that
employed exclusively LPRNGs as constituent generators. If someone
has 'concrete' (as against theoretically postulated) ideas of how
to effective
Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #10 Tue, 17 Aug 99 14:13:02 EDT
Contents:
Re: Blowfish algorithm - Is it full proof? (Helger Lipmaa)
Re: E2 (John Savard)
Re: How good is this quadratic sieve variation? (Mok-Kong Shen)
Re: NIST AES FInalists are (John Savard)
Re: Wrapped PCBC mode (Tom St Denis)
Re: Wrapped PCBC mode (Tom St Denis)
Re: CRYPTO DESIGN MY VIEW ("Douglas A. Gwyn")
Entropy in "modified" passwords (Nick Battle)
CRYPTO DESIGN MY VIEW (John)
compress then encrypt? (John)
Re: Kana, was occurrence of letters in english (Patrick Juola)
Re: Entropy in "modified" passwords (Mok-Kong Shen)
Back doors(was: AES Finalists) (fungus)
Re: CRYPTO DESIGN MY VIEW (Patrick Juola)
Re: Academic vs Industrial (John Savard)
Re: crypto survey (Medical Electronics Lab)
Re: Please help a HS student with an independent study in crypto (Barry Herman)
Re: Cracking the Scott cryptosystems?
Re: Kana, was occurrence of letters in english (John Savard)
From: Helger Lipmaa [EMAIL PROTECTED]
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Tue, 17 Aug 1999 14:29:52 +
David A Molnar wrote:
What if we're not aiming at the target plaintext 67890, but just want
*any* other plaintext than 12345 ? I agree that being able to pick the
resulting plaintext would be a huge weakness! Except it's not at all clear
to me why flipping bits in Blowfish (with the key staying the same)
wouldn't produce a valid ciphertext which decrypts to some garbage
plaintext...although the adversary wouldn't know which one.
Then pick *any* other ciphertext than A? :) It's a bijective business... Every
ciphertext decrypts to some (however you would define that) "garbage" plaintext.
You cannot get things like plaintext awareness without randomness and thus
increasing the output length. On the other hand non-malleability is always
tacitly assumed from the block ciphers (although in the block cipher world the
word NM is almost never used, it's a too trivial requirement).
Helger
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: E2
Date: Tue, 17 Aug 1999 15:29:33 GMT
[EMAIL PROTECTED] wrote, in part:
Is anyone else disappointed that E2 was not chosen as an AES finalist?
It probably just barely missed out, since many people found it to be
one of the better designs.
RC6 and MARS were also classic Feistel designs which used
multiplication to provide nonlinearity and rapid diffusion in one
step, like E2.
The other three finalists are significantly different, and Twofish in
particular had one of the most comprehensive analyses of any
submission, and was designed to be suitable for a wide variety of
platforms.
Thus, if E2 had been accepted, one of RC6 or MARS would need to be
thrown out. (Similarly, if CAST-128 had been accepted, one of Serpent
or Rijndael would have needed to be thrown out.)
Both of those designs come from sources with very good reputations.
RC6 is interesting because of its extreme speed and simplicity, and
MARS has a complicated design, but perhaps that is what is needed for
security.
So E2, I think, got squeezed out not because there was anything wrong
with it, but because it just wasn't as exciting as the others.
John Savard ( teneerf- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: How good is this quadratic sieve variation?
Date: Tue, 17 Aug 1999 17:51:02 +0200
Bob Silverman wrote:
The basic problem is that one hopes that values of Q(x) are smooth
over an interval (say) [-M,M]. The best one can hope for is that
these values are going to be equal to about M sqrt(N)/sqrt(8) for
well chosen polynomials Q(x).
For f(x) = x^2 mod N, is there any empirical estimate (rough values
based on actual runs) of the probability of having f(x) smooth
for x, say, in [h, 2h] (h = sqrt(N)) ?
M. K. Shen
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are
Date: Tue, 17 Aug 1999 15:16:52 GMT
"Douglas A. Gwyn" [EMAIL PROTECTED] wrote, in part:
That hardly qualifies as a "back door", because the opponent doesn't
have the ability to alter the innards of your encryptor/decryptor.
No, it isn't the same thing at all, I admit.
It does qualify as an attack, though, if the opponent manages to limit
the key size of my encryptor/decryptor by ensuring that if I alter its
innards to make the key bigger, its security collapses.
While I agree that it's unlikely - verging on preposterous - that the
NSA is going to (or rather, has already) put a real backdoor into the
winning AES candidate, I merely seek to focus consideration on the
real and possible ways that their superior knowledge of these matters
could be put to u
Cryptography-Digest Digest #65
Cryptography-Digest Digest #65, Volume #9Wed, 10 Feb 99 14:13:04 EST
Contents:
Re: Intel's description of the Pentium III serial number (Terje Mathisen)
Re: Clarification on PGP. pls (Michael Kjorling)
Re: RNG Product Feature Poll (wtshaw)
Re: RNG Product Feature Poll (Herman Rubin)
Re: Clarification on PGP. pls (Ríkharður Egilsson)
Re: Java random ("Else")
Re: block ciphers (wtshaw)
Re: Two simple questions about RSA (Paul Rubin)
Re: Clarification on PGP. pls (Jim Felling)
Re: What is left to invent? ("Trevor Jackson, III")
Re: RNG Product Feature Poll ("Trevor Jackson, III")
Re: Who will win in AES contest ?? (Hironobu Suzuki)
From: Terje Mathisen [EMAIL PROTECTED]
Crossposted-To: comp.sys.intel
Subject: Re: Intel's description of the Pentium III serial number
Date: Wed, 10 Feb 1999 15:53:52 +0100
John F Carr wrote:
In article [EMAIL PROTECTED],
Terje Mathisen [EMAIL PROTECTED] wrote:
CPUID is a user-mode instruction, as well as the documented way to
serialize the cpu instruction stream from user code.
I.e. there's no way Intel could make this a ring 0 opcode.
They could make CPUID privileged when eax=read serial, or make it
return a different value (e.g. 0|0|0 or "I Don't Know") in user mode.
OK, that is theoretically possible. IMHO, it is however very unlikely,
because it would force Intel to either
a) modify the instruction decoder, which would be almost impossible
since the OOO cpu core means that the decoader don't know what a given
register will contain
or
b) (much more feasible) add an extra decision point in the cpuid
hw/microcode to test the eax value, and branch to different versions
depending upon the result.
Assuming CPUID actually is microcoded, this would in fact be possible,
and using the loadable microcode feature, Intel might be able to do
this, but only by having the needed microcode loaded into the cpu during
POST, which would require new bios code.
(This would be hard to do since all the large vendors have lots of
PIII's in the production pipeline by now.)
I don't know if the loadable microcode, which was added around the time
of the FDIV fiasco, allows modifications to user-mode instructions.
OTOH, since we already know that CPUID(GetSerialNumber) obeys a 'sticky'
disable bit in one of the Model Specific Registers (MSRs), there's
probably a quite complicated set of microcode involved already.
On the gripping hand however, what would Intel gain by making this a
kernel mode instruction? This would only weaken whatever security
(authentication) they intend to use this serial number for! I.e. by
allowing the kind of sw traps/replays/faking as the original post
referred to.
Terje
--
- [EMAIL PROTECTED]
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
--
From: [EMAIL PROTECTED] (Michael Kjorling)
Subject: Re: Clarification on PGP. pls
Date: Wed, 10 Feb 1999 15:29:06 GMT
Reply-To: [EMAIL PROTECTED]
=BEGIN PGP SIGNED MESSAGE=
Hash: SHA1
I bet you're thinking of trial divisions or something:)
The problem is not the algorithm, it is the time required to execute the
algorithm with cryptographically good input. Try to factor (2^256-3)/2, it'll
take a while, but it isn't impossible (I've got the factors many lines down if
you want them...)
For those who's interested, the number I want you to factor is:
57896044618658097711785492504343953926634992332820282019728792003956564819966
(My apologizes if this extends to the outer parts of your screen, but the
number is that long!)
//Michael
On Wed, 10 Feb 1999 01:33:52 -1000, "Wm. Toldt" [EMAIL PROTECTED] wrote:
There is a way to factor large primes which I am willing to divulge to
you. Once you see how it is done, you will wonder why you did not think
of it by yourself. If you want the secret, just ask for it here.
PRIME FACTORS FOR (2^256-3)/2:
2, 3, 56713727820156410577229101238628035243,
170141183460469231731687303715884105727
Factorization required about 7000 MIPS-hours on my Pentium II 350/NT4
Workstation at High priority and no concurrently running processes using
MIRACL-based software
=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/AwUBNsGXmSqje/2KcOM+EQIfAwCcDJ++jdW+O50/3eJfVv6olmwqNjoAoMzi
gtcrWQb0b2S0LMjt0QN/ZZTT
=DyBZ
=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 E
