Cryptography-Digest Digest #956, Volume #8 Sat, 23 Jan 99 19:13:04 EST
Contents:
Re: Pentium III... ([EMAIL PROTECTED])
Re: Please help. Need protocol advice. ([EMAIL PROTECTED])
Re: Is speed of public-key algorithms important? (George Barwood)
Re: Can anyone offer opinions on TEA, XTEA? (Mr. Tines)
Re: Edupage coverage of Flannery story (Derek Bell)
Re: Who will win in AES contest ?? (Derek Bell)
Re: simple symetric encrypt <-> decrypt (John Bailey)
Re: Who will win in AES contest ?? (David Crick)
Re: Please help. Need protocol advice. ([EMAIL PROTECTED])
Re: Pentium III... (R. Knauer)
Algorithms & Attacks: Supplementing Bruce's Course... (JPeschel)
Re: Metaphysics Of Randomness (R. Knauer)
Re: Cayley
Re: Pentium III...
Why does the GOP hate encryption? [no PGP content] (Anonymous)
Re: Please help. Need protocol advice. ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium III...
Date: Sat, 23 Jan 1999 20:08:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Ritter) wrote:
> and I dispute the idea that this is particularly "random." What it is
> is "complex," but this is the complexity of digital logic state
> machines whose structure is known.
If the clock skew were the ONLY factor, this might not be such a good choice.
I used the title of clock skew because people would recognize the
implementation strategy. There are MANY other activities affecting the code
path between each sample. For example, I/O activity causes the processor to
execute code, and also may access memory via DMA, causing memory access wait
state variations. If you have methods to predict the time, within 3
nanoseconds, of every network packet flowing into a device, there are some
folks from Cisco who would want to talk to you. As far as I know, the instant
in time that someone in the world clicks a link on a web page, is a random
event. These events will influence the code path of the sample time on a web
server, causing true randomness. For any computer that has a UI, every
keystroke or mouse moment causes code path variations, triggered by true
random events.
The software generator I mentioned also had three algorithms, to deal with the
potential that one (or even two) had a weakness. Stirring a less random soure
together with a more random source gives the more random result. Do you also
believe disk seeks are highly predicatble?
Your also suggesting you can take the output from a cryptographic hash
(assuming we hash the data from the original source generator), and exactly
predict the patterns of the input, to analyze the patterns originally
generated. I've heard of some success in generating MD5 hashes with specific
output bits at specific values, but haven't heard of a total breakdown in the
integrity of either MD5 or SHA-1. Are you suggesting cryptographic hashes are
reversable? That gives a hash, you can calculate the number and value of input
bits?
I agree that if you put a system in a lab under very controlled conditions,
you may be able to predict or influence things better. The software I worked
on and I believe software running on most peoples systems will not be under
these conditions.
The topic of this thread is about the usefulness of a hardware random number
generator in a Pentium III. My belief is anybody who is serious about
security, will want some external hardware device anyway. So doing security
on a PC without extra hardware only applies for 'low' security uses. I
believe software generated random numbers are very sufficent for this.
Really, I'd love to see some hardware support for security in PC's. I just
don't think Intel's latest features improve things much. I don't believe the
weakest link is in the quality of random number generators. I think a socket
on motherboards for an iButton would be a lot better (and cost very little).
For lowest security uses, just a serial number button with costs a buck. If
users wanted better security, a crypto iButton could be popped in for a dozen
or two bucks. Of course this would work just as well for Intel, AMD, and
Cyrix processors, which may not be Intel's goal.
- Jan
P.S. I really have no connection with Dallas Semi. I just like iButtons more
and more when I think about the problems that need solving.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Please help. Need protocol advice.
Date: Sat, 23 Jan 1999 20:06:16 GMT
In article <78c9ku$nau$[EMAIL PROTECTED]>,
"Else" <[EMAIL PROTECTED]> wrote:
> Here is how I solved very similar problem:
>
.
.
.
> 3. Every client fetches the public key from the server.
> 4. Using the fetched public key of the server, client encrypts a 128 bit
> random block and passes it back to the server. The random block is generated
> by the client - pay attention to the source of randomness.
> 5. Server decrypts the block using the private key.
> 6. All following client-server communication is encrypted by RC4 using the
> 128 bit block as the RC4 key.
> 7. A new RSA keypair is generated by the server every 24 hours.
This is a part of my current attempt at a solution but the problem with the
approach is that the client software may be replaced with one with all of the
same fucntionality except for the addition of one line of code saying
something like "before you send this random block to the server, display it
on the monitor." Which is why I think it's almost an impossible attack to
stop. I've got some other checks which try to circumvent this problem, but
as I said in the original post my "solution" is far from perfect.
Don't ask me .. I'm still trying to figure out what standards I'm
dedicated to as a nonconformist.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (George Barwood)
Subject: Re: Is speed of public-key algorithms important?
Date: Sat, 23 Jan 1999 20:25:30 GMT
On Thu, 21 Jan 1999 10:26:55 GMT, [EMAIL PROTECTED]
(Bodo Moeller) wrote:
>> [EMAIL PROTECTED] (Charles Blair):
>
>>> My understanding is that PGP and other protocols do the following:
>
>>> (1) Create a cryptographically strong hash of the plaintext. The
>>> size of the hash does not depend on the size of the plaintext.
>
>>> (2) Use the hash to create a key for a PRIVATE-key system, such as
>>> IDEA or something like DES. Encrypt the plaintext using this system.
>
>This method of creating the symmetric key is not advisable: If
>guessing the plaintext is feasible for the attacker...
>Instead of selecting the symmetric key deterministically as a function
>of the plaintext, the software should use a random number generator...
I would argue that it is best to do *both*. Random number generators
are notoriously difficult to implement securely, so a reasonable
assumption is that the RNG *may* be broken - hence including the
transmitted message in the hash as well as 'random' data is advisable
in practice, unless performance considerations make this unacceptable.
George
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: Can anyone offer opinions on TEA, XTEA?
Date: 23 Jan 1999 20:09 +0000
###
On 23 Jan 1999 12:04:08 -0500, in <78cve8$[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Thomas A. Oehser) wrote.....
> Has there been any further review of the tea/xtea algorithm?
>
> I saw only a comment that it was "too new to comment on", but,
> that was a long time ago... has it just been forgotten?
The summary of what I have heard about TEA is
1) the observation that certain bit swaps in the key are
no-ops, reducing the effective strength to 126 bits
2) a mention of "weaknesses in the key schedule", which might
be the same as 1 above
3) a comment that the algorithm has been broken, which might
just be 2 above after a few passes of Chinese whispers.
This is the first I've heard of XTEA.
I'd be glad of more info myself.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
ca077648f665b891f5d201d360cb31682f7dff5e3f2370e9f91f0acac9f5
e4a8c804ca344d7ee057a51cc184c8e429417c19de7f446afc37fda3ce1b
------------------------------
From: [EMAIL PROTECTED] (Derek Bell)
Subject: Re: Edupage coverage of Flannery story
Date: 23 Jan 1999 21:09:30 -0000
"hapticz" <[EMAIL PROTECTED]> writes:
>she may be a front for her daddy's intellect
I doubt it - she's made a good impression on the crypto people at
Baltimore Technologies.
>and the dearth of concrete info about this may be cautious trepidation about
>letting millions of pounds slip thru their hands+ACE-
They're getting a lot of enquiries, so they're probably busy with that.
Besides, William Whyte said that there was little chance of making money from
a public key patent nowadays.
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Derek Bell)
Subject: Re: Who will win in AES contest ??
Date: 23 Jan 1999 21:13:45 -0000
[EMAIL PROTECTED] (David Hamilton) writes:
>[EMAIL PROTECTED] wrote:
>> The winner will be one of the entries that the NSA has entered
>Which of the entries were entered by the NSA?
None.
>>which to the public will seem secure. If the method was any good
>>then it would not be so easily available. The US government would
>>never allow something to be used that it can not easily break.
>False. You attribute power to the USA government that it doesn't have.
Ah, but he knows this because his tinfoil hat shields his brain from
the orbital mind-control lasers! ;-)
Derek
--
Derek Bell [EMAIL PROTECTED] | Socrates would have loved
WWW: http://www.maths.tcd.ie/~dbell/index.html| usenet.
PGP: http://www.maths.tcd.ie/~dbell/key.asc | - [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: simple symetric encrypt <-> decrypt
Date: 23 Jan 1999 22:09:37 GMT
On Tue, 19 Jan 1999 10:18:22 GMT, "Daniel Feurle" <[EMAIL PROTECTED]> wrote:
>Have anyone of you an idea how i can encrypt and decrypt a simple
>integernummer.
>with a symmetric cryptosystem and without using -> x mod m
>modulo???
>
>example: 1234 -> encrypt -> (like) 3121239 -> decrypt -> 1234
None of the other answers took the requirement of **symmetric**
seriously.
I liked your problem so much I got around to doing it.
Have a look at:
http://www.frontiernet.net/~jmb184/interests/cryptography/flip.html
Because its in Javascript, you can look at the source.
Let me know if you find any problems.
John
http://www.frontiernet.net/~jmb184
ggw.org/donorware
------------------------------
Date: Sat, 23 Jan 1999 22:33:57 +0000
From: David Crick <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Who will win in AES contest ??
Paul Crowley wrote:
[much snippage]
> This leaves only:
>
> CAST-256, Crypton, Rijndael, Serpent, Twofish
>
> Two very popular candidates just got dropped: MARS and RC6.
[snip]
> but the AES winner has to be flexible enough to run in a wider
> variety of environments.
[..]
> I don't think that CAST or Serpent have enough to recommend them to
> justify the performance cost; this basically leaves Crypton,
> Rijndael, and Twofish as likely winners.
[..]
> However, I agree with the previous poster that Twofish is the most
> likely contest winner - it's the best performer on 32-bit processors,
> very competitive everywhere else, and offers a wide variety of useful
> implementation tradeoffs. It also has the most comprehensive > submission document.
Paul,
The above argument is exactly the kind of thing that NIST want to hear
with regards to the streamlining of the candidates for the end of
Round 1.
I'm in the process of compiling my own comments which I will submit
some time after I've read some of the [post] 2nd conference papers,
etc, and I hope you will also be submitting your own thoughts to NIST.
David.
--
+---------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/~vidcad/ |
| Damon Hill WC '96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| Brundle Quotes Page: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Key: (RSA) 0x22D5C7A9 00252D3E4FDECAB3 F9842264F64303EC |
+---------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Please help. Need protocol advice.
Date: Sat, 23 Jan 1999 22:34:42 GMT
In article <[EMAIL PROTECTED]>,
Mr. Tines <[EMAIL PROTECTED]> wrote:
> ###
>
> On Sat, 23 Jan 1999 08:40:55 GMT, in <78c1un$jbn$[EMAIL PROTECTED]>
> [EMAIL PROTECTED] wrote.....
>
> > I'm looking for a possible way to secure two-way (client/server)
> > communication even against attacks that may reverse-engineer and subvrt
> the
> > code on one end.
> With the code at the attacker's disposal, then so
> is the final prepared plaintext immediately before
> encryption.
Actually, my most important objective is to keep the encrypted data from
the server secure from a powerful, malicious client. It probably boils down
to a similar scenario, but I thought I'd mention it. I'm sending data to a
client which is (to me, anyways) highly sensitive and needs to be able to
remain secure even if the client has been unnoticeably modified to print the
keys and the incoming data, or something along those lines.
Don't ask me .. I'm still trying to figure out what standards I'm
dedicated to as a nonconformist.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Pentium III...
Date: Sat, 23 Jan 1999 23:20:21 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 23 Jan 1999 18:50:52 GMT, Daniel James
<[EMAIL PROTECTED]> wrote:
>The serial number in the chip is to help control the trade in stolen CPUs,
>which is a big moneyspinner in certain parts of the criminal world.
Once again the law-abiding citizen has to pay the price for the
ineptness of law enforcement.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Algorithms & Attacks: Supplementing Bruce's Course...
Date: 23 Jan 1999 23:28:03 GMT
Just added a new page to my site called,
"Algorithms and Attacks." There you'll find
links to Gladman's AES implementations,
and links to the AES Block cipher lounge
and the CAESar project. The latter two
sites link to various AES attacks.
I've included, when I could find them,
links to implementations of and attacks
on such fare as FEAL, FEAL8, FEAL-NX,
Akelarre, and Skipjack.
With a bit more searching on my part
and some help from you folks, I hope
this section will grow so that it might
be used with Bruce's self-study
cryptanalysis course.
Also, fairly new in the contest section
is the scott19u contest. This contest
should be fairly easy to solve. Each
month starting in March a clue -- one
nibble -- will be given. No money
involved in this one. Try it for fun...
or to gloat.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Metaphysics Of Randomness
Date: Sat, 23 Jan 1999 23:29:42 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 23 Jan 1999 08:59:09 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>No, there is no other difference. The fundamental concept is that the
>key value should be selected (generated) by a method that makes it as
>hard as possible for an attacker to guess the key.
And the only proveably secure method of doing that is to use a TRNG.
>I think the latter is true. The discussion above involves two
>conclusions: 1. any filtration reduces strength by some amount; and 2.
>Filtering out pathological patterns is not harmful to the security of
>an OTP.
If those are restricted to 111...1 and 000...0, I agree. It is far
more dangerous to ignore those two sequences than to use them for
diagnostics.
If you do use them as diagnostics only, and only shut the TRNG down
for maintenance, and then restart the TRNG, the subsequent output is
not affected in any way, so the proveable security is not impacted.
There is no rule that states that you must use only continuous output.
>In theory yes. An attacker knowing your intention to avoid using "bad"
>patterns does not have to consider those keys. Thus his job is easier.
>However, the amount of reduction in the work he has to do is
>infinitesimal.
.... if the strings are long enough. If the string is 2 bits long, then
you have a serious problem because then you have filtered 1/2 your
output.
>In theory filtration is "bad". In practice, you run the numbers, and
>find that reasonable filtration reduces you key strength by around one
>bit. Consider it a form of "weak key" avoidance.
Consider it essential diagnostics.
Bob Knauer
"It is not the function of our government to keep the citizen from
falling into error; it is the function of the citizen to keep the
government from falling into error."
--Justice Robert H. Jackson
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Cayley
Date: 23 Jan 99 22:22:46 GMT
Herman Rubin ([EMAIL PROTECTED]) wrote:
: Cayley numbers are simple enough. But why should someone in
: cryptography be interested in nonassociative division algebras over
: the REAL NUMBERS? There is so much more flexibility over the
: rational numbers, even commutative (field extensions) or
: associative. The extensions of the Cayley idea to algebras over
: other fields are called Cayley-Dickson algebras.
Although a 3x3 matrix usually uses real numbers as its elements, nothing
can stop us from using a matrix that happens to be filled with integers.
The Hill cipher uses matrices whose elements are integers modulo 26, and
this changes somewhat the allowed manipulations when inverting a matrix
(instead of multiplying a row by any nonzero number, the number must be
relprime to 26; this condition does not apply when you multiply a row by a
number to add to another row).
So one can also have complex numbers whose components are integers modulo
M where M=pq, or quaternions or octaves of that kind.
If the term "Cayley-Dickson algebra" is applicable to this sort of thing,
this is good to know, but I am not aiming for so much mathematical
sophistication as to become obscure.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Pentium III...
Date: 23 Jan 99 22:26:15 GMT
Daniel James ([EMAIL PROTECTED]) wrote:
: The serial number in the chip is to help control the trade in stolen CPUs,
: which is a big moneyspinner in certain parts of the criminal world.
I hadn't thought of that, but you are correct.
Also, as the serial number will identify the type of the chip - and its
rated clock speed - that should help combat *fraudulent* overclocking in a
way that does not require Intel to design the chips to prevent
overclocking by the individual user.
However, a serial number accessible to software will be used by some
software packages for software piracy prevention: it will not be suitable
for most mass-market software, but there are packages to which that sort
of thing is applicable.
John Savard
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Why does the GOP hate encryption? [no PGP content]
Date: 18 Jan 1999 10:19:00 +0100
Does anyone actually believe that the Republican party is any more sympathetic to the
cause
of popular encryption than the Dems? Come on, gimme a break. I don't give a rat's
ass about
Clinton's current troubles, what bothers me is the way he and Gore backpeddaled on
this
issue. Long criticized for co-opting republican ideas, he did the same with this one.
Anti-encryption/pro law enforcement in this regard is a totally Republican agenda.
Clinton sold us
out on this one. The Republicans will be the ones to just slam this door shut on
privacy.
------------------------------
Date: Sat, 23 Jan 1999 18:47:49 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Please help. Need protocol advice.
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Mr. Tines <[EMAIL PROTECTED]> wrote:
> > ###
> >
> > On Sat, 23 Jan 1999 08:40:55 GMT, in <78c1un$jbn$[EMAIL PROTECTED]>
> > [EMAIL PROTECTED] wrote.....
> >
> > > I'm looking for a possible way to secure two-way (client/server)
> > > communication even against attacks that may reverse-engineer and subvrt
> > the
> > > code on one end.
>
> > With the code at the attacker's disposal, then so
> > is the final prepared plaintext immediately before
> > encryption.
>
> Actually, my most important objective is to keep the encrypted data from
> the server secure from a powerful, malicious client. It probably boils down
> to a similar scenario, but I thought I'd mention it. I'm sending data to a
> client which is (to me, anyways) highly sensitive and needs to be able to
> remain secure even if the client has been unnoticeably modified to print the
> keys and the incoming data, or something along those lines.
>
As stated the only answer is a serious piece of hardware. But I'm a little
curious. You stated that you wanted to keep the encrypted data froma malicious
client. I suspect you meant the unencrypted data. The question is, what do you
want friendly clients to do that malicious clients cannot do?
------------------------------
** 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
******************************
