Cryptography-Digest Digest #184, Volume #12 Sun, 9 Jul 00 14:13:01 EDT
Contents:
Re: A thought on OTPs ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Implementing RSA................ (Bill Unruh)
Re: DES Analytic Crack (Bill Unruh)
Re: Use of EPR "paradox" in cryptography (Bill Unruh)
Re: Use of EPR "paradox" in cryptography (Bill Unruh)
Re: Using CRC's to pre-process keys (David A. Wagner)
Re: Efficient algorithm to determine relative primality? (root)
Re: Using CRC's to pre-process keys (David A. Wagner)
Re: Has RSADSI Lost their mind? (Bill Unruh)
Re: Has RSADSI Lost their mind? (Bill Unruh)
Random Numbers ("David Hyde")
Re: Using CRC's to pre-process keys ("Scott Fluhrer")
Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html
("tok")
Re: Quantum Computing (Was: Newbie question about factoring) (Bill Unruh)
Re: Proposal of some processor instructions for cryptographical (Dennis Yelle)
Re: Random Numbers (Roger Schlafly)
Re: Random Numbers ("Scott Fluhrer")
Re: Concepts of STRONG encryption using variable base http://www.edepot.com/phl.html
("tok")
Re: Using CRC's to pre-process keys (Mack)
Re: RC4 question (Bill Unruh)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Re: RC4 question (Johnny Bravo)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: A thought on OTPs
Date: Sun, 09 Jul 2000 12:01:06 -0400
Mok-Kong Shen wrote:
> My point has been that it is an interesting fact that, while there is no
> generally applicable test for independence (a correlation test can be
> considered a pre-test to screen out unnecessary test candidates) in
> practice, one nonetheless in quite a number of places of applied
> statistics makes assumption of independence of random varaibles (and
> deduces results, which are certainly theoretically interesting, but
> .....).
Your point seems to be confusion. As I have repeatedly explained,
independence is a (mathematically precisely defined) property that
is used in the construction of a *model*. It is no different from
using the property that an unbiased cubical die has the probability
1/6 of showing a particular number 1..6 when rolled, or any similar
theoretical property. It allows us to make predictions, e.g. what
the odds are for the total on N dice. Whether or not the model is
sufficiently accurate in describing a particular actual real-world
experiment is a different matter; by having precise theoretical
properties, we are able to make predictions and devise tests that
measure how well the model actually fits the observations. For
randomized behavior, these (inherently statistical) tests cannot
(for a potentially unbounded set of observations) *prove* with 100%
certainty that the observed system is behaving *exactly* in
accordance with the model; what such a test provides is a measure
of the degree to which the observations are consistent with the
model. If we make enough observations and there is a large
discrepancy between what the model predicts and what was observed,
then our confidence in the model's predictive ability for this
particular physical set-up becomes very low. Pearson's chi-square
is a typical classical test of this kind, although there are others.
This whole area should be discussed in any decent textbook on
statistics, typically under the heading "hypothesis testing" if
not at the very beginning of the text.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 12:06:09 -0400
Mok-Kong Shen wrote:
> I think that 64-bit PCs are in the coming, and the price of 64-bit
> workstations are going down to be affordable to those having serious
> encryption jobs that justify higher expenses.
Many of us have been using architectures with 64-bit words on our
desktops for several years now.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 12:18:02 -0400
Mok-Kong Shen wrote:
> > This is called bit reversal. It is common in digital signal processing.
> I implicitly assume a common processor, e.g. what people normally
> have access to, e.g. a PC.
Bit reversal isn't very expensive on traditional architectures,
especially if you can use assembly language so that you can get
at the carry bit. But in any case, DSP peripherals are not very
expensive, and they would be cheaper still if many people really
wanted them. Why should much of the CPU design be geared toward
your particular application if nobody is clamoring for it?
What would serve a wide variety of applications, including
cryptology, better would be good support for bit addressing.
I've discussed this with computer architects in the past, and
they have agreed that it would be useful, but were not able to
sell the idea to management, largely because common programming
languages are unable to make direct use of the facility. There
is a "chicken and egg" situation here; when I tried to get the
specs for Standard C to support bit addressing in implementations
that had it, the counterargument was that there wasn't a
significant amount of hardware that had good enough support for
bit addressing to worry about such implementations.
Wouldn't it be a whole lot better to be able to write
bit a[1024], b[1024];
int i;
for (i = 0; i < 1024; ++i)
b[i] = a[1023-i]; // reverse bit order
and get lightning-fast execution?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 12:22:07 -0400
Thomas Womack wrote:
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote
> > Transposition is one of the basic operations in cryptography.
> Is it, any more? Having a look at the AES candidates, most of them
> carefully refrain from calling for bit transpositions simply because
> they're rather hard to implement.
Whether the operation is basic is a different question from whether
awkward support for it causes it to be underutilized.
Transposition and substitution, sometimes under the names diffusion
and confusion, are often considered basic cryptographic principles.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Implementing RSA................
Date: 9 Jul 2000 16:46:17 GMT
In <8jg12s$c03$[EMAIL PROTECTED]> "Daniele \(Neo\)"
<[EMAIL PROTECTED]> writes:
]-----BEGIN PGP SIGNED MESSAGE-----
]Hash: SHA1
]Hi,
]I'm implementing RSA in JavaScript (yea, the same scripting language
]used in HTML pages.......).
Bad idea.
]Both Netscape and Microsoft documentation say that numbers supported
]in javascript are included in this range: 1,79E+308 and 1,79E-308 (a
]tipical *double* type specification in VB, or Java, or other
]programming language.............)
Those are NOT integers between those ranges, but floats. Floats are
encodes with a 64 ( or maybe 80) bit number plus 9 bit or so exponent.
Ie, It cannot reliably encode an integer larger than 64 (or 80) bits,
which is 10^ 19 ( or 10^24).
You MUST either impliment or use a big number package to use RSA.
You CANNOT use standard math packages.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: DES Analytic Crack
Date: 9 Jul 2000 16:49:47 GMT
In <[EMAIL PROTECTED]> "Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
]Mok-Kong Shen wrote:
]> Do you know any literature about obtaining and solving the set of
]> equations for DES? Could you give any reference or are you merely
]> postulating on a miscalculation? Thanks.
]As previously reported here, many years ago a colleague constructed
]the complete, explicit set of DES encipherment equations and printed
]them on a line printer, resulting in output just a few inches thick.
]That much data can easily be held in RAM on today's computers.
?? Who cares how much memory it requires to hold the equations? What
matters is how much memory is required to solve the equations, a
different question entirely.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
Date: 9 Jul 2000 16:53:03 GMT
In <[EMAIL PROTECTED]> DSM <[EMAIL PROTECTED]> writes:
>Why haven't I heard of any use of the EPR "paradox"
>in cryptography? Is it only my poor research, or something
>else?
It is only your poor research. Look for the phrase
Quantum Cryptography.
>From what I know, EPR allows uninterceptable, untraceable,
>instantaneous exchange of RANDOM data. Many have concluded
Easily intercepted, not instantaneous.
>that its inability to carry true (non-chaotic) data makes
>the phenomenon useless for communication. Not so. This is
>the perfect one-time pad mechanism. Simply XOR your data
>on both sides of the (conventional) link with the stream
>from your EPR boxes...
And your attacker can just intercept on of the epr pairs, read it and
send on to you the output.
That is why the protocol is more complex.
>Is it the expense of EPR machinery which prevents widespread
>use? How much does a setup cost? Could it be built out of
>open-market materials?
Read the literature.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: sci.physics
Subject: Re: Use of EPR "paradox" in cryptography
Date: 9 Jul 2000 16:56:48 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John
Savard) writes:
>>Not really, at witnessed by the fact that one cannot exploit
>>EPR to send controlled information faster than light.
>Yes, one cannot do that. However, the one measurement still does
>affect the other measurement, since if both measurements are of the
>same polarity component, the results always match.
That is called correlation, and exists in the classical world as well.
It is just that quantum correlations are "stonger" and different than
classical. Ie, you must be very careful in QM to differentiate between
correlation and quantum entanglement, and often people people talk about
the latter when their discussion is about the former.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Using CRC's to pre-process keys
Date: 9 Jul 2000 09:57:59 -0700
In article <[EMAIL PROTECTED]>,
Mack <[EMAIL PROTECTED]> wrote:
> I believe what he was trying to say is that if you take a SHA-1 for example
> and produce a 128 bit value (pick your method of reducing it) from a 128
> bit input you will have some collisions. By the birthday paradox 1
> collision after 2^64 inputs. With a CRC for a fixed 128 bit input length
> you will never get a collision unless you reuse an input.
>
> Is this any clearer?
Sure, it's plenty clear. (It's also slightly wrong, because SHA1 produces
a 160-bit output, so collisions only occur after 2^80 hashes.)
What's not clear is why this is at all relevant to the application of
hashing entropy sources to get key material. I don't know about you,
but the number of keys _I_ have ever generated falls far short of 2^80...
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Re: Efficient algorithm to determine relative primality?
Date: 9 Jul 2000 17:04:12 GMT
John Savard <[EMAIL PROTECTED]> wrote:
> On 09 Jul 2000 01:17:46 GMT, [EMAIL PROTECTED] (ChenNelson) wrote, in
> part:
>>Would someone know an efficient algorithm for determining whether
>>numbers x and y are relatively prime, without havng to necessarily
>>calculate gcd(x,y) using Euclid's method? Calculating the gcd of two
>>numbers using Euclid's method is too slow for crypto-size (100+digits)
>>numbers. Thanks.
> Actually, Euclid's method is better than polynomial time, and you
> won't find one much faster. It would take a time proportional to the
> logarithm of the number of digits in the number if the time for
> addition and subraction were constant, and this is very good speed.
> John Savard (teneerf <-)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Using CRC's to pre-process keys
Date: 9 Jul 2000 10:07:00 -0700
In article <[EMAIL PROTECTED]>,
Mack <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (David A. Wagner) wrote:
> >That's not at all clear. Ciphers are analyzed under a model where
> >the key is chosen uniformly at random. If you take non-uniform keying
> >material and pass it directly to the cipher (without pre-hashing), the
> >security warranty has been voided, and all bets are off.
>
> An ideal cipher is not subject to related key attacks. Theoretically
> that is part of the security waranty.
Actually, the standard definitions usually do not include resistance
to related-key attacks as a requirement.
For example, the most common theoretical definition of security for a
block cipher is that it be a pseudorandom permutation. Pseudorandom
permutations need not be secure against related-key attacks, and one
can readily come up with examples that are pseudorandom permutations
but insecure against related-key cryptanalysis.
You could extend the usual definitions to include security against
related-key attacks, and this seems like a reasonable idea, but beware:
then you have to choose ciphers carefully, because a number of
otherwise-secure ciphers will become insuitable, and moreover the
related-key security of many of the remaining ciphers may not have
been studied too carefully. So be careful: this introduces an extra
failure mode which is not present if you pre-hash your key material.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Has RSADSI Lost their mind?
Date: 9 Jul 2000 17:12:02 GMT
In <395fcb6a$1$jutvvv$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
]Below is a couple of messages posted to the OpenSSL users mailing list.
]Seems someone down at RSADSI has lost it. I found the part about them
]*owning* EAY quite amusing. I wounder if anyone bothered telling him that
]he is considered owned property of RSADSI.
Uh, the orginal poster stated that his "quotes" were "paraphrases" a
rather poor technique. Thus, you cannot trust the words at all.
Note that RSA IS patented in the USA ( and USA only) by MIT (not RSADSI
although through their agreement with MIT, they are the sole licensors
of that patent). That patent expires in a couple of months, but is also
irrelevant in most of the world. However, if you use RSA, no matter who
it is written by or where it was written (eg OpenSSH or OpenSSL) then
the presumption is that you have to enter into agreement with the
licensors ( or invalidate the patent, or use it and wait for them to sue
you) or wait a couple of months.
]>From: Bill Rebey <[EMAIL PROTECTED]>
]>To: [EMAIL PROTECTED]
]>Subject: Legality - just heated up
Just heated up?? Why? This has been obvious all along!
]I just got off the phone with, among others, John Riley at RSA. He's
]claiming things like (paraphrased):
]"It's flat out illegal to use OpenSSL for Commercial purposes" "Even if
]you use OpenSSL, it still uses RSA technologies that you have to pay
]royalties for (regardless whether it uses RSA encryption or not)" "We own
]EAY, thus we own SSLeay/OpenSSL"
]He's leaning on us to pay $70K up front, plus $636 in royalty fees for
]every copy of our product that we sell!!
If you are in the USA, then you fall under US patent law. As such you
have the five choices.
a) Stop using it.
b) Enter into agreement with the licensor of the patent.
c) Wait two months.
d) Wait for them to sue you, and try to invalidate the patent.
e) Rewrite OpenSSL to use DH/ElGammel key exchange ( but ov course then
you would not be in compliance with SSL)
His royalty fees are rather steep, but I guess he is annoyed at you, and
is setting punitive fees. If this is a new product, I suspect he would be hard put
to get a court to award such damages since the patent is now essentially
worthless with only two months to run ( but I am not a lawyer and so my
opinion may bear no relation to legal fact).
]Can anyone clarify any of this for me?
]Is there another group that I should mail to that would be a more
]appropriate or authoritative audience for such legal questions?
]Thanks again,
]Bill Rebey
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Has RSADSI Lost their mind?
Date: 9 Jul 2000 17:14:29 GMT
In <fgU75.27452$[EMAIL PROTECTED]> "Lyalc" <[EMAIL PROTECTED]> writes:
>RSADSI did buy the Australian company whose key employees wrote the
>opensource SSLEAY.
So what? They cannot retroactively change the license under which the
original was distributed. And it allowed unlimited copying I believe,
and did not allow them to retroactively invalidate the license.
>The licensing issues are a different matter.
------------------------------
From: "David Hyde" <[EMAIL PROTECTED]>
Subject: Random Numbers
Date: Sun, 9 Jul 2000 18:17:16 +0100
Does anyone know how to convert a random bit stream into random 16-bit
numbers with uniform distribution?
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Using CRC's to pre-process keys
Date: Sun, 9 Jul 2000 09:59:57 -0700
Adam Durana <[EMAIL PROTECTED]> wrote in message
news:Uc0a5.2349$[EMAIL PROTECTED]...
> > I believe what he was trying to say is that if you take a SHA-1 for
> example
> > and produce a 128 bit value (pick your method of reducing it) from a 128
> > bit input you will have some collisions. By the birthday paradox 1
> > collision after 2^64 inputs. With a CRC for a fixed 128 bit input
length
> > you will never get a collision unless you reuse an input.
> >
> > Is this any clearer?
>
> Yes its clear now, but are you sure this is true about CRC? I know there
is
> quite a bit of mathematical theory behind CRC, but I was unaware that you
> were guaranteed no collisions if you used input of the same size as the
> output.
Actually, that is quite true. You can realize this from the well-known fact
that, for an N bit CRC, any nonzero change made to an area no bigger than N
bits is guarranteed to change the CRC. If you have an N bit input, *all*
nonzero changes are in an area no bigger than N bits.
--
poncho
------------------------------
From: "tok" <[EMAIL PROTECTED]>
Subject: Re: Concepts of STRONG encryption using variable base
http://www.edepot.com/phl.html
Date: Sun, 9 Jul 2000 19:21:35 +0200
> my local machine? Why do I need to use a cypherblock? Why
> not utilize webservers? Why not use multiple webservers?
> Why not utilize the whole internet as my algorithm? As you can
Oh yes, you have the divine light, you are my light master; i want to enter
in your sect, please give me your power.
I want to have the dynamic light in my face and the dynamic money of your
new algorithm in my bank
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.theory
Subject: Re: Quantum Computing (Was: Newbie question about factoring)
Date: 9 Jul 2000 17:32:32 GMT
In <8jr41b$ii6$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nick Maclaren) writes:
>In article <[EMAIL PROTECTED]>,
>Paul E. Black <[EMAIL PROTECTED]> wrote:
>>Nick Maclaren wrote:
>>> However, some people believe that building a quantum computer is
>>> an exponentially complex problem,
>>
>>Interesting. Could you give more details, for instance, who believes
>>that or what goes into it? For instance, is it that designing a
>>quantum computer is exponentially complicated, or constructing it
>>(an exponential number of steps needed)?
>It is some of my physicist colleagues. The problem is converting
>a sequence of bits (i.e. an integer) into the same number of
>predetermined simultaneous quantum states. And, of course, the
>converse. It is less than clear how to do this, or how complex a
>problem it is.
?? This makes no sense. The standard algorithms convert a set state --
all 0-- to a coherent superpostion of all of the numbers of n bits. This
is not an exponential problem-- it is linear in n.
The big problem in QC is solving the problem of decoherence -- which
destroys quantum computation. Error correction is one path,-- but it is
tough. The big problem is that QC does not scale well at all. Ie knowing
how to build two 4 bit QC does not help much in building an 8 bit one.
Each new bit is a new challenge at the present stage.
>I believe that the current state of the art is 4 bits, but the
>limit may have been pushed a bit further since I heard.
No. A 7 bit "computation" has been realised in NMR I believe, but it is
a technique which we know will not scale beyond maybe 10-20 bits ( which
would be about a 3 bit QC with error correction). A 2 or 3 bit has been
does with optical/atomic cavities. condensed matter systems
(nanotechnology) I think is around the 1 bit level.
------------------------------
From: Dennis Yelle <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 10:34:02 -0700
"Douglas A. Gwyn" wrote:
[...]
> Wouldn't it be a whole lot better to be able to write
> bit a[1024], b[1024];
> int i;
> for (i = 0; i < 1024; ++i)
> b[i] = a[1023-i]; // reverse bit order
> and get lightning-fast execution?
That is not a very good example,
because one of these will usually be faster:
unsigned char a[128], b[128];
int i;
for( i=0; i<128; ++i)
b[i] = bit_reverse_uchar[ a[127-i] ];
or
// By using only 31 bytes of the table
// we assure that it will (usually) be in the L1 cache.
// (If your cache line is longer than 16 bytes, you might
// want to adjust the masks.)
for( i=0; i<128; ++i)
b[i] = rev_uchar[ a[127-i] & 0xf] | rev_uchar[ a[127-i] & 0xf0];
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here: http://table.jps.net/~vert
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random Numbers
Date: Sun, 09 Jul 2000 10:33:37 -0700
David Hyde wrote:
> Does anyone know how to convert a random bit stream into random 16-bit
> numbers with uniform distribution?
I assume that the original random bit stream is not uniform,
or the question is trivial.
The standard procedure is to run the numbers thru a crypto
hash function like MD5 or SHA-1.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Random Numbers
Date: Sun, 9 Jul 2000 10:19:55 -0700
David Hyde <[EMAIL PROTECTED]> wrote in message
news:8kac12$nk2$[EMAIL PROTECTED]...
> Does anyone know how to convert a random bit stream into random 16-bit
> numbers with uniform distribution?
>
Umm, to generate a 16-bit number, you take the next 16 bits from the random
bit stream, and treat them as a binary 16 bit number. Assuming that the
bits from the random bit stream are independent and unbiased, the resulting
16 bit numbers will be independent and unbiased.
Why do I get the feeling I'm missing something here...
--
poncho
------------------------------
From: "tok" <[EMAIL PROTECTED]>
Subject: Re: Concepts of STRONG encryption using variable base
http://www.edepot.com/phl.html
Date: Sun, 9 Jul 2000 19:32:20 +0200
> For more information on BASE Encryption, read it up
> here http://www.edepot.com/phl.html
There is nothing !
No soft to download, nothing, only a text !!
Give us a software or a source code before !
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Using CRC's to pre-process keys
Date: 09 Jul 2000 17:40:27 GMT
>In article <[EMAIL PROTECTED]>,
>Mack <[EMAIL PROTECTED]> wrote:
>> I believe what he was trying to say is that if you take a SHA-1 for example
>> and produce a 128 bit value (pick your method of reducing it) from a 128
>> bit input you will have some collisions. By the birthday paradox 1
>> collision after 2^64 inputs. With a CRC for a fixed 128 bit input length
>> you will never get a collision unless you reuse an input.
>>
>> Is this any clearer?
>
>Sure, it's plenty clear. (It's also slightly wrong, because SHA1 produces
>a 160-bit output, so collisions only occur after 2^80 hashes.)
>
If the 160-bit hash is reduced to 128 bits (again pick your method of
reducing it) collicions occur after 2^64 inputs. When you reduce your
key to produce 128 bit output the birthday paradox applies to the
reduced value not the original value.
>What's not clear is why this is at all relevant to the application of
>hashing entropy sources to get key material. I don't know about you,
>but the number of keys _I_ have ever generated falls far short of 2^80...
>
Since the original post was about ASCII text key processing I am
not sure it is.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4 question
Date: 9 Jul 2000 17:41:44 GMT
In <8js32m$t7j$[EMAIL PROTECTED]> dexMilano <[EMAIL PROTECTED]> writes:
]A silly question.
]I've tried the implementation of RC4 you can find on the web.
]Is it correct the felling that the same sequence of bits in the same
]position, with the same key, is coded in the same way, indipendently
]form the previos bit sequences.
]I mean that, if yuo have to code gufy and pufy, the cript version shold
]be something like 1234 and 9234.
Yes, IF they are in the same postion in the stream with the same key.
That is why you MUST NEVER use the same key to encrypt two different
texts.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 20:14:22 +0200
Holger Bettag wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>
> > Skipper Smith wrote:
> >
> > > Have you looked at the AltiVec instructions contained in the MPC7400? You
> > > can download the manual from:
> > > www.mot.com/SPS/PowerPC/teksupport/teklibrary
> >
> > It would be nice, if you would give a list of instructions of that processor
> > that are particularly relevant for crypto.
> >
> "Vector permute" would be the most outstanding candidate. Together with
> "vector select" and the bitwise shifts/rotates, one can build almost arbitrary
> bit permutations.
Would you please explain a little bit these instructions and illustrate
with a tiny (reduced) example of how to effect an arbitrary permuation?
Thanks.
M. K. Shen
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: RC4 question
Date: Sun, 09 Jul 2000 14:02:33 -0400
On 9 Jul 2000 17:41:44 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>In <8js32m$t7j$[EMAIL PROTECTED]> dexMilano <[EMAIL PROTECTED]> writes:
>
>]A silly question.
>
>]I've tried the implementation of RC4 you can find on the web.
>]Is it correct the felling that the same sequence of bits in the same
>]position, with the same key, is coded in the same way, indipendently
>]form the previos bit sequences.
>
>]I mean that, if yuo have to code gufy and pufy, the cript version shold
>]be something like 1234 and 9234.
>
>Yes, IF they are in the same postion in the stream with the same key.
>That is why you MUST NEVER use the same key to encrypt two different
>texts.
This is the primary reason for the salt value, to keep the same
stream from being reused when the same password is reused.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
** 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
******************************
