Cryptography-Digest Digest #1, Volume #9 Fri, 29 Jan 99 18:13:05 EST
Contents:
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
Re: Smaller RC6 (DJohn37050)
Re: Metaphysics Of Randomness ("John Feth")
Re: Public Key encryption (DJohn37050)
Re: Foiling 56-bit export limitations: example with 70-bit DES
([EMAIL PROTECTED])
SSL Question ("John")
Re: My comments on Intel's Processor ID Number (chris)
some brief questions ("Spiffy")
Re: Who will win in AES contest ?? (David Hamilton)
FIALKA description added (John Savard)
Re: Some more technical info on Pentium III serial number (Terje Mathisen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Fri, 29 Jan 1999 19:49:05 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
> In article <78sh1l$hhh$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
wrote:
>
> >
> > DES is not a random cipher over more than 64-bits (one block).
> But, it does not dictate what you can do to the data before you give it a
> block of bits to deal with. There are many ways to deliver a block of
> bits that are already transformed from recognizable text, so you would
> have to solve enough blocks for the solution of what came before, which
> could be many, many blocks.
>
I think we are in agreement even though we are calling different cards ;-)
When I have cipher C (say, DES) and calculate C's unicity -- what is it? Is
it the unicity of an unknown encipherment B *before* C? No, it is the unicity
of C. So, it is the least amount of plaintext needed to break C -- which
means that I am able use the unicity's amount of plaintext that was inputted
into C in order to find the key used in C to produce **that** ciphertext.
**NOTE: Of course, once you find that key, then the whole set of anything
******* encrypted with that key and C is open to you.
Now, if **that** plaintext (that was inputted into C) is actually a ciphertext
from another cipher B (which is what I understand you are saying), then that
still does not change the unicity of C -- which is what I am saying.
OK?
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Smaller RC6
Date: 29 Jan 1999 20:38:29 GMT
I may be misunderstanding something but a 32-bit blockcipher is open to text
attacks after about 2**16 blocks have been encrypted. This is less than 1M.
Don Johnson
------------------------------
From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: 29 Jan 1999 20:36:26 GMT
Bob, my comments are interspersed below.
R. Knauer <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> It just occured to me after finishing Chaitin's new book, "The
> Unknowable", that perhaps one reason people insist on using
> statistical tests to characterize numbers as random - which we know is
> incorrect for purposes of crypto - is that one can presumably
> characterize certain numbers by such means, but only if they are
> infinite in length.
Crimenently Bob, we characterize number strings with statistical tests
because we poor mortals can't wait for the whole string and don't want to
take it on faith that the little partial strings we get are randomly
sequenced.
> One might be tempted to say that if a very large number is
> characterized as random by statistical methods, then it is "almost"
> perfectly random. But as I understand it, that is a error in
> judgement. If the numbers you are using are finite, then the only way
> you can decide if they are random for purposes of cryto is to
> characterize the generator that produced them.
>
> The generator tells you how an infinite number could be produced by
> it, and from that you can infer that finite numbers produced by it are
> crypto-grade random numbers, assuming it is a TRNG. IOW, although you
> cannot actually characterize an infinite number produced by a
> generator, but you can characterize finite numbers produced by it from
> inspection of the generation procedure itself.
Yikes Bob! You mean children can be characterized by inspecting the
parent's plumbing? Think about it, finite number of humans, finite number
of finger prints, finite number of personalities, finite number of
words...maybe you're on to something!
> That is, you can extrapolate your knowledge of the generation
> procedure to infinite number generation, and from that infer the
> randomness of finite numbers produced by that procedure. But you
> cannot take a large number and use it to extrapolate to infinite
> number generation. The reason for that is simple.
>
> If the finite number you are trying to characterize by statistical
> tests is presumably random, then its generation is indeterminate, and
> therefore there is no procedure to extrapolate its characteristics to
> infinite number generation. It could very well be random but there is
> no way you can decide that from statistical tests on the number
> itself. If the number is indeed random, it will not yield any
> information about how it was genrerated, and therefore extrapolation
> to infinite number generation - where statistical tests DO apply - is
> not possible.
Watch out Bob, this zany premise is about to go over the edge. Remember
the old adage, "Interpolate to your heart's content, extrapolate at you
peril"? Statistics are not predictive, they are retrospective and
appropriate only for a (finite) data set.
> Here is the reductio ad absurdum: If you claim that a statistical test
> can extrapolate alleged random characteristics from a finite number to
> infinite number generation, then there must be a procedure to do that,
> in which case the extrapolation is deterministic - and therefore the
> infinite number generation procedure you just used is not random, and
> you cannot use it to characterize the original number as random.
>
> A number is random because it tells you nothing about itself,
> including the fact that it is random. If a number can tell you that it
> is random, then it is not random. It's like the Epimenides Paradox:
>
> "All (finite) random numbers are liars." :-)
Golly Bob, you'll be even happier if you look at numbers as strings of
digits. Then you'll find that the longer the string the more you know
about the randomness of the sequence, and you can test any old finite
string to see if it is lying to you.
> Bob Knauer
Regards,
John Feth
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Public Key encryption
Date: 29 Jan 1999 20:52:34 GMT
The IEEE P1363 draft standard has a lot of good info.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Fri, 29 Jan 1999 20:36:28 GMT
In article <78ss2c$s4b$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <78qtll$6p4$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> [snip]
> > It is possible that you have mistyped before, as I understood you were
> > proposing to use the stream cipher on the *plaintext* -- please read what
you
> > wrote:
>
> Actually, I read the paper between making my two posts. My first post was
> incorrect in suggesting that you pre-encrypt, instead of post-encrypting.
OK, at least now we synch'ed texts! ;-)
> Have you considered doing both (i.e., Ci = rndblock_X XOR DES(Pi XOR
> rndblock_X), where rndblock_X is the block you chose out of 2^M blocks)?
>
Yes, but it is worse.
> [snip]
> > Further, it is of course clear that XORing the ciphertext is ONE alternative
> > -- the method just calls for encrypting each DES ciphertext block.
>
> O.K., then the only reasons to use an
"already published " can also be algorithmically "published" in the M-DES
software itself -- for example, as simple as:
UK = rand(2^M); //where rand(2^M) returns a random value between 1 and 2^M
// Unknown-Key = UK
> M-bit algorithm for
> the post-encryption step, instead of using 2^M published "random" blocks, are
> a) you can avoid having to create and disseminate the table of 2^M blocks,
...and the errors that might result from some (say) mistyping. You could
exhaust *all* 2^M values and still find nothing because the other guy used a
wrong key not in the set of 2^M you are using. There are 2^50 possibly wholly
different sets of 2^14 keys in the 2^64 space -- and, of course, (2^14 - 1)
different errors may result if you consider the error caused by just *one*
different bit in the 2^M key set chosen.
> and b) it never hurts to use the stronger of the two choices.
There is no "stronger" or weaker -- because **any** set with unknown 2^M
elements (with no reptition) has an entropy of M = log2(2^M). Thus, it just
must not have repetitions or you fall back to a lesser M.
***This is an important issue -- and, *one* of the reasons why just simple XOR
encoding is enough for the method.
I would also add a c):
c) the 2^M blocks can be keyed by a third-key in the range 2^50 -- which must
be secret and trusted by Bob and Alice. This is not WA-compliant but yields
120-bit security.
>
> This brings up another question. You have the underlying assumption that any
> 56-bit algorithm is automatically exportable. From the U.S., this is not true
> (I don't know about other Wassenaar countries).
Interesting subquestion.
To the question itself, no. My assumptions were not what you say. I assumed:
(i) DES is automatically exportable from the US and, (ii) DES is a 56-bit
cipher. Both are true.
Now, the interesting subquestion. Note that the M-DES method works with DES
-- but may not work with another 56-bit cipher, even if the cipher is as
secure as DES. The reason is given in http://www.mcg.org.br/nrdes.htm -- DES
has what I called a "hash-function property" (which is bad for its security
as discussed in the text and is due to the dimensional reduction of 64:56)
but which provides the "right" wrong decipherment properties needed to make
Alice's search viable with a low discovery-time. In other words, DES "hints"
the search for Alice -- this is *essential* to afford high Ms.
>
> [snip]
> > >and may be less secure than
> > > post-encrypting with a good M-bit block cipher.
> >
> > No, it is not less secure. See above.
>
> Actually, if they have a known cipher-text block,
This assumption is only granted if "they" have broken the whole 70-bit key --
not otherwise. In other words, what you mention is not possible **if** the
*whole* 70-bit key is not broken -- thus, it cannot be used to break any bit
of that key. That is why I said before (above): "No, it is not less secure."
> > > All three approaches,
> > > however, have the weakness that you must include a known plaintext block
(or
> > > send only English text, or printable data), if you want to be sure that
> Alice
> > > can successfully brute-force Bob's post-encryption step.
> >
> > Not the scheme I explained in the paper -- but see also [Note-2] in the
> > paper. If you send only random data then the effective key-length is already
> > 120-bits, the cipher is even theoretically secure against brute-force
> > attacks, and you may set M = 0. However, if you send private-keys, then even
> > though they are pretty random you can't set M = 0. This is all in [Note-2]
in
> > the paper -- the address is http://www.mcg.org.br/unicity.htm -- perhaps
you
> > read the old .txt version? That would explain some of the discrepancies.
>
> So, you modify the protocol to inform Alice what M you used, and she can
> infer from that what the unicity is for her brute-force on the M-bit
> post-encryption?
No, the protocol is not modified -- Bob has to inform Alice (in plain) what M
he is using. One particular case is M = 0. Thus, when Bob negotiates a cipher
with Alice, he sends (suppose):
M_DES_M0 --> which means M-DES with M=0
or
M_DES_M14 --> M-DES with M=14
OK?
>
> [snip]
> > Because you can't get more random than random. The ciphertext has entropy 8
> > bit/byte as a function of the plaintext, for a fixed 56-bit key.
>
> So, you are assuming that the attacker never has a known-cipherttext block
> (i.e., that the attacker can never know what the value of one of the DES
> ciphertexts was before you post-encrypted it)?
Yes -- that information never leaves Bob's machine unless XOR-encrypted with
the M-bit key he has chosen. Note that the known-ciphertext is now:
(M-bit key) XOR DES(Key,Message)
and NOT just DES(Key,Message).
This is a rather funny reverse use of XOR, because the key is fixed and
the plaintext (here, DES(Key,Message)) is random ;-)
Cheers,
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "John" <[EMAIL PROTECTED]>
Subject: SSL Question
Date: Fri, 29 Jan 1999 18:34:12 +0100
Hi,
Sorry for this question that may sound stupid,but I am new in the
domain.
I am using SSLeay 0.9 to generate an API connecting by SSL to any htttpd
server. The question I was asking is what the minimum or the maximum
of the key used for encryption ? (128 bits?) Can I change it when I
compile the SSLeay pkg ?
BTW, has any one developed such a simple client (using C) ?
I would like to get it since docs are not very updates in the
SSLeay pkg.
Thanks for helping;
John
------------------------------
From: [EMAIL PROTECTED] (chris)
Subject: Re: My comments on Intel's Processor ID Number
Date: Fri, 29 Jan 1999 21:26:51 GMT
On 28 Jan 1999 13:48:47 GMT, "jay" <[EMAIL PROTECTED]> wrote:
>
>chris <[EMAIL PROTECTED]> wrote in article
><[EMAIL PROTECTED]>...
>>
>>
>> i can't see why people worry about this stealing their privacy
>> while they are perfectly happy giving out phone #s and VISA #s on the
>> LL Bean or Amazon websites.
>>
>You are assuming that the *same* people that are freely giving out their CC
>are the people most concerned about ID. This is probably not true.
>
perhaps not.
>Additionally, you consciously give a CC out to specific sites that you
>choose. At other registration sites, people are only known by their name
>and password. The externally accessible nature of the PIII would allow
>widespread cross-compilation of user data between unrelated sites, without
>user consent. This is serious.
i don't think it's any more serious than CC, email address ,
physical address, SSN, telephone #, name, and driver's license #
compilation. if the compilation one more number leads to anything at
all, it will be to more annoying sales pitches.
people are not going to have their PIII ID# tattooed on their
foreheads any more than they'll have their car's vehicle ID number
tattooed on their backs. the ID only IDs a chip in a box.
------------------------------
From: "Spiffy" <[EMAIL PROTECTED]>
Subject: some brief questions
Date: Fri, 29 Jan 1999 14:31:19 -0800
Hi
I'm a high school student and I'm doing encryption for my senior project. I
have a few questions about things I've read/heard. I'm currently reading
Schneier's Applied Cryptography, ed 2 and ed 1 (One is from the library, one
is from my comp sci teacher; ed 1 has some source code from some programs
that ed2 doesn't have). I jumped around and haven't really gotten too far in
reading the book. If an answer is in there, please refer me to the page #,
or the fact that it's in there.
* What are all those "unsigned long 0x4b7a70e7" in blowfish's source code in
Schneier's Applied Cryptography ed. 2 and in DES in the first edition? (the
last 8 characters are random, i just took the first one i saw) I took the
first year of C++ so i understand some of the code.
* Does anybody know how to manipulate bits in C or can refer me to a
website? I'm planning to write a simple encryption program for my project.
* In Applied Cryptography, he said that truly random numbers are
incompressible. Does it follow that incompressible data is random? Example:
"if P, then Q." Are "If Q, then P," and "If not P, then not Q" true in the
case of this randomness and compressibility? If so, does that mean I can zip
up an mp3 file and say that the data is random? In general, is ciphertext
random? Just wondering.
* If computers know they cracked a code by getting ASCII letters, then can't
I zip it and then encrypt it so they don't see any letters?
* Is it really that hard to get "good" random numbers? What's wrong with the
static from the TV (channel 3 for example) or the radio?
* The export laws on strong encryption don't make sense. What's stopping
somebody from bringing a hard copy of the source code to another country?
Seems like one of those dumb laws that make politicians look good and that
are unenforceable.
* Is PGP shareware or freeware or neither? If it is one of the previous, is
it worth downloading even though I probably wouldn't really use it. Btw, is
the source code available?
* What are the math/computer courses do you have to take to fully understand
the posts here and most of the algorithms?
* Today, how long would it take to crack enigma (the WW2 German encryption
machine) on a Pentium 2 400 with hardware written esp. for cracking it (you
know the algorithm and that it is encrypted in it). I heard that enigma has
10^(big number) of combinations so I don't see why it's weaker than any
contemporary encryption algorithm. Wouldn't adding another rotor make it a
lot more strong?
Thanks for the help!
--David
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Who will win in AES contest ??
Date: Fri, 29 Jan 1999 22:31:47 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (David Hamilton) wrote:
>> (snip)
>Earlier in this thread, you said:
>> Don't use David A. Scott's software. There is evidence that it is almost
>> certainly weaker than, eg, PGP. See message-ID:
>> <[EMAIL PROTECTED]> in the thread 'Re: Encryption Basics'
>> posted in sci.crypt on 19th December for details.
>> David Hamilton. Only I give the right to read what I write and PGP allows
>> me
> I should know better than to anwser your posts since you are a sick
>man.
Isn't there a particular type of person/organisation/political system that
regards people who ask questions as sick? You continue to use insults in the
desperate hope that people won't notice your refusal to answer questions such
as:
1) You did say you would break IDEA didn't you?
2) Have you broken IDEA yet?
3) You did say that the AES winner will be one of the entries that the USA
NSA has entered didn't you?
4) Which were the USA NSA AES entries?
> But since you claimed to have proof I tried to look up using
>Deja News the article you quoted. At least when I click on the blue
>part it goes to an error message.
Go to http://www.dejanews.com/. Near the top left hand side you will see the
word 'Find' on an orange background. Paste into the area underneath that the
message id quoted above. Click on the find button and you will get several
messages returned because I have quoted the above message id in a number of
postings. However, I will now show that entire posting here with headings.
*****************************************************************************
*****************************************************************************
START OF <[EMAIL PROTECTED]> FROM SCI.CRYPT ON 19TH DECEMBER
Xref: news.demon.co.uk sci.crypt:18542
Path: news.demon.co.uk!demon!davidham.demon.co.uk!not-for-mail
From: [EMAIL PROTECTED] (David Hamilton)
Newsgroups: sci.crypt
Subject: Re: Encryption Basics
Date: Sat, 19 Dec 1998 13:54:52 GMT
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <75et38$tsi$[EMAIL PROTECTED]
com>
NNTP-Posting-Host: davidham.demon.co.uk
X-NNTP-Posting-Host: davidham.demon.co.uk:158.152.167.6
X-Trace: news.demon.co.uk 914075593 nnrp-07:3616 NO-IDENT davidham.demon.co.
uk:158.152.167.6
X-Complaints-To: [EMAIL PROTECTED]
X-Newsreader: Forte Free Agent 1.1/32.230
Lines: 108
- -----BEGIN PGP SIGNED MESSAGE-----
[EMAIL PROTECTED] wrote:
Initiate auto-response program. (Why didn't I think of this before?)
> Do to the fact the government wants to restrict encryption and
>the socalled experts in the US are in bed with the NSA that wants
>the ability to read anything you encrypt. You are going to have
>a very hard time.
David A. Scott believes that everyone who disagrees with him is in bed with
the USA NSA. (It would need to be a very big bed.)
> You will not get good encryption. The information
>is not there. You have to either learn yourself. Or get fooled by
>some shark that writtes well.
Don't get fooled by David A. Scott. Use PGP. Or take a look at Scramdisk. The
choice depends on needs. (There are other products of course.)
> I would suggest try scott16u.zip
I wouldn't. It is extremely likely that David A. Scott's software is much
weaker than, eg, PGP. For example, his native language (English) is poor and
this may be a programming risk. In addition, David A. Scott designed all the
algorithms and code used in his software and, with one exception, he can't
remember the names of people who 'commented' on it.
On the other hand, Phil Zimmermann (author of PGP) says about PGP's
algorithms:
'The three symmetric block ciphers offered by PGP are CAST, Triple-DES,
and IDEA. They are not home-grown algorithms. They were all developed by
teams of cryptographers with distinguished reputations.' And 'It (IDEA) was
developed at ETH in Zurich by James L. Massey and Xuejia Lai, and published
in 1990.'
In addition, with PGP, there are newsgroups and mailing lists that can help
with queries. There aren't any such things for David A. Scott's software.
People need to be wary of David A. Scott's claims. For example, in the past,
he said that he would crack IDEA ... but then he said he had a disk crash and
lost his work (because, he said, he hadn't backed-up his disk). This might be
regarded as a shoddy way of working. Another way to get an impression of
David A. Scott's software and his attitudes is to see the threads 'Re: David
A. Scott and his cryptographic software (Was Re: image encryption)' and 'An
Initial Cryptoanalysis of SCOTT16U' both started in sci.crypt in June 1998 -
more than 70 postings between them. I don't think people's impressions would
be favourable.
Another of David A. Scott's claims, in the context of a dictionary attack,
was that he had seen a dictionary attack work on a system where the attacker
never guessed the correct passphrase but just stumbled on one that hashed to
the same value. He subsequently declined to give any information about the
passphrase, the hashing algorithm, the dictionary size or the method of word
selection. David A. Scott also declined to give the odds of stumbling on a
passphrase that hashed to the same value. His reason for declining to give
this information was that the person referred to 'still works for the federal
government'.
People need also to beware of David A. Scott's assertions because that's
exactly what they are ... and only what they are. Evidence isn't supplied.
Finally, David A Scott is always insulting others. Although this doesn't
affect his (lack of) cryptography abilities, it does mean that most people
would rather eat dirt than help him. To give the gist, here are some of the
comments he has made in sci.crypt in recent responses to me:
(a) Not only am i rude but also crude so fucking what that is the way I
am. I also don't spell worth a shit but big fucking deal everyone has
crosses to bear or are you perfect. I mean I think you kind of an ass
like me but I bet you see your self in a higher light.
(b) I answer as I see them. And so do you. SO don't tell me how to fucking
write.
(c) You really are a pompous ass aren't you.
(d) Or maybe you don't strike me as much of an asshole as in other replys
(e) As to your last stupid question did I design it. Yes and its
algoritms.
(f) how the FUCK do you know. (I hope this makes up for lack or rudness
which you waved in my face from an earlier post).
(g) Is that os FUCKING HARD or are you just all talk.
(h) So fuck you and let the people try it.
(i) Well asshole.
David A. Scott has similarly insulted others.
So, when deciding on cryptography software to protect privacy, I recommend
that David A. Scott's software should not be on anyone's shortlist.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
- -----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNnuuXMo1RmX6QSF5AQHoAAgAnyuDwPpU9/5gjjP5HqzgsZs6b69uTUnR
2G376ccwAFrXoyfLwCA0ejBUcREyyDL4IuIjyJFIv+aSd0FtunK9FRnXfn1+qf4H
+Cg1uIzuIaZ4VRUYjac6eqmQ9btnRR9LB0QTonKoBSrwXcU3Wp0FeLq6a1ZjDxXp
6fyyM08+JTRNC4r4lYMnkoi00dTobAbKuLnYgaeCKjVei8XLAp5ePwRldT8yOTsZ
1rlNHWuZWzoQrVw5Zx9drxTWb4KER/uKQ9DeE42b8UDzLXQxFMyJvbHEpCKhlqpQ
tPYBw1VSEPMzwecOlvOKAeaG0NhyIk3FMCSwKBXmIebbUDCfGLQYuw==
=boyl
- -----END PGP SIGNATURE-----
END OF <[EMAIL PROTECTED]> FROM SCI.CRYPT ON 19TH DECEMBER
*****************************************************************************
*****************************************************************************
> Oh well so much for your so called
>proof.
See above for how to use Dejanews.
(snip)
>These concepts are to hard for Mr Hamilton let him
>stick to the "zero entropy" methods the fool has no understanding
>of this basic concept.
See above for insults and your refusal to answer questions.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNrIwMso1RmX6QSF5AQF3yAf+PNhHkDx91Y6A5E/PzPLjM5oxWQWFq2gh
hAs9rcQcbYOI/45rqR03tJP/FhGH58taHzftodmKgVcAdGXYQs3Pliynf/6nLQmA
5gJVteRJODR7StAB1kLZyzIvSqBGVeAg93KrRJFRfAi/OVeeXWHv1HC8+/9BcEfq
LA7Ag9E33lUicMk1fhGZhpVUG7fLwQ+gnSPbG9XdawF0vIbKLdAIkPz/DIoX+K6b
9N3LwU4wuPzxwckYHAlPBvR1nbXCCDL6lrcs3O7iou8DIof2mFjP4L36Zh05TENj
q0qDz6f+aI+WYtYPr07IYfIz3x8g6EMQWco6NIFATEVt+GK+wx4Ekw==
=FxgP
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: FIALKA description added
Date: Fri, 29 Jan 1999 22:31:01 GMT
Recently, there were a couple of posts to this newsgroup by one Joerg
Drobick, asking if anyone had information about cipher machines used
in the former East Germany.
I took a peek at his web site, and am very happy I did. At first, I
had trouble finding anything out, but he added some more diagrams, and
I was finally able to understand something about three of the cipher
machines described, particularly the M125 cipher machine (Fialka)
which was described in the most detail.
I have now included a description of this machine, based on his work,
in the section of my web page devoted to miscellaneous cipher machines
based on the Enigma, at
http://members.xoom.com/quadibloc/ro020404.htm
There is also a link to Joerg Drobick's web page there, of course.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Some more technical info on Pentium III serial number
Date: Fri, 29 Jan 1999 23:47:36 +0100
John Savard wrote:
[snip]
> But an undocumented instruction would, at least, prevent a trivial
> direct attack with an emulator - and do so dependably in all machines
> in which the chip was used, even if they weren't PC-compatible. Also,
> as Intel _is_ the chip designer, they could have included a special
> instruction specifically suited to this kind of purpose.
Not really: To be decodable (by the instruction fetch hardware), the
instruction cannot be really long/complicated.
It would always be possible to design your emulator in such a way that
if it comes upon an unknown (i.e. invalid to the emulator) opcode, it
should just stop and tell about it.
At this point you would transfer the emulator state to the actual
hardware, let it single-step through the next instruction(s), until you
get to a point where you can determine that the following code is
OK/known.
It would be possible to do this without leaving any gap for the cpu to
detect that it is being under attack.
If you want a paranoid cpu, you would have to have a realtime clock
(independent of the input clock) embedded in the cpu, and then combine
this with sequences of more-or-less undocumented opcodes.
Even this might not be enough to detect all attacks.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
** 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
******************************
