Cryptography-Digest Digest #110, Volume #12 Mon, 26 Jun 00 14:13:00 EDT
Contents:
Re: Compression and known plaintext in brute force analysis (James Felling)
Re: Idea or 3DES (Mark Wooding)
Re: Compression & Encryption in FISHYLAND (James Felling)
Re: Idea or 3DES (Simon Johnson)
Re: TEA-wmlscript question ("Douglas A. Gwyn")
Re: How Uncertain? (James Felling)
Re: How Uncertain? (Future Beacon)
Re: where start for engine computer encyrption system (Mike Rosing)
Re: Compression & Encryption in FISHYLAND (SCOTT19U.ZIP_GUY)
Re: Encryption on missing hard-drives ("CrakMan")
Re: TEA-wmlscript question (dexMilano)
TEA question (dexMilano)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis
Date: Mon, 26 Jun 2000 11:12:59 -0500
Tim Tyler wrote:
> James Felling <[EMAIL PROTECTED]> wrote:
> : Joseph Ashwood wrote:
>
> :> [...] with compression a slightly different result can occur, we can end up
> :> with a deflation down to significantly smaller sizes. A quick test with
> :> winzip on a large text file gave a size reduction of 65%, more usefully for
> :> this that means that the compression resulted in 3 bytes per byte. Moving
> :> outward this leads to 3 blocks per block, so with a (semi)known plaintext,
> :> under compression, it is entirely possible that the unicity distance could
> :> actually be reduced.
>
> : Ok, I think I see what you are claiming. That given n encrypted blocks and a
> : plaintext of known character, with compression you may actually need fewer
> : cyphertext blocks than without compression. I belive this to be a possible
> : condition to occur. OTOH I believe you are missing something here.
>
> : Given we have a plaintext P composed of blocks p(i), and after compression
> : we have a compressed plaintext C composed of blocks c(i). It may be
> : possible to recognise the code with fewer c(i)'s , however it would still
> : require more p(i) blocks.
>
> I wondered if this was what was intended.
>
> However, it still doesn't seem to make any sense.
>
> If the compressor actually compresses, then a larger proportion of
> cyphertexts will result in expansion to valid plaintexts (for any given
> length of cyphertext) - so you'll typically need a larger cyphertext (as
> well as a larger original plaintext) to reduce the number of possible
> plaintexts to 1.
I am in agreement with your position, I was just pointing out that even in the
worst case, where compression does NOT buy you a more efficient usage of space, it
may still have the effect of increasing the number of plaintext blocks required to
reach unicity.
In my opinion a good compression method can have the effect of increasing the
unicity distance in two ways. 1) by expanding the space of possible inputs to the
cypher in comparison to the raw plaintext ( won't always happen as it is possible
to have a space of possible inputs in raw plaintext that is wider than the space of
all compressed files, but is a safe bet most of the time)
and 2) as I suggest ablove, by making an equal amount of cyphertext go further in
relation to plaintext.
>
> --
> __________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Niagra falls.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Idea or 3DES
Date: 26 Jun 2000 16:24:44 GMT
Simon Johnson <[EMAIL PROTECTED]> wrote:
> It is optimized against both linear and differential cryptanalysis
> where as the original form of DES was only secure against differential
> cryptanalysis.
IDEA was designed before linear cryptanalysis was known. That IDEA is
resistant to linear cryptanalysis is useful and interesting, but doesn't
necessarily imply that this was a design decision.
> Moreover, IDEA doesn't have any steps that might be troublesome in
> software.
Actually, IDEA's multiplication mod 2^{16} + 1 is a real nuisance in
software, even though it's theoretically lovely. ;-)
> Even better, all the operations in the F-function work on 8-bit words,
What? IDEA is entirely based on 16-bit operations, not 8-bit ones. Are
you getting confused with SAFER?
> IDEA is faster than Triple-DES, DES is prehaps the securest cipher on
> the plannet, i say this because it has the weight of 30-35 years of
> analysis.
Which is pretty impressive for a cipher which was designed in the
1970s. I think you mean 25 years. ;-)
As for securest ciphers, consider BEAR or LION with a BBS and
HMAC-SHA1.
> In conclusion, though Triple-DES is old and clunky, its the best out
> there for guaranteed security. If you want a faster, robuster and
> newer algorithm, IDEA is the one to go for.
Don't forget patents: IDEA is patented.
I agree that Triple-DES is the cipher to use for maximum paranoia. I
thoroughly disagree about IDEA, though. I suspect that, had Zimmerman
not used IDEA in PGP, it would have been little more than an interesting
research toy.
If you want something strong and fast, to run on a general-purpose
computer, I think that the cipher to look at is Blowfish. In more
constrained environments, I might choose other ciphers, such as SAFER in
8-bit embedded systems. But IDEA is well down the list.
-- [mdw]
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Date: Mon, 26 Jun 2000 11:21:48 -0500
> <snip>
> .
>
> I don't follow ya. I never intended to suggest that compression
> will make it weaker, I just wanted to point out an interesting
> observation about how compression can make a cipher stronger
> (which it can't).
It CAN make a cyper stronger, but it is not guaranteed to. There are
advantages regarding Unicity distance, and also regarding the amount of
cyphertext available for analisys, but there are always cases where it
will actually make your situation worse. ( such as encrypting highly
random data -- it will probably worsen the statistacal character of your
data while actually lengthening the plaintext.
I am of the opinion that compression before encryption is almost always
a good idea, with special emphasis on the almost.
>
>
> Tom
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
------------------------------
Subject: Re: Idea or 3DES
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 26 Jun 2000 09:34:41 -0700
[EMAIL PROTECTED] (Mark Wooding) wrote:
>Simon Johnson <[EMAIL PROTECTED]> wrote:
>
>> It is optimized against both linear and differential
cryptanalysis
>> where as the original form of DES was only secure against
differential
>> cryptanalysis.
>
>IDEA was designed before linear cryptanalysis was known. That
IDEA is
>resistant to linear cryptanalysis is useful and interesting,
but doesn't
>necessarily imply that this was a design decision.
>
>> Moreover, IDEA doesn't have any steps that might be
troublesome in
>> software.
>
>Actually, IDEA's multiplication mod 2^{16} + 1 is a real
nuisance in
>software, even though it's theoretically lovely. ;-)
>
>> Even better, all the operations in the F-function work on 8-
bit words,
>
>What? IDEA is entirely based on 16-bit operations, not 8-bit
ones. Are
>you getting confused with SAFER?
Yes, Sorry :)
>
>> IDEA is faster than Triple-DES, DES is prehaps the securest
cipher on
>> the plannet, i say this because it has the weight of 30-35
years of
>> analysis.
>
>Which is pretty impressive for a cipher which was designed in
the
>1970s. I think you mean 25 years. ;-)
Sorry, again, I forgot when it was made :)
>As for securest ciphers, consider BEAR or LION with a BBS and
>HMAC-SHA1.
>
>> In conclusion, though Triple-DES is old and clunky, its the
best out
>> there for guaranteed security. If you want a faster, robuster
and
>> newer algorithm, IDEA is the one to go for.
>
>Don't forget patents: IDEA is patented.
>
>I agree that Triple-DES is the cipher to use for maximum
paranoia. I
>thoroughly disagree about IDEA, though. I suspect that, had
Zimmerman
>not used IDEA in PGP, it would have been little more than an
interesting
>research toy.
>
>If you want something strong and fast, to run on a general-
purpose
>computer, I think that the cipher to look at is Blowfish. In
more
>constrained environments, I might choose other ciphers, such as
SAFER in
>8-bit embedded systems. But IDEA is well down the list.
Oh dear, that was a bad post by me. :D
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: TEA-wmlscript question
Date: Mon, 26 Jun 2000 16:18:15 GMT
dexMilano wrote:
> So I can say that
> \phi = a/b where a/b = b/(a+b)
> and a, b and the their ratio are integer.
> ???
"???" is right -- that's incorrect. Phi is an irrational number.
+----+-------+
| | |
| | | phi
| | |
+----+-------+
1 phi
The ratio phi:(1+phi) is equal to the ratio 1:phi; that's where
the name "the golden mean" originated. Simple high-school algebra
then yields: phi^2 - phi - 1 = 0, which can be solved in various
ways, e.g. the "quadratic formula": phi = 1/2 + sqrt(1/4 + 1) =
(1 + sqrt(5))/2 which is approximately 1.618. phi's reciprocal is
exactly one less than phi (exercise: prove!), approximately 0.618.
> SO I think there are some tables anywhere.
There would not be "tables" of a single number. I am sure
that one can find phi's decimal expansion to a few dozen digits
in some table of common constants, and certainly the first
several digits of the decimal expansion of the square root of 5
may be found in some table.
> Why the number Golden number is so great?
It's not so great. However, the Pythagoreans believed that it
was the most aesthetic ratio for the sides of a rectangle, and
that was used that in much Greek art (such as the Parthenon).
In the current context, phi is a common irrational number whose
decimal or binary expansion can be readily computed, and there
is no obvious reason to expect a statistical bias in the digits
of the expansion. I personally would prefer e or pi, which are
also transcendental and thus less likely to have a simple
pattern in their digits. (All these numbers *do* exhibit a
particular pattern, in that their digits are easily computed.
Thus they are no good at all as *secret keys*.)
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Date: Mon, 26 Jun 2000 12:02:46 -0500
Future Beacon wrote:
> Tom,
>
> Thank you for trying to explain this to me:
>
> On Sun, 25 Jun 2000, tomstd wrote:
>
> > Future Beacon <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >Files A and B are composed of the least significant two bits of
> > >bytes found in news group messages (excluding headers, carriage
> > >returns, line feeds, and spaces). A and B contain one megabyte
> > >each of this data. In each case, these bits are strung together,
> > >four pairs per byte. At least three quarters of the original
> > >data available in the news group messages is not used.
> >
> >
> > Maybe you missed a very important point. ASCII DATA IS NOT
> > RANDOM!!!
> >
> > There will be strong biases from ANY bit you take from ascii
> > characters...
>
> I don't understand it. ASCII is a seven bit code communicated in
> bytes. About a quarter of the text characters end with each of 00,
> 01, 10, and 11. The bias due to which letter is likely to follow
> which other letter is somewhat diminished by ignoring all of the
> byte except the last two bits. The question is not whether file
> A or file B is perfectly random. Here is the most important of the
> two questions I asked:
Here is the problem. Given that this is english text it will suffer a
bias as the characters in english are NOT randomly distributed.
Example.( this is not the actual case, but I am simply creating it for
the sake of argument. The actual case is distributed as badly as my
example, just not in the same way I have given) assume the text is 30%
00, 30%01, 25% 10, and 15% 11) then your method will generate out put
that is 26.5 % 00, 25.5 % 01, 24% 10, and 24% 11. This is an easily
exploitable level of bias for an atttack, and in actuality there will be
associative attacks that will make it even worse ( they exploit the fact
that englidg bigrams ands trigrams are not evenly distributed -- one
should be able to make a pretty good guesss that if this pair is a 00,
then the next bit is likely to be 00 as well or something like that.
>
>
> Can anybody characterize the degree of orderliness or predictability
> of RAND (without knowing A or B)?
>
> If it is perfectly orderly (can be described by some formula or
> program) I would be amazed, but need it explained further. I don't
> just "see" that the extracted data is not at all unpredictable.
>
> To XOR the data with a message still seems make the reading of the
> message difficult. Can anybody suggest a method of attack?
Drag cribs and choose likely looking keys based upon this. One could
probably run a correlative attack on the PRNG. I will admit that this
will be neither quick nor infalible, but it will be acomplished with
reasonable ease by machine. My bet is that this method will have about
3-4 bits of randomness per byte, and while this is better than XORING
plaintext with a fixed plaintext key ala cesar, it is not a substantial
improvement.
>
>
> Here is the rest of the setting (original message):
>
> File B is divided into two files (BP and BQ) this way: If the
> first bit in A is a 0, then the first bit in B becomes the first bit
> in BP. If the first bit in A is a 1, the first bit in B becomes the
> first bit in BQ. In this way, each next bit in A determines whether
> the next bit in B becomes the next bit in BP or BQ. When the bits
> of A and B are exhausted, BQ is appended to BP and the resultant
> file is called RAND.
>
> Two people wishing to send and receive encrypted messages use the
> one-time-pad method but instead of using a random number generator
> to create their shared random numbers, they use the file called
> RAND.
>
> Nobody except these two people know how the news group messages are
> selected and all of the files are kept secret. Does anybody know
> how to attack the encrypted messages? Can anybody characterize the
> degree of orderliness or predictability of RAND (without knowing A
> or B)?
>
> Thank you for your help.
>
> Jim Trek
> Future Beacon Technology
> http://eznet.net/~progress
> [EMAIL PROTECTED]
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Date: Mon, 26 Jun 2000 13:17:28 -0400
James,
Thank you for this very helpful response.
Jim Trek
[EMAIL PROTECTED]
On Mon, 26 Jun 2000, James Felling wrote:
>
>
> Future Beacon wrote:
>
> > Tom,
> >
> > Thank you for trying to explain this to me:
> >
> > On Sun, 25 Jun 2000, tomstd wrote:
> >
> > > Future Beacon <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >Files A and B are composed of the least significant two bits of
> > > >bytes found in news group messages (excluding headers, carriage
> > > >returns, line feeds, and spaces). A and B contain one megabyte
> > > >each of this data. In each case, these bits are strung together,
> > > >four pairs per byte. At least three quarters of the original
> > > >data available in the news group messages is not used.
> > >
> > >
> > > Maybe you missed a very important point. ASCII DATA IS NOT
> > > RANDOM!!!
> > >
> > > There will be strong biases from ANY bit you take from ascii
> > > characters...
> >
> > I don't understand it. ASCII is a seven bit code communicated in
> > bytes. About a quarter of the text characters end with each of 00,
> > 01, 10, and 11. The bias due to which letter is likely to follow
> > which other letter is somewhat diminished by ignoring all of the
> > byte except the last two bits. The question is not whether file
> > A or file B is perfectly random. Here is the most important of the
> > two questions I asked:
>
> Here is the problem. Given that this is english text it will suffer a
> bias as the characters in english are NOT randomly distributed.
>
> Example.( this is not the actual case, but I am simply creating it for
> the sake of argument. The actual case is distributed as badly as my
> example, just not in the same way I have given) assume the text is 30%
> 00, 30%01, 25% 10, and 15% 11) then your method will generate out put
> that is 26.5 % 00, 25.5 % 01, 24% 10, and 24% 11. This is an easily
> exploitable level of bias for an atttack, and in actuality there will be
> associative attacks that will make it even worse ( they exploit the fact
> that englidg bigrams ands trigrams are not evenly distributed -- one
> should be able to make a pretty good guesss that if this pair is a 00,
> then the next bit is likely to be 00 as well or something like that.
>
> >
> >
> > Can anybody characterize the degree of orderliness or predictability
> > of RAND (without knowing A or B)?
> >
> > If it is perfectly orderly (can be described by some formula or
> > program) I would be amazed, but need it explained further. I don't
> > just "see" that the extracted data is not at all unpredictable.
> >
> > To XOR the data with a message still seems make the reading of the
> > message difficult. Can anybody suggest a method of attack?
>
> Drag cribs and choose likely looking keys based upon this. One could
> probably run a correlative attack on the PRNG. I will admit that this
> will be neither quick nor infalible, but it will be acomplished with
> reasonable ease by machine. My bet is that this method will have about
> 3-4 bits of randomness per byte, and while this is better than XORING
> plaintext with a fixed plaintext key ala cesar, it is not a substantial
> improvement.
>
> >
> >
> > Here is the rest of the setting (original message):
> >
> > File B is divided into two files (BP and BQ) this way: If the
> > first bit in A is a 0, then the first bit in B becomes the first bit
> > in BP. If the first bit in A is a 1, the first bit in B becomes the
> > first bit in BQ. In this way, each next bit in A determines whether
> > the next bit in B becomes the next bit in BP or BQ. When the bits
> > of A and B are exhausted, BQ is appended to BP and the resultant
> > file is called RAND.
> >
> > Two people wishing to send and receive encrypted messages use the
> > one-time-pad method but instead of using a random number generator
> > to create their shared random numbers, they use the file called
> > RAND.
> >
> > Nobody except these two people know how the news group messages are
> > selected and all of the files are kept secret. Does anybody know
> > how to attack the encrypted messages? Can anybody characterize the
> > degree of orderliness or predictability of RAND (without knowing A
> > or B)?
> >
> > Thank you for your help.
> >
> > Jim Trek
> > Future Beacon Technology
> > http://eznet.net/~progress
> > [EMAIL PROTECTED]
>
>
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: where start for engine computer encyrption system
Date: Mon, 26 Jun 2000 12:13:10 -0500
[EMAIL PROTECTED] wrote:
>
> I want to take in data off of my car's engine computer, encrypt it,
> store it and only allow me and a "GM" mechanic to get the information
> off. I think they should all be able to get the information without
> each others permissions. Where should I start looking to design such a
> system? What sort of pieces do I need? What can I buy that would fit
> into this puzzle?
But anyone can read out the information. Unless you reprogram the car's
processor to spit out encrypted data, and you give the key to the
encryptor to whoever you want to be able to read it.
>
> I think I would need some sort of device to get the data from the
> engine computer (I have that) and then another device to encrypt it. I
> would have to already have PKI system in place? Please let me know
> what/where I should be looking.
Anyone can get the raw data! If all you want to do is transmit the
data, you can use a portable to get the data from the engine computer,
encrypt with a standard program like PGP, and send it to whoever you
want via the internal modem. That's plenty secure assuming you don't
let anyone else near your car.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression & Encryption in FISHYLAND
Date: 26 Jun 2000 17:22:39 GMT
[EMAIL PROTECTED] (James Felling) wrote in
<[EMAIL PROTECTED]>:
>> <snip>
>
>> .
>>
>> I don't follow ya. I never intended to suggest that compression
>> will make it weaker, I just wanted to point out an interesting
>> observation about how compression can make a cipher stronger
>> (which it can't).
>
>It CAN make a cyper stronger, but it is not guaranteed to. There are
>advantages regarding Unicity distance, and also regarding the amount of
>cyphertext available for analisys, but there are always cases where it
>will actually make your situation worse. ( such as encrypting highly
>random data -- it will probably worsen the statistacal character of your
>data while actually lengthening the plaintext.
>
>I am of the opinion that compression before encryption is almost always
>a good idea, with special emphasis on the almost.
>
I my be wrong but it seems your position is starting to crack.
I will go to say that most compression methods in use may be of
help to the attacker. The main reason is that they gave the attacker
a black and white anwser as to weather or not the guessed key leads
to a possible solution. Do to the fact most random files will not
decompress and then compress back to the stated random file. By using
most compression schemese you give the attacker who may know nothing
about the message being sent a way to eliminate most files immediatly
without having to check if the guessed file is a valid file for some
word video or audio application. If one chooses a bijective or (1-1)
compressor this problem does not exist. In the compression methods
that have been modifed to make them bisjective namely the huffman rle
and arithmetic they also compress better after the methods were modifed
to make them bijective. There is no reason to belive this effect would
not occur in other compression methods. It is just that people don't
give it much thought yet. The NSA and phony crypto gods have let people
but these improvements on the back burner for obvious reasons.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction
of the truth."
------------------------------
From: "CrakMan" <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: Mon, 26 Jun 2000 10:45:27 -0700
Absolutely correct.
For a really entertaining exposition of this attitude I highly recommend
reading a book called "Surely You're Joking Mr. Feynman" by the eponymous
author.
If you have ever worked with worked in a highly secure environment, you will
find this one to be a real knee slapper. It relates various stories of the
Nobel prize winner's encounters with the dark forces of security and other
hilarious events including Feynman's antics while breaking the combination
locks on safes holding classified information. In one episode, Feynman
breaks into a super secret vault and leaves notes to the security people
proving that he gained access in spite of their best efforts to keep him
out.
A warning...if you start reading this book, you won't put it down until
every last page has been savored. :--))
The attitude expressed in this book is the nightmare scenario for anyone
charged with maintaining a secure environment.
John E. Kuslich http://www.crak.com
Guy Macon <[EMAIL PROTECTED]> wrote in message
news:8isuvh$[EMAIL PROTECTED]...
> Mok-Kong Shen wrote:
> >
> >[EMAIL PROTECTED] wrote:
> >
> >> ABC news reported today that "[Bill] Richardson said he has changed
> >> the procedure which now requires information such as the data on the
> >> hard drives to be encrypted" which strongly implies that it
> >> wasn't. Really though, no amount of encryption is going to help in the
> >> face of abysmal physical security. Twenty six people were allowed
> >> unescorted access to the vault, and could remove items without signing
> >> for them. On top of that, the last inventory was for the y2k
> >> inspection.
> >
> >Judged with commonsense, one can conclude that the materials involved
> >(despite the official claims) could not be very critical. I base my
> >conjecture
> >on a case I know: In the seventies a friend developed a program for a
> >certain hightech firm. The program was on a magnetic tape and kept in a
> >vault. Each time when the program got run, the tape was taken from the
> >vault to the computing centre and put back after the run, always under
> >the supervision/protection of an armed guard. Even years after leaving
> >the firm, he was requested to provide informations about the names of
> >countries he visited during vacations. So it seems unbelievable that the
> >present hard-drive could contain materials that are really any precious.
> >
> >M. K. Shen
> >
>
> You are missing the cultural differences. These aren't employees of a
> high tech firm. Thjese are scientists with a core belief that keeping
> secrets is silly, futile, moronic, and a big game that they win whenever
> they circumvent the military security procedures.
>
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: Re: TEA-wmlscript question
Date: Mon, 26 Jun 2000 15:45:00 GMT
Yes the number is little enough (at start of the algorithm),
unfortunately I've a 32 cicle and it groes too much.
Other ways to reduce it?
thx
dex
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> dexMilano wrote:
> > I've tried to implement TEA in wmlscript but I've found some
problem to
> > assign the Golden number delta (= 0x9e3779b9).
> > In the wmlscript we have (signed) int a 32 bit so the range arrive
to
> > 7fffffff.
>
> WMLScript specifies twos-complement arithmetic, so you can just use
> signed variables as if they were unsigned. (Note that addition,
> subtraction, multiplication and xor are the same for signed twos-
> complement arithmetic as for unsigned arithmetic, when viewed as
> operations on bit patterns. If you can find an implementation of
> TEA in Java, it will probably use this technique.)
>
> > The question is: Is there a way to create a golden number minor than
> > 7fffffff?
>
> Use 0x9E3779B9 - 0x100000000 = -0x61C88647 (but if you're not familiar
> with twos-complement arithmetic, look it up and make sure you
understand
> why this works).
>
> - --
> David Hopwood <[EMAIL PROTECTED]>
> PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
> RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66
15 01
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBOVQoVzkCAxeYt5gVAQGiOwgAvsTp+lYNE2LSfUchKheXdlWJM2fQu6uP
> dazIe4mveJchjjT0g/svrR7CX1YDNL8/ttrQRDj0nk/MZwSiMjDqW75FG5Hvq3hT
> nZmmZsODzgt2FGl1FNXfzpYxtADtPQt+Go+L9PZ7PWyKCHHXNPWXDAssvQoGt+Iq
> 5X49BX0wAEbLhAxvELAQFDDag0Uyoqljh9681VGn7x8Jhb/wN8C43BXHrZ8dVx0N
> GDPkXKidaOPI3oM+AP7YZBofdN3c2vbohHoouwmy/jdJ9nXme9Ghedr7M429U//P
> W5ZV0TlYqNd9aIcOkYtfON8/7TUXnajUeyU3+zQZ+0mOr+pS/b/dCA==
> =kPfU
> -----END PGP SIGNATURE-----
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: dexMilano <[EMAIL PROTECTED]>
Subject: TEA question
Date: Mon, 26 Jun 2000 16:42:16 GMT
Why we have to use the golden number ...
Why cannot we use 1569234 for example?
thx
dex
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
