Cryptography-Digest Digest #97, Volume #11 Fri, 11 Feb 00 15:13:01 EST
Contents:
Re: Compression cannot prevent plaintext recognition (was Re: is (Anton Stiglic)
Re: Twofish vs. Blowfish (John Myre)
Re: Bounding (p-1)(q-1) given only knowledge of pq (Anton Stiglic)
Re: Newbie Encrypt question (Jerry Coffin)
Re: Persistent vs Non-Per DH for Voice (Mike Rosing)
Re: Period of cycles in OFB mode (Mok-Kong Shen)
Re: Encryption protocol questions (Mike Rosing)
Re: Newbie Encrypt question (Mike Rosing)
Re: Do 3 encryptions w/ a 40-bit key = 120 bits? (Mike Rosing)
Re: Do 3 encryptions w/ a 40-bit key = 120 bits? (Jerry Coffin)
Re: Which compression is best? (Mok-Kong Shen)
BASIC Crypto Question ([EMAIL PROTECTED])
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: Using Gray Codes to help crack DES ([EMAIL PROTECTED])
Re: Twofish vs. Blowfish (Eric Lee Green)
Re: PKI's and CA's (Ralph Hilton)
Re: Twofish vs. Blowfish (Eric Lee Green)
Re: Newbie Encrypt question (Email forms are lame)
Re: UK publishes 'impossible' decryption law (David Crick)
Re: Hill Climbing (Mok-Kong Shen)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
----------------------------------------------------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Compression cannot prevent plaintext recognition (was Re: is
Date: Fri, 11 Feb 2000 12:55:31 -0500
Tim Tyler wrote:
> Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> : Wooo, this is deviating again. Let me make this as simple as possible:
>
> : E_k: encryption algorithm using a key k,
> : D_k: decryption algorithm using a key k,
> : Z: compression function,
> : U: uncompression function
> : m: a plaintext message
>
> : So, encrypting m, would be done as follows:
> : -first compress m,
> : -then encrypt the result
> : That gives E_e(Z(m)), where e is the encryption key
>
> : Now, if you are testing out a decryption key d, you do
> : y <- D_d(E_e(Z(m)))
> : Now, if you have the correct key y=Z(m), so you simply
> : unzip y , call the result x (x <- U(y)), if you have the right
> : decrypiton key, x = m. So an attacker will simply look
> : for the headers in x.
>
> What if all x (such that x = U(f) for some f) have the headers the
> attacker is looking for?
>
> I.e. what if the information about message content available to the
> analyst is the same as the information about message content which was
> available to the author of the compressor - and the latter designed a
> scheme to correctly exploit it?
Ah well that would be great! I'd want to be the first one to use it! But
this is no longer a problem about compression functions, this turns out
to be a problem of picking a function that only works on a specified subset
of a larger set, this is sounding to be more like an NP-complete problem??
Anton
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Fri, 11 Feb 2000 10:57:17 -0700
Scott Fluhrer wrote:
>
> John Myre <[EMAIL PROTECTED]> wrote in message
<snip>
> > Later in the development process, when you have an alpha or beta or
> > something that sort of works, you can replace RC6 (if necessary)
> > based on more recent information (like an AES decision).
>
> Umm, I don't know if that is legal. I believe that RC6 is patented, and
> so use of it (without RSA's permission) is illegal. If it does become the
> actual AES algorithm, then the patent issues go away, but that hasn't
> happened yet, and may never.
Why wouldn't it be legal to use during development? AFAIK, patents
are only relevant once you start to sell it (or the equivalent).
Actually I suppose that you could get the same sort of developmental
behavior by using an "encryption algorithm" that you make up yourself
and is trivial. It doesn't have to be secure; it just has to have
the right interface and scramble the data at least a little, so as
to support testing.
The important aspect I wanted to address is that allowing a change
in algorithm is useful because it allows you to postpone your
"final" choice, even if you don't anticipate allowing flexibility
in algorithm choice as one of the product requirements.
JM
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Bounding (p-1)(q-1) given only knowledge of pq
Date: Fri, 11 Feb 2000 13:03:29 -0500
So I haven't read your post completly, but
here is a quick reply:
(p-1)(q-1) will have approximatly the same
size as pq = n. So if you have, let's say,
a 1024 bit RSA modulus, (p-1)(q-1) will be
about a 1022 bit modulus. This only tells you
that p-1 and q-1 is a BN of size 1022 (there are
2^1022 of them!!!!!, not much info at all).
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 11:10:07 -0700
In article <8814vm$7lv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I've been looking into data encryption lately. I want to write my own
> simple encrypt program (C/C++). From what I understand one way to
> encrypt is to shift the underlying binary data and then Xor it with a
> password. Question I have is where the heck to you store the
> password???
>
> Example, say I encrypt a paragraph and the password I use is "mypass".
> This would be used for the xor part. Now when I send it to my friend
> and he brings up the program to de-crypt it he has to use "mypass". But
> in order for my program to verify the password is correct it would have
> to be stored in the file. That doesn't seem very safe. Any ideas?
Usually the program simply doesn't attempt to verify that his password
is correct at all -- instead, it just attempts to decrypt using
whatever password he provides, and if he uses the wrong password, all
he gets out is garbage.
I'd advise against attempting to verify the password at all, but if
you're really convinced you need to do this, there IS a way to do it
reasonably safely. You shouldn't normally plan on taking the password
a user enters and using it directly as a key for encryption. Instead,
you normally want to run the password through a cryptographic hash,
and use the output from the hash as the key.
If you want to verify a password, you can use two separate hashes: one
to produce the key, and one for verification. Store one of the hashes
in the file, and use the output from the other for the encryption
itself. When you need to verify a password, you run it through the
verification hash and compare it against the hash that's in the file.
If they don't match, the password they entered was wrong. If they do
match, it's still BARELY possible it was wrong, but not very likely.
You then hash the password with the OTHER hash, and try to decrypt the
file. If the password was correct, you'll get good output, but
otherwise you'll get garbage.
I'll note, however, that anytime you store ANYTHING that verifies
entry of the correct password, you're giving information away to an
attacker, making it easier to break your encryption. OTOH, the form
of encryption you're suggesting is so weak that this doesn't really
matter in any case -- it can be broken in a fraction of a second on a
modern computer. In fact, with my old 386/20, it still only took a
second or two to break as a general rule.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Persistent vs Non-Per DH for Voice
Date: Fri, 11 Feb 2000 12:16:12 -0600
[EMAIL PROTECTED] wrote:
>
> By session key, you mean the DH ephemeral key which in turn creates a
> session key using a symetric cipher...
The two DH keys of each side create the session key used with the
symetric cipher.
> OK...it may be more secure, but what about the setup time each time a
> call is made...and man in the middle attack...
Problems to deal with for sure!
> Is this techqnique widely used in two way real time communications?
Not widely, but it's used in some secure phones. Doing a MITM with RF
in real time is pretty hard.
> Any references to the MQV algorithm?...I cant find any papers or source
> code....if you have any URL, I would be glad to have them...thanks
Check out the P1363 web site at ieee:
http://grouper.ieee.org/groups/1363/D9.html
(send me e-mail via [EMAIL PROTECTED] and I'll send you the
username,password to get the downloads)
> Certicom?
Yup.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Date: Fri, 11 Feb 2000 19:43:18 +0100
Scott Fluhrer wrote:
>
> > > Well, one obvious approach would be to add in a step counter after every
> > > encryption step. That is, (if X(n) is the internal state at step n),
> turn:
> > >
> > > X(n+1) = Encrypt( X(n) )
> > >
> > > into
> > >
> > > X(n+1) = Encrypt( X(n) ) + n
> > >
> > > where the above + is either xor, or addition modulo the block size.
> > > Then, cycles are impossible (if X(n) = X(m) for some n!=m, then
> > > X(n+1) != X(m+1) )
> >
> > Every sequence computed in the space of the finite block size
> > cannot have a period length of infinite. So I wonder how could
> > 'cycles are impossible' be possible?
>
> Well, the OP was asking about short cycles, and I just ellipsed out
> the word short. If you are encrypting more than 2**64 blocks (with
> a 64 bit block size), then the attacker will be able to form a code
> book anyways, and so a cycle is irrelevant.
O.K. But yet this only 'formally'/'artificially' prevents cycles.
The result of addition could have (in this context unknown) undesirable
properties relative to the unmodified sequence and that should be
studied. (The sequence e.g. 0 1 2 3 ... is not periodic within the
blocksize.)
M. K. Shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Encryption protocol questions
Date: Fri, 11 Feb 2000 12:36:58 -0600
wtshaw wrote:
> If this is required by your algorithm of choice, using a different key,
> then the algorithm is deficient, especially when compared with an
> alternative that designed closer to real world needs and does not have
> that problem.
"required" is too strong. It's idilic in the sense that using a
different
key for each session makes the cryptanalyst's problem more difficult.
For
most people, it probably isn't necessary if they use something like
Blowfish.
If I was a military commander, I'd want every logged session to use a
different key. It doesn't *have* to be, but it *can* be, and that makes
things more secure.
Still doesn't stop spys :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 12:45:48 -0600
[EMAIL PROTECTED] wrote:
>
> I've been looking into data encryption lately. I want to write my own
> simple encrypt program (C/C++). From what I understand one way to
> encrypt is to shift the underlying binary data and then Xor it with a
> password. Question I have is where the heck to you store the
> password???
>
> Example, say I encrypt a paragraph and the password I use is "mypass".
> This would be used for the xor part. Now when I send it to my friend
> and he brings up the program to de-crypt it he has to use "mypass". But
> in order for my program to verify the password is correct it would have
> to be stored in the file. That doesn't seem very safe. Any ideas?
Just type it in when you start the program. You tell your friend what
the "password" is verbally, then she types it in.
While this is a good way to begin learning, it's pretty useless against
anyone older than 12. Once you get it to work, do a web search on
"block ciphers". That'll keep you busy for a while :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Do 3 encryptions w/ a 40-bit key = 120 bits?
Date: Fri, 11 Feb 2000 12:51:21 -0600
[EMAIL PROTECTED] wrote:
> Given that 40 bit encryption is considered insecure, what about the
> scenario if you take a file and use 40-bit encryption to encrypt it 3
> times, would that not give it an effective key length of 120 bits, and
> therefore be secure?
>
> Does such a scenario work? Does it really give the file an effective
> key length of 120 bits? Or is it hocus-pocus?
It'll give you 41.5 bits of security. To get 80 bits of security, you
can encrypt with k1, decrypt with k2 and encrypt again with k1 (or k3,
doesn't matter). The reason comes from the way attacks are performed,
you assume the attacker has some known plaintext-ciphertext pairs to
work from, and they can do a meet-in-the-middle attack.
Look at "Triple DES" for an example and lots of arguments of why this
is.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Do 3 encryptions w/ a 40-bit key = 120 bits?
Date: Fri, 11 Feb 2000 11:51:28 -0700
In article <8815d7$7ra$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> Hello,
>
> Given that 40 bit encryption is considered insecure, what about the
> scenario if you take a file and use 40-bit encryption to encrypt it 3
> times, would that not give it an effective key length of 120 bits, and
> therefore be secure?
Most triple encryption schemes (e.g. 3DES) only effectively double the
key size. OTOH, an 80-bit key is only RIGHT at the very edge of being
breakable at the present time -- there was a thread a while back in
which I did some extrapolation putting it at around $200 million (or
so) to exhaust an 80-bit key space in a reasonable length of time.
> Does such a scenario work? Does it really give the file an effective
> key length of 120 bits? Or is it hocus-pocus?
When done correctly, it can really work. The effective key-length is
normally double, rather than triple, that of the original.
There's one other point to keep in mind: 40-bit keys mostly become
prominent when the US had much tighter restrictions on exporting
ciphers using keys larger than that. The export restrictions have
changed so under most circumstances, you can simply replace the 40-bit
encryption with something else entirely -- normally something that's
substantially more secure.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Fri, 11 Feb 2000 20:02:57 +0100
John Chandler wrote:
>
> I just noticed a post crediting "DS" with suggesting using
> adaptive compression in _both_ directions before encrypting.
If the forward pass does a good compression job, I wonder how much
additional compression could be expected from the backward pass.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: BASIC Crypto Question
Date: Fri, 11 Feb 2000 18:51:55 GMT
Am I right to assume that Ciphers (Block and Stream Ciphers) work at the
bit level , regardless of what the data structure/format is of the
document file.
This would imply that with the same cipher (DES, IDEA, Blowfish), I can
encrypt documents, images ( .jpeg, .jif, .bmp ) , .wav files, email
attachments, word documents, .xls documents, .pdf, .ps,
.tar, .gz, .zip...whatever... is that right? The cipher only sees
bits...
So for an email text with an attachment, I would encrypt both seperately
and lump them together? or should one merge two files of diffetent
formats together in one file? .
Are there some ciphers more suited to say image and formated documents
encryption, whereas others more suited to text...Or is it all bits and
bits...nothing else to consider?
Obviously data mapping is important...so with a 32 bit colour image, one
would want to map down the pixel...so for a 54 bit block cipher that
would be two pixels...i.e. no sheet mapping across pixels....
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 20:14:06 +0100
Ian Clarke wrote:
>
> The algorithm is simple, I take the initial data, and XOR each byte with
> the previous byte (the first byte is left unchanged). This moves
> forward through the string compounding the XOR at each stage (ie. each
> byte is actually XORd with all previous bytes).
>
> The following piece of java does this: (Data is in char[] strC):
>
> for (int x=1; x<strC.length; x++)
> {
> strC[x] ^= strC[x-1];
> }
This is a form of what is in classical terminology termed auto-key
encryption. One can simply try all possible values of the first byte
to decrypt.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Using Gray Codes to help crack DES
Date: 11 Feb 2000 19:13:17 GMT
> It's not that so much as the fact that at the transition,
> some bits can be taken from the encoding of one sector and
> the other bits from the encoding of the other sector,
> without causing a "glitch" (temporary value that differs
> from both the initial and final values).
That's what I was trying to say, but brevity obscured clarity.
There's another odd algorithm that comes to mind. It's used for counting
the number of bits set to '1' in a word:
count = 0;
while(x > 0)
{ x = x & (x - 1);
count++;
}
This mixes two types of operator to get a useful result and I'm wondering
how many of these types of algorithm there are around? Are there any
books, mags, web sites etc where one can find them?
Keith
http://www.cix.co.uk/~klockstone
------------------------
'Unwise a grave for Arthur'
-- The Black Book of Carmarthen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Fri, 11 Feb 2000 12:12:36 -0700
John Myre wrote:
> I'd start with RC6 (another of the AES candidates), because it is by
> far the easiest to code, which means it is the easiest to get right.
It also contains patented algorithms. Beats me how you can patent
multiplication -- sounds to me like trying to patent lead, or some other
similar 'act of god' -- but RSA apparently believes you can if they happen to
be used within an encryption algorithm.
Don't get me wrong, I like RC6, but I don't recommend that you use it at the
moment due to the patent situation. Especially when there are explicitly free
algorithms (like TwoFish) available.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Ralph Hilton <[EMAIL PROTECTED]>
Subject: Re: PKI's and CA's
Date: Fri, 11 Feb 2000 20:06:45 +0100
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Fri, 11 Feb 2000 09:46:48 GMT, [EMAIL PROTECTED] wrote:
>I am trying to understand PKI and the role of the
>CA's, toolkits etc. Here are a few of my queries,
>can any one help?
>
>1) To have use PKI technology you need CSP's.
>Where do these come from (not who makes them). Do
>they get installed when you go to the CA?
>
>2) When logging on to send a secure message how
>can the computer verify that it is you by any
>more than a password and therefore bypass the
>main problem that "passwords are notoriously easy
>to crack".
>
>3) When a secure message is sent is everything
>verified with the CA at the time? And the
>recievers CA?
>
>4) do CA's sell the "middleware" or "toolkits" so
>the PKI may be used across applications
>
>As you can probably tell I am rather confused!
>Any help oon any of these issues or other related
>issues that you think are important would be very
>much appreciated.
>
>Thank you
>
>Philly
Well Philly - its Friday night and seeing as no one else has replied so
far you will have to suffer what I have to say.
I gather the impression that you haven't the faintest clue about what you
are talking about.
The first statement that would be useful to answer your query is about
what you want to do. Spend 10 paragraphs explaining in detail.
Tell us what sort of organization, structure etc.
One thing I can assure you of is that if you take up the private replies
of expensive solutions then you will get ripped off.
If you wander over to ftp://ftp.zedz.net/pub/replay/pub/pgp/ you might
find that all of the wonders of the world are revealed unto thee.
=====BEGIN PGP SIGNATURE=====
Version: 6.5.1ckt
Comment: Ralph Hilton http://www.fzint.org/rhilton/
Comment: Fingerprint: 8E22 FC69 3FB3 F53A 0B0D 4392 409D AE0D 1173 21D0
iQA/AwUBOKRPskCdrg0RcyHQEQLfOwCfbpwC/2finytE7WQ+fX2z9yD9TZAAn1uT
+897Gur6/8ZbUho27V1wUZMM
=BgaF
=====END PGP SIGNATURE=====
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Fri, 11 Feb 2000 12:15:41 -0700
John Myre wrote:
> Why wouldn't it be legal to use during development? AFAIK, patents
> are only relevant once you start to sell it (or the equivalent).
No. Mere possession of a patented item without a license is illegal, whether
or not you intend to sell such item. Thus not only the seller of the patented
item is at risk of being sued by the patent holder, but those who bought the
patented item may also be sued for royalties.
> The important aspect I wanted to address is that allowing a change
> in algorithm is useful because it allows you to postpone your
> "final" choice, even if you don't anticipate allowing flexibility
> in algorithm choice as one of the product requirements.
That, on the other hand, is a definitely good idea, and is what I was
attempting to say when I said "a generic AES crypto API".
-E
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Email forms are lame <[EMAIL PROTECTED]>
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 19:09:38 GMT
Hi there,
[EMAIL PROTECTED] wrote:
> I've been looking into data encryption lately. I want to write my own
> simple encrypt program (C/C++). From what I understand one way to
> encrypt is to shift the underlying binary data and then Xor it with a
> password. Question I have is where the heck to you store the
> password???
You don't necessarily have to store the password. See below.
>
>
> Example, say I encrypt a paragraph and the password I use is "mypass".
> This would be used for the xor part. Now when I send it to my friend
> and he brings up the program to de-crypt it he has to use "mypass". But
> in order for my program to verify the password is correct it would have
> to be stored in the file. That doesn't seem very safe. Any ideas?
>
There are a couple ways of proceeding. First off, let me make clear that
the
system it sounds like you are trying to implement is a 'one-time pad'.
Please
see the FAQ for details but realize the password must be truly random, must
be as long as the message itself, and must never be reused. Using this type
of encryption is not very practical, as you might have imagined.
Your encryption function should take two inputs and yield one output. It
should take the plaintext original message and the key as input and the
output should be the ciphertext. The encryption function simply performs
a bitwise xor on each bit based on the key. You will NOT store the key
anyplace, as the key really just described the OPERATION to perform
on the incoming plaintext bit. As long as your friend does the same
operation
(feeds the same key into the xor function) then he'll get the data you sent
to him.
The decryption function of course takes two inputs & one output. It takes
the ciphertext output from the encryption function and the key and produced
plaintext. Again, the key really describes the operation, ie, what to do
with
the ciphertext data to turn it back into plaintext. It doesn't need
stored. If
a bad guy tries to decode your data using the wrong key, then you're program
is just going to perform the wrong operation(bad input to the xor function)
on the ciphertext bits, which will yield total junk. Notice doing it this
way
doesn't ever say whether the output is RIGHT or WRONG, it just works
blindly on the data -- performing what you told it to perform.
The other way to proceed is to hash the password and store it at the
beginning of the ciphertext. Then you can check the hash of the entered
passphrase and compare it to the hash of the passphrase used to
encrypt the data. This will give you a correct password, incorrect password
result. Notice this isn't really insecure, because cryptographic hashes
like MD5 and SHA1 are designed to withstand being reversed.
>
> Thanks in advance
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
I hope this helps,
Keith
P.S. If you are fairly comfortable working with a compiler, then download
the bignum libraries(see FAQ), and then implement RSA as it is easy to
implement and much more practical than a OTP.
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Fri, 11 Feb 2000 19:20:11 +0000
Adam Lock wrote:
>
[snip]
> In other words, the Police cannot prove that I haven't handed over
> the keys but I can still keep my secrets safe if I want to.
Unfortunately, they don't have to prove anything. *You* have to
prove you don't have the key(s).
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| ICQ#: 46605825 PGP: RSA 0x22D5C7A9 DH-DSS 0xBE63D7C7 0x87C46DE1 |
+-------------------------------------------------------------------+
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hill Climbing
Date: Fri, 11 Feb 2000 20:25:07 +0100
Michael Darling wrote:
>
> I'm hearing a lot about hill climbing algorithms - can anyone tell me of any
> links or books which would
> tell me more about them.
The following article may be of some interest to you:
W. Millan et al., Boolean Function Design Using Hill Climbing
Methods. LNCS 1587, Springer, 1999.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: 11 Feb 2000 18:24:39 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dan O.) writes:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > Generate a permutation P on {0..255} (the "primary permutation"), and
> > a second permutation R on {0..255} (the "rotation permutation"). Form
> > the columns of square S as follows: for each column c, 0<=c<=255, c
> > is rotate(P, R[c]). For c s.t. R[c] is 0, the column will be simply
> > P; for other columns, the first entry in the column will be P[R[c]],
> > the second P[R[c]+1 (mod 256)], etc.
> What you are discribing is a permutation of a base Latin Square. Let L be
> a base latin square {ie: L(r,c) = r+c mod 256}. Let P, R, T be
> premutations on {0..255}. Then the latin square for encryption is t =
> Le(r,c) = T(L(R(r),C(c))). And the inverse function for decryption in the
> form r = Ld(t,c) = R'(L'(T'(t),C'(c)) where R', C', T' are the inverse
> permutations of R, C, T respectivly and L' is the inverse of the base
> latin square L [ie: L'(t,c) = t-c mod 256 = L(t,-c mod 256)].
Thanks. It looks like we can generate both the encoding and decoding
PRT arrays without having to actually generate the square in full at
any point, which preserves the memory-consumption advantage of this
method (which in turn makes using order-256 squares useful in memory-
constrained environments).
Further, the time to compute R', C', and T' is small (the decoder
can generate the inverses while populating the arrays - just another
indirection), and using the permutations to index (the virtual) L'
just requires an additional negation, so it looks like the decoder
won't be prohibitively slower than the encoder.
(Of course, whether this combiner is useful in cryptographic
applications is still an open question.)
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
I would never understand our engineer. But is there anything in this world
that *isn't* made out of words? -- Tawada Yoko (trans. Margaret Mitsutani)
------------------------------
** 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
******************************
