Cryptography-Digest Digest #943, Volume #9 Tue, 27 Jul 99 19:13:05 EDT
Contents:
Re: Novice question .. (fungus)
Re: Novice question .. (Jim Gillogly)
Re: Kryptos morse code - "DIGE TAL INTERPRETATU?" (Jim Gillogly)
Re: OK. Maybe I am missing something here. (John Savard)
Re: How would this effect the good old One Time Pad? (wtshaw)
Re: How would this effect the good old One Time Pad? ("Jeffery Nelson")
Re: another news article on Kryptos ("Douglas A. Gwyn")
Re: Location of Crypto ("Douglas A. Gwyn")
Pentium III & cripto ([EMAIL PROTECTED])
Re: How would this effect the good old One Time Pad? ("Jeffery Nelson")
Re: convert key (John Xiao)
Re: OTP export controlled? (Jim Dunnett)
Re: to the group... well... ("Robert C. Paulsen, Jr.")
Re: convert key (Michael Slass)
reviews on PAAM (Drew Cutter)
Re: message digest problem? (David P Jablon)
Re: How Big is a Byte? ([EMAIL PROTECTED])
Re: How would this effect the good old One Time Pad? (Jerry Coffin)
Re: What the hell is XOR? ([EMAIL PROTECTED])
Re: hush mail ([EMAIL PROTECTED])
Open source version of PGP !!! (spike)
Re: Pentium III & cripto (John Savard)
----------------------------------------------------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Novice question ..
Date: Tue, 27 Jul 1999 18:18:55 +0200
Jim Gillogly wrote:
>
> fungus wrote:
> >
> > "Paper and pencil" ciphers have great difficulty in wiping out all
> > statistical information, and unless you do this then a computer can
> > break it quite easily.
>
> That's pretty glib. A combined substitution and transposition can
> be quite challenging, with or without computers. "Quite easily"
> is an overstatement, if we assume reasonable Playfair keys (i.e.
> a fairly mixed square) and a "good transposition cipher" as he
> specified -- e.g. a double transposition with a long key or two.
> Even if some of the statistical information shows through, just
> throwing a computer at it won't exhaust the key-space, so you'll
> need to do something clever.
>
Ok, maybe I was a bit harsh. If the methods used are obscure, then
yes, these ciphers could cause a lot of trouble to a cryptoanalyist.
OTOH, if I know you used a playfair followed by a vigenere, and
I had a nice little program to let me fiddle with the results
graphically, I could probably break it in a morning.
> > Codes like this were being broken regularly 50 years ago. We've got
> > fast computers...
>
> We do have faster computers, but they need to be programmed with
> something better than brute force to handle this kind of thing.
>
Software guided by a human hand, the best of both worlds.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Novice question ..
Date: Tue, 27 Jul 1999 09:34:00 -0700
fungus wrote:
>
> Jim Gillogly wrote:
> > A combined substitution and transposition can
> > be quite challenging, with or without computers. "Quite easily"
> > is an overstatement, if we assume reasonable Playfair keys (i.e.
> > a fairly mixed square) and a "good transposition cipher" as he
> > specified -- e.g. a double transposition with a long key or two.
> > Even if some of the statistical information shows through, just
> > throwing a computer at it won't exhaust the key-space, so you'll
> > need to do something clever.
>
> Ok, maybe I was a bit harsh. If the methods used are obscure, then
> yes, these ciphers could cause a lot of trouble to a cryptoanalyist.
>
> OTOH, if I know you used a playfair followed by a vigenere, and
> I had a nice little program to let me fiddle with the results
> graphically, I could probably break it in a morning.
Likely, assuming a reasonable length Vigenere key. Playfair in
particular has some nasty regularities that would help with
this analysis. For example, if the message is long enough
your Vigenere evaluation function could eliminate all Playfair
possibilities that resulted in an XX digraph (for any X), since
Playfair won't produce those. This would be the killer stat I'd
look for in this case.
The system proposed by Neil Bell was not Vig, but a "good transposition
cipher" following the Playfair. Double transposition with long
keys and a single long text is challenging enough without the initial
Playfair step, and I think this would be more than a morning's fiddling.
I agree that something that left fewer tracks than Playfair would be
a better choice for the first cipher. Maybe a longish period Vig
for the first step followed by a long-key double transposition for
the second would suffice to spoil your whole week.
In another followup thread John Savard asked how you'd arrange a separate
key for each message. Leo Marks described two main methods in "Between
Silk and Cyanide": the weaker one was based on differing uses of the same
shared secret (a poem in this case); the stronger one used a shared
printed table of secret keys. The idea of having the key to the next one
in each message is bad for the usual reasons: if the plaintext is
compromised by any means (e.g. the ashes of the worksheet are recovered
intact in the grate), the enemy need not lose contact with any future
traffic.
--
Jim Gillogly
Highday, 4 Wedmath S.R. 1999, 16:20
12.19.6.7.2, 7 Ik 10 Xul, Seventh Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Kryptos morse code - "DIGE TAL INTERPRETATU?"
Date: Tue, 27 Jul 1999 09:39:02 -0700
Sundial Services wrote:
>
> Jim Gillogly wrote:
>
> > of the more usual A against the '+' on the plaintext disk. "DIGE TAL
> > INTERPRETATU" might suggest some kind of digit-based running key for K-IV,
>
> Could this be a typo or is it a clue? ;-)
>
> Morse "E" is "." but you expect Morse "I" which is ".."
>
> U "..-" is somewhat like ION ".. --- -."
>
> Morse mutilation? Seems odd for a sculpture.
I suspect Morse mutilation is in fact the answer. If the second
dot of the second I in DIGITAL were broken off for a souvenir, the
result would be DIGE TAL. The INTERPRETATU could easily be an
example of the old
THINK AHea
d
that was popular a couple of decades ago: just not room for the
whole message, and enough of it had gotten through already. When
we ship Doug out there for his second round he can check to see
if the space in DIGE TAL has a shiny spot, and if there'd be room
for the final "-- -." at the end, and if there's more of a space
in the "..-" of the U. I'd volunteer to go myself, but the way
the media has been playing this up as a competition, I'm not sure
they'd let me out!
--
Jim Gillogly
Highday, 4 Wedmath S.R. 1999, 16:34
12.19.6.7.2, 7 Ik 10 Xul, Seventh Lord of Night
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OK. Maybe I am missing something here.
Date: Tue, 27 Jul 1999 15:41:51 GMT
[EMAIL PROTECTED] (Shktr00p1) wrote, in part:
>More than one file,
>How do you figure? That's 1000 bytes of random data which is overlayed by
>another 8 bytes just so that each file is encrypted slightly different. Since
>the 1000 bytes is already random and just encryted again by 8 bytes, what basis
>of decrpytion cracking would be used?
Essentially, a cryptanalyst would use the *relationship* between two
encrypted files, produced by means of the same 1000 bytes of random
data, and two different 8-byte keys.
If the attacker didn't have known plaintexts, his work *would* be
harder than if the text itself were directly encrypted with an 8-byte
key, but it would not be impossible.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How would this effect the good old One Time Pad?
Date: Tue, 27 Jul 1999 11:13:06 -0600
In article <[EMAIL PROTECTED]>, "Jeffery Nelson"
<[EMAIL PROTECTED]> wrote:
...
>
> But because you do have a key perhaps adding a little extra security could
> be accomplished by doing this:
>
> abcdefghijabcdefghij
>
> and then encrypting the center characters of the first repition of the key
> (as close as can be determined) -to- the center of the second repition of
> the key with the key it's self. As shown...
>
> abcde|fghijabcde|fghij
> |abcdefghij|
>
There is something here, and I did a demonstration of it here in 1995, and
was part of my campaign to stress the idea that any text can be made into
a useful key. The idea is offsets, that a single long string can be
compounded with itself several times to create a new string. One or two
offsets can be solved fairly easily with a short string. Even for a sort
string, a few more offsets and the original is very difficult to
reconstruct.
I'll take the above paragraph and use it as the base string for a key.
Then, I'll combine it with an offset of itself of 100 alphabetic letters.
Finally, I'll encrypt a passage of your comments from above.
> xww nrah bhykmmdrnt euv oxqwqf pmjxwkwdrd ut vqa vibfk kdgwtyqy ea egt jbo
> (uh gresk qw xsm uu gqggezveta) -dl- shg izkfdp go zax vduqfn xldpdroh if
> ukd gnv hxqr oja ayg gr'b xuyk. Au uioce...
Because of the nature of the language, note that some letters heal
themselves, but chance means this will happen. It is not enough to make
the passage easily solved.
Notice that I selected a key which would be quite long, longer than the
passage to be encrypted.
--
Freedom means having the right to chose to be isolated and left
alone. It also means not having the right to force someone to get
involved. But, the continuation of freedom demands that some of
us act for those that can't or won't.
------------------------------
From: "Jeffery Nelson" <[EMAIL PROTECTED]>
Subject: Re: How would this effect the good old One Time Pad?
Date: Tue, 27 Jul 1999 12:22:17 -0000
I wasn't sure if this was a good idea or not, but here's another though.
Although this would take lots of time, both in computer computation and your
guessing on how they did it to code the computer. It can be broken
none-the-less (because, as you know, it is still a form of repition). I do
agree that your theory would work though, and perhaps to a better degree
than mine. Especially if they couldn't disassembel your code (BTW if anyone
has documentation and\or commends on how to make your code harder to
disassembel or make it harder to understand once it is disassembeled I
wouldn't mind haveing a copy...) to find your methods. Did you ever code a
version of what you are refering to? If so could you email it to me?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: another news article on Kryptos
Date: Tue, 27 Jul 1999 14:04:54 GMT
wtshaw wrote:
>> Best to not put blinders on prematurely. If I got it right, *a whole new
> ball game* could be sort of a cryptic clue.
Not likely; that's a standard American idiom.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Location of Crypto
Date: Tue, 27 Jul 1999 14:07:33 GMT
Shktr00p1 wrote:
>... it is egotistcal of our big brother to assume that only good
> encrpyption software can be created in the U.S.
I don't think that was ever assumed by the creators of the policy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Pentium III & cripto
Date: Tue, 27 Jul 1999 17:39:20 GMT
Hi,
Does anyone knows how is going to affect the new Pentium III's SIMD
instructions in the computing of crypto algorithms?
There is going to be any speed up at all?
See you,
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Jeffery Nelson" <[EMAIL PROTECTED]>
Subject: Re: How would this effect the good old One Time Pad?
Date: Tue, 27 Jul 1999 13:00:11 -0000
But...
You limiting the key size to 1,000,000 is an understatement. This theory
represented by mine and wtshaw's deliberations could be repeated, in theory,
forever. Each time, you would yield a key of lenght pow(strlen(key),2) (or
lenght of key squared). According to theory, the key could be made
indefinitly long. Especially if you use wtsha's version of useing character
offsets by adding to their binary values. You coud (to make it even harder
to decrypt) set the offset number to be equal to the integer value of the
first ASCII character and so on, respective to your curretn repition of the
function.
In a way, I'm agreeing with you, but I don't see why the key would be
limited to 1,000,000. And the actual KEY could be plaintext and you use the
decryption program on the other end to do all the modifications needed to
decrypt with it. I guess that is why you were saying it was like a block
cypher?
-Jeff
------------------------------
From: John Xiao <[EMAIL PROTECTED]>
Subject: Re: convert key
Date: Tue, 27 Jul 1999 14:26:41 -0500
I tried it, openssl did the conversion, but is the *.der binary or what?
also, how can I convert the key to hexadecimal?
Michael Slass wrote:
> If you're using the openssl command-line tool, you can use
>
> openssl rsa -inform PEM -in mykey.pem -outform DER -out mykey.der
>
> -Mike
>
> John Xiao wrote:
>
> > How can I convert my private key from base64.1 to binary?
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Crossposted-To: talk.politics.crypto
Subject: Re: OTP export controlled?
Date: Tue, 27 Jul 1999 19:00:28 GMT
Reply-To: Jim Dunnett
On Mon, 26 Jul 1999 13:32:09 -0700, Jim Gillogly <[EMAIL PROTECTED]> wrote:
I wrote:
>> Isn't this the cipher which Kahn describes as a modified
>> Nihilist? Combining a straddling checkerboard with a
>> one-time key.
>
>Yes, in essence, but the "one-time" key Kahn describes (pp 650ff)
>is from well-known published statistical books.
>
>> Appears it was the standard Soviet spy cipher in WW-II.
>> He speaks highly of it. Surely it's unbreakable if the
>> additive key is unpredictable?
>
>Yes, but picking a published book isn't the right idea.
Absolutely. But if the additive *is* unpredictable, it equates
to a novel one-time-pad.
>Has the source of Guevara's been traced? Is that the famous
>"Cuban girls typing randomly" algorithm?
I read somewhere that the Russians tried this way of generating
OTP key for spy communications, but scrapped the idea when they
detected bias in the key. (Probably Kahn again).
--
Regards, Jim. | Findhorn Community:
amadeus%netcomuk.co.uk | Developing EcoVillage
dynastic%cwcom.net | of about 350 people:
|
PGP Key: pgpkeys.mit.edu:11371 | http://www.gala.org/findhorn/
------------------------------
From: "Robert C. Paulsen, Jr." <[EMAIL PROTECTED]>
Subject: Re: to the group... well...
Date: Tue, 27 Jul 1999 15:52:03 -0500
Jeffery Nelson wrote:
>
> I did as you said (in most cases, for debug output I still used cout), but
> this didn't fix my problem. The REAL problem was the fact that for some
> reason the code I put out will only extract 455 of the actual 307,514
> characters in that file before encountering a "so called' EOF. My loop
> breaks and I've only got 455 characters encrypted out of the total 307,514
> in the entire binary stream. This poses a real problem because my
> encryption algorythm (like most) outputs the cyphertext as binarary
> characters, and not readable char's... I can't double encrypt things with
> two keys, because it won't get 'all' the infromation back out of the file...
> Here is the updated source with the changes... The cout doesn't do
> anything, but I left it in there...
>
Well, the cout does something on *my* system -- it trashes the
console by spewing out lots of non-ASCII stuff!
Another problem with your code is the way you count. First, you
start with one instead of zero. (The count shouldn't be at 1 before
anything is read. Second, you increment the count before checking
that the read went OK.
Something else to try... Use cin.read() instead of cin.get()...
char got;
long x = 0;
for( x=0; inFile.read(&got,1); ++x )
{
// process the character here
cout<< int(got) << ' ';
}
cout<< "size: " << x << endl;
--
____________________________________________________________________
Robert Paulsen http://paulsen.home.texas.net
If my return address contains "ZAP." please remove it. Sorry for the
inconvenience but the unsolicited email is getting out of control.
------------------------------
From: Michael Slass <[EMAIL PROTECTED]>
Subject: Re: convert key
Date: Tue, 27 Jul 1999 13:51:02 -0700
Yes, DER is binary. If you want to see the key in hex, use
openssl -inform DER -in mykey.der -text
This will display all three components of the key, as well as the original
primes and the intermediate numbers that were used to generate the key,
nicely formatted with lables and hex byte pairs.
-Mike
John Xiao wrote:
> I tried it, openssl did the conversion, but is the *.der binary or what?
>
> also, how can I convert the key to hexadecimal?
>
> Michael Slass wrote:
>
> > If you're using the openssl command-line tool, you can use
> >
> > openssl rsa -inform PEM -in mykey.pem -outform DER -out mykey.der
> >
> > -Mike
> >
> > John Xiao wrote:
> >
> > > How can I convert my private key from base64.1 to binary?
------------------------------
Date: Tue, 27 Jul 1999 16:29:50 -0400
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: reviews on PAAM
I'm looking for reviews of PAAM (pluggable authentication and
Authorization Module). Any Opinion on strength and weakness of this
method of single sign on.
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: message digest problem?
Date: Tue, 27 Jul 1999 21:31:35 GMT
In article <[EMAIL PROTECTED]>,
Bill Lynch <[EMAIL PROTECTED]> wrote:
>I was doing some reading on Message Digests (specifically in Jonathan
>Knudsen's "Java Cryptography") and maybe I'm missing the boat but it
>seems that this is vulnerable to a replay attack.
>
>Here's what he suggests for a secure authentication (username/password).
>Instead of transmitting the username and password in plain text, we'll
>take the password and send the message digest of it. The username is
>sent as plain text -- the server uses the username to look up the
>password, run it through the same message digest algorithm -- if both
>the server digest and the one transmitted by the client match, the
>client is authenticated.
He forgot to add a random value to the input of the hashed
response. Then you only get to the state of the art ... for 1988.
The big remaining problem is that many passwords can be brute-force
or dictionary cracked by anyone with access to the challenge
and the hashed response.
To learn about modern protocols, like SPEKE, EKE, and SRP, visit
www.integritysciences.com.
======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>
------------------------------
Date: Mon, 26 Jul 1999 18:23:05 -0400
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte?
Douglas A. Gwyn wrote:
>
> [EMAIL PROTECTED] wrote:
> > Douglas A. Gwyn wrote:
> > > [EMAIL PROTECTED] wrote:
> > > > If the number line is entended into the negative realm there are
> > > > alternate representations of zero. 1-1 would be one such.
> > > That's no longer base 1.
> > ... as you define it.
>
> That's not base 1 as any competent mathematician defines it.
> You can't obtain the -1 term by raising 1 to any integer power.
I think I disagree, but I'm certain I do not fully understand your
statement above. Would you please amplify it with an example of
generating negative terms in any other base by raising something to a
power?
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: How would this effect the good old One Time Pad?
Date: Tue, 27 Jul 1999 15:25:20 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> But...
>
> You limiting the key size to 1,000,000 is an understatement.
Perhaps I misunderstood what you said, but I thought that was the
number you gave in your post.
If you simply meant "some very large number", then analyzing the
result becomes essentially impossible. At least as I read your method
of incraeasing the effective key size, it's fairly limited in how far
you can go with it. You appear to be XORing the key with a shifted
part version of the same key to get a larger effective key. The
problem is that starting with a 1000 byte key (using your example) you
can only shift it a total of 999 places. After that, you're XORing
bytes with themselves, which will always produce 0's.
At least as I understand your proposal, your answer to that is that
after you shift 999 places, you no longer XOR the key with the shifted
version of the key, but with the previous XORed version of the key.
At this point things start to get tricky, but there's always a limit
on how far you can go -- by shifting and XORing the key with itself,
you're always going to come to a point that you're XORing a part of
the key with itself, thereby cancelling out that part of the key.
Don't get me wrong: if you're clever enough with this, there's no
question that you can create a very long effective key.
> In a way, I'm agreeing with you, but I don't see why the key would be
> limited to 1,000,000. And the actual KEY could be plaintext and you use the
> decryption program on the other end to do all the modifications needed to
> decrypt with it.
I'm not sure I follow what you're saying here.
> I guess that is why you were saying it was like a block cypher?
I was saying it was like a block cipher mostly because of two things:
first of all, the key is only modified by other parts of the key,
rather than by the previously encrypted text as is usually the case
with a stream cipher. Second, as you described it, the cipher
basically works in 500 byte chunks, at least as I read your
description. Unfortunately, it doesn't seem to have anything similar
to the avalanche effect you normally expect to see in a block cipher;
one byte of key effects only one byte of output.
------------------------------
Date: Mon, 26 Jul 1999 18:32:21 -0400
From: [EMAIL PROTECTED]
Subject: Re: What the hell is XOR?
Douglas A. Gwyn wrote:
>
> "SCOTT19U.ZIP_GUY" wrote:
> > XOR R1,R2 which is make r2 = r1 XOR r2
> > XOR R2,R1 which is make r1 = r1 XOR r2
> > XOR R1,R2 which is make r1 = r1 XOR r2
>
> This is a well-known hack. If it weren't so well known,
> it would be obscure and thus require documentation via a
> comment in the source code at that point. Unless there
> is a bottleneck at that point, swapping via a temporary
> would be clearer and thus preferable (from a code
> maintenance point of view).
Actuall swapping via a temporary may produce much faster code on a CPU
with speculative execution. Since speculative execution depends heavily
on register renaming the swap devolves into a double rename.
Even without an advanced CPU some compiler may be smart enough to handle
the renaming as part of the register allocation/tracking optimization.
Simpler is *MUCH* better than tricker.
------------------------------
Date: Mon, 26 Jul 1999 18:44:32 -0400
From: [EMAIL PROTECTED]
Subject: Re: hush mail
[EMAIL PROTECTED] wrote:
>
> David A Molnar wrote:
>
> > I can't speak for the designers of the AES process, but I will note that
> > if practical quantum computers are built, then a space of n bits may be
> > searched in sqrt(n) time. In this case, a 256-bit cipher is "only" as
> > difficult to brute force as a 128-bit cipher would be w/o quantum
> > computers.
>
> Eh? Wouldn't that mean that that a 256 bit encryption would be equal to 16
> bit b/c sqrt(265) = 16?
The calculation is based on the number of possible states of an N-bit
variable. There are 2^N such states. QC works on the sqrt(states) not
sqrt(bits). Since sqrt(2^256) is 2^128, you get the conclusion stated
above.
------------------------------
From: spike <[EMAIL PROTECTED]>
Subject: Open source version of PGP !!!
Date: Tue, 27 Jul 1999 15:00:47 -0700
Reply-To: [EMAIL PROTECTED]
==============C20A6E456CE0243DA89800A3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hey all...
What do you all think of the Gnu Privacy Guard, also known as GPG ? It
is intended to be a freeware version of pgp sponsored by the Free
Software Foundation as part of the GNU system. You can check out this
web page for more information. Any input regarding the quality of this
would be very appreciative.
http://www.gnupg.org
Thanks in advance...
Spike
==============C20A6E456CE0243DA89800A3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<br>
<p>Hey all...
<p>What do you all think of the <a href="http://www.gnupg.org">Gnu Privacy
Guard, </a>also known as <a href="http://www.gnupg.org">GPG</a> ? It is
intended to be a freeware version of pgp sponsored by the Free Software
Foundation as part of the GNU system. You can check out this web page for
more information. Any input regarding the quality of this would be very
appreciative.
<p>
<a href="http://www.gnupg.org">http://www.gnupg.org</a>
<p>Thanks in advance...
<p>Spike
<br>
<br> </html>
==============C20A6E456CE0243DA89800A3==
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Pentium III & cripto
Date: Tue, 27 Jul 1999 22:55:35 GMT
[EMAIL PROTECTED] wrote, in part:
>Does anyone knows how is going to affect the new Pentium III's SIMD
>instructions in the computing of crypto algorithms?
>There is going to be any speed up at all?
The Pentium III's "Streaming SIMD Extensions" are an extension of MMX
which includes, as its major feature, short vector (two elements!)
floating-point arithmetic.
This won't be terribly relevant to cryptography, which usually uses
integer arithmetic. When floating-point arithmetic is used, for
example in some Schonhage-Strassen routines, it is double-precision
arithmetic which is used in any case. (SSE fits two 32-bit single
precision reals in one 64-bit vector.)
So there is very little relevance of this new feature to cryptography.
However, a new support chip used with the Pentium III offers the very
important feature of hardware random numbers, but that feature is not
generally available (documentation of it is not released).
The forthcoming (middle of next year) IA-64 architecture does promise
some exciting improvements that may relate to cryptography. A
population count instruction is included (maybe because PA-RISC had
one?) and there is also a transposition instruction, MUX;
unfortunately, though, it only transposes 16-bit segments in an
arbitrary way, and 8-bit bytes in a handful of preprogrammed ways;
there is no real bit transposition instruction.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
