Cryptography-Digest Digest #335, Volume #12 Wed, 2 Aug 00 04:13:01 EDT
Contents:
Re: Hash function? (tweaked) (Boris Kazak)
Re: Plausible Word Generation via Trigram Statistics (Kurt Shoens)
MD5 algorithym as a VBA module (Simon Mainey)
Re: Sending Messages in Morse Code (John Savard)
Re: Sending Messages in Morse Code (John Savard)
Re: Small block ciphers (Mack)
Re: Small block ciphers (Mack)
Re: Stream Ciphers (John Savard)
Re: Stream Ciphers (Runu Knips)
Re: Blowfish Implementation (Runu Knips)
Re: Skipjack (Tim Tyler)
Re: RC5 / 4 (rlogin)
Re: RC5 / 4 (rlogin)
Re: Small block ciphers (Mack)
Re: Elliptic Curves encryption (Roger Schlafly)
Re: Small block ciphers (Mack)
----------------------------------------------------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hash function? (tweaked)
Date: Wed, 02 Aug 2000 05:40:57 GMT
Francois Grieu wrote:
>
> Boris Kazak <[EMAIL PROTECTED]> proposed
> Karagash, a simple hash function.
>
> In the reference implementation, the function accepts a message
> containing an arbitrary number of 8 bit bytes, and outputs a 16 bytes
> result. An additional input key of up to 16 bytes is optional.
>
> Negative comments:
>
> 1) the design goals are not given; in particular it is unclear if the
> function is designed to be an unkeyed hash function like MD5 or SHA1
> are, or a keyed hash like MAA or ISO-9797 are. The former are usefull as
> message digest as part of electronic signature schemes, while the later
> are providing message authentification between parties sharing a secret
> key.
> 1a) in the unkeyed hash hypothesis, is the goal to prevent the attacker
> from making two messages with the same hash, or from making a message
> with a choosen hash ?
======================
Merci, Francois,
I shall think about your comments, probably it will take me 2-3 days to
compose a detailed answer. Just rapidly some points:
Length of hash is not restricted to 16 bytes, it can be #defined with
HASHSIZE constant. So one of design goals was to make the hash function
scalable. (if you need a 208-bit hash, here it is...)
The name SEED comes from a couple of ciphers where I used the modular
multiplication (mod 2^32-1) and (mod 2^32+1). Subkeys there were set up
as powers of a number called SEED.
The test file that I used for debugging of the program, happened to be
45 bytes long. This has no connection with the program, so if there is
somewhere in the program this debugging leftover, please disregard it.
Actually any 16-bit constant with the higher bit set and with Hamming
weight close to 0.5 should be acceptable as SEED. It should assure
good mixing of bits from 2 multipliers, so the number of 1-s and 0-s
in this constant should be approximately equal. In our time, when so
many
people suspect the backdoors in ciphers and hash functions, using the
first 4 hex digits of a mathematical constant dispels the fears.
Best wishes Boris Kazak
=================
>
> Breaking the thing (in the various possible meanings) is an interesting
> cryptanalysis exercise for the group.
>
> Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (Kurt Shoens)
Subject: Re: Plausible Word Generation via Trigram Statistics
Date: 1 Aug 2000 22:40:51 -0700
I wrote such a program to generate random words from trigram statistics.
I train the thing with a dictionary of words and it spits out random
words for you. Here's an example of what they look like:
election iniopsitism communiform savskillar yorrating destaffoot epidotion
ratogenous easligory alystely arelaughhea asculpator antarenesis pomologic
Most of the words it creates can be pronounced.
For fun, I also trained it with the name of high tech companies from
the NASDAQ stock exchange. There aren't as many examples to train from,
so the generated statistics are thin. Examples of what it generates are:
speedusa affinited isocortec rediacread adflexiinter invistargen
sagensorb tradiohm sunriserv telekabel tripointer metrimagine genersal
Consultants who make up successful names charge high prices. I wonder
if they use such foolishness to generate ideas.
Anyway, it's fun.
------------------------------
From: [EMAIL PROTECTED] (Simon Mainey)
Subject: MD5 algorithym as a VBA module
Reply-To: [EMAIL PROTECTED]
Date: Wed, 02 Aug 2000 06:04:15 GMT
Hi All
I have the C source (or is it an example) of MD5. I also have the
RFC1321, which explains the methodology/steps and I have a java
source/example from a web site.
http://bbs.cruzio.com/~schlafly/md5.htm
http://www.w3.org/Library/src/HTDigest.html
ftp://ftp.nue.et-inf.uni-siegen.de/pub/SECURITY/rfc/rfc1321.txt
I'm know next to nothing about encryption <g> .. but all I want to
know is .. has someone got this same source in VBA ? I'm not lazy, and
given some time can code one up, its just that I'm in a bit of a hurry
and would hate to "re-invent" the wheel (vba) when its already been
done.
Thankies
Aequi
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Date: Wed, 02 Aug 2000 06:18:38 GMT
On Tue, 01 Aug 2000 22:18:42 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Do I understand correctly that you want to transform a random bit
>sequence (almost uniformy distributed) into a sequence of Morse
>code symbols and study the optimal transformation?
I'm assuming I have a bit sequence that is precisely uniformly
distributed, and my goal is to find the optimal transformation of that
sequence - within limits to the complexity of the transformation used
- into Morse code.
>I admit that
>I haven't fully understood your article, hence the question: Do
>you keep the set of the original Morse code symbols or do you
>consider possible extensions, i.e. introducing more symbols?
I do keep the original Morse code symbols. I note that if I introduced
more symbols, even symbols from the original Morse code, such as those
for digits, this would result in changes to the transformation.
Normally, in constructing a Huffman code for the English alphabet, for
example, one has probabilities for symbols, and then uses those
probabilities to construct symbols. Supposing one already has a fixed
set of symbols of different lengths: can one go in reverse, and
determine how to use those symbols optimally?
That is the question I address, and I find that I have to determine
the potential efficiency of a code using those symbols before I can
compute the probability for each symbol that would make the code
optimal. This requires solving a fancy polynomial equation. And this
also means I have to take into account per-symbol overhead (as opposed
to per-bandwidth-unit or per-bit overhead, which being constant can be
ignored). Then I can construct a Huffman code based on those
probabilities normally, although I am using it in reverse to express
an input in bits as an output in symbols of differing probability.
I just don't remember seeing this kind of thing done before, and so it
seems an illustration of the math involved in finding optimal codes of
a different kind.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Date: Wed, 02 Aug 2000 06:21:11 GMT
On Tue, 01 Aug 2000 19:10:00 GMT, [EMAIL PROTECTED] (JimD)
wrote, in part:
>I'm not qualified to comment on its security.
Except for that which may be conferred by obscurity, it has none. It's
just a way to take something that has already been securely encrypted
in the binary domain, and convert it into letters which, instead of
being uniformly distributed, are distributed in such a way to minimize
bandwidth requirements for transmitting the bits by Morse code.
It's present to illustrate an unconventional way of applying the
theory behind optimal coding.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 02 Aug 2000 06:23:56 GMT
>Mack <[EMAIL PROTECTED]> wrote:
>> Has the field of building small block ciphers
>> been neglected?
>
>No. There is a _ton_ of cryptographic literature on S-box design.
>
>(I take it you are intending these things for use as internal components
>of a cipher, in which case they are more properly called S-boxes.
>The word "block cipher" is probably best reserved for the externally
>visible functionality, not the internal invisible components.)
>
>
No I am not talking about s-boxes. I am talking
about small block ciphers. s-boxes fall into two
categories static and dynamic (key dependent).
The dynamic version certainly fills the bill as
a cipher. The static version does not.
If you could point me to some good literature on
fast 'secure' dynamic s-box design that might prove
useful. By secure I mean no attack better than
brute force or dictionary attack.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 02 Aug 2000 06:29:59 GMT
>Mack <[EMAIL PROTECTED]> wrote:
>> Studying such structures would seem to benefit
>> future designs.
>
>If you were planning to study S-box design, the first question to ask
>yourself is: What are the relevant metrics?
>
>Note that this question will not have a universal answer; it will depend
>on how you want to use the S-box, and often on the specific cipher design
>you will be using it in. Blindly using S-boxes designed for use in one
>algorithm elsewhere may lead to bad results.
>
>In other words, there is no "a priori" correct set of metrics to choose.
>You must first study how you are going to use the S-boxes, identify a set
>of metrics, and justify them in the setting of your application. Then,
>you can talk about how to build S-boxes that optimize those metrics.
>
>
Certainly s-box design is part of a block cipher. The overall structure
is also important. Once again pointing to the attack on skipjack using
impossible differentials. In that attack the design of the s-box was
not relevant. The attack would work with any s-box as it was dependent
on the overall structure of the cipher.
The method they describe of reducing ciphers to a smaller size and
then finding the differentials and final expanding the cipher back to
full size certainly indicates that studying small block ciphers may
have substatial benefits.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Stream Ciphers
Date: Wed, 02 Aug 2000 06:26:22 GMT
On Tue, 01 Aug 2000 10:42:43 -0700, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote, in part:
>Why do you need a "free" stream cipher?
>What do you plan to use it for or do with it?
>You can have a shareware copy of OAP-L3: Original Absolute
>Privacy - Level3 encryption software package.
Obviously, perverse thing that she is, she wants to write her own
encryption program. I suppose it is sad that the existence of OAP-L3
hasn't caused the world to stop trying to devise other methods of
encryption, now that perfection has been achieved, but I would not say
that it is surprising: particularly as the "experts" have not yet been
won over to its merits.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
Date: Wed, 02 Aug 2000 08:27:52 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers
Benjamin Goldberg wrote:
> I would be interested in knowing how you can get a *secure* stream
> cipher with just 64 bits of state.
I would be interested in knowing how you could get the impression
that I said 64 bits are secure.
------------------------------
Date: Wed, 02 Aug 2000 08:36:46 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Daniel Leonard wrote:
>
> On Tue, 1 Aug 2000, John Myre wrote:
>
> > Joseph Ashwood wrote:
> > <snip>
> > > Just tell the computer that it's a pointer to a different type, in this case
> > > long instead of char.
> >
> > Ah, gee. Are you seriously intending to promulgate this practice
> > to programmers who plainly don't know any better? Or is this a
> > joke, and my sense of humor has malfunctioned? Not every computer
> > is an Intel x86.
> >
> > JM
> >
>
> That is why he said as introduction (not exact quote) :
>
> if you do not worry about endianness
It is NOT the endianess that is the problem, it is the alignment. You
get
SIGBUS signals if you try to read unaligned integer data on other
machines than the x86 (or some other old CISC machine such as the m68k).
Many systems catch SIGBUS by themself (such as OSF1), but they print
ugly warnings on the console and its of course very inefficient.
Too, if you cast to long, you get a pointer to 64 bit numbers on modern
64 architectures (such as the alpha processor). So better use some
typedef for 32 bit types.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Skipjack
Reply-To: [EMAIL PROTECTED]
Date: Wed, 2 Aug 2000 06:58:19 GMT
David A. Wagner <[EMAIL PROTECTED]> wrote:
: Has anyone looked at the 256-element Skipjack S-box to see if it can
: be expressed with less memory?
Less that 256 bytes? It's quite likely it can. Since it's a permutation,
it can be described as the nth permutation (of some permutation ordering
scheme). If you're working in an appropriate descriptive language, it
seems quite possible such a description could be smaller than 2048 bits.
Of course, even if true, this is not of much practical use ;-)
: For instance, is there any chance it is itself expressable as a
: 4-round Feistel network with some choice of 4-bit S-boxes?
4 rounds? Reducing the storage space from 256 bytes to 32 (if the boxes
are 4x4)? Even if some additional round constants and the like are used,
it seems likely that this would represent a severe weakening compared to
the equivalent random table, on non-linearity grounds alone. It would be
pretty suprising if such a representation were located.
: Does anyone know of any way to determine whether such
: a representation exists, for this size table?
I would have thought that looking for weaknesses inevitably present in a
4 round Feistel network using 4x4 s-boxes would be sufficient to rule out
this possibility. That should work in this instance - though it won't
provide a general method of answering this question. If more rounds are
allowed, the question becomes harder. Of course, you'll know much more
about all this than me...
: Apart from a factual issue about Skipjack, it seems to be an interesting
: theoretical question about whether it is possible to build a cipher
: with a S-box which has a small representation that can be kept secret
: from even a somewhat determined adversary. [...]
Yes, a wonderful question. It seems likely to me that the answer is yes.
However the issue of how to design such a cypher is probably a tricky one.
Factorising [sic] a table-based cypher into the Feistel network used
to construct it is no-doubt a non-trivial exercise, and it seems
unlikely that the best ways of doing it are all currently known.
AFAIK, Skipjack was intended to be used primarily in public places -
and while the algorithm was secret reverse engineering was a possibility
that could not have been neglected.
If there's a slimmer version for clandestine use, that probably represents
a stupid design decision - probably weakening the algorithm for no good
reason, since the thin version can't ever make it into the shops.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Niagra falls.
------------------------------
From: [EMAIL PROTECTED] (rlogin)
Subject: Re: RC5 / 4
Date: Wed, 02 Aug 2000 08:31:54 GMT
Thanks :)
On Tue, 01 Aug 2000 09:09:01 -0700, tomstd
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (rlogin) wrote:
>>1. I'm looking for the source code of RC5 or RC4.
>>2. What is the best stream cipher, and where can I get its
>source
>>code?
>
>You can find code for that on a few FTPs listed at
>counterpane.com. Also RC5 is patented in the states.... RC4 is
>an ok stream cipher... some security related iffies...
>
>Tom
>
>
>
>-----------------------------------------------------------
>
>Got questions? Get answers over the phone at Keen.com.
>Up to 100 minutes free!
>http://www.keen.com
>
------------------------------
From: [EMAIL PROTECTED] (rlogin)
Subject: Re: RC5 / 4
Date: Wed, 02 Aug 2000 08:37:52 GMT
This address is wrong, can you please give me the correct address ?
On Tue, 01 Aug 2000 09:09:01 -0700, tomstd
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (rlogin) wrote:
>>1. I'm looking for the source code of RC5 or RC4.
>>2. What is the best stream cipher, and where can I get its
>source
>>code?
>
>You can find code for that on a few FTPs listed at
>counterpane.com. Also RC5 is patented in the states.... RC4 is
>an ok stream cipher... some security related iffies...
>
>Tom
>
>
>
>-----------------------------------------------------------
>
>Got questions? Get answers over the phone at Keen.com.
>Up to 100 minutes free!
>http://www.keen.com
>
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 02 Aug 2000 07:39:02 GMT
>Mack wrote:
>
>> >Mack wrote:
>> >>
>> >> ****************
>> >> My current interest is in block ciphers. I am not sure
>> >> what relevance the security of stream ciphers has in this.
>> >> Certainly adding state increases security, however doing so
>> >> it is no longer a block cipher.
>> >>
>> >> Mack
>> >> Remove njunk123 from name to reply by e-mail
>> >--------------------------
>> > But you can regard propagating state as a kind of block
>> >chaining mode. Otherwise, in your presentation, the only legitimate
>> >chaining mode is ECB.
>> >
>> >Best wishes BNK
>> >
>> >
>>
>> For what I am currently working on ECB is the only
>> legitimate chaining mode. All other modes contain
>> state which doesn't work with the representations
>> I am using. Specifically the block size
>> is no longer a constant.
>
>Would you care to define your use of the term "block size"? It's usually
>independent of internal state.
>
Since this has gotten way out of the context which it refers maybe
we should restate that. The original topic was block ciphers
with a small block size. Someone made various statements about
stream ciphers which don't seem relevant. (the ciphers not the statements).
Anyway, BNK posted about chaining modes. For my purposes the
the cipher should have state. The only way to get this to work for
chaining modes is to assume that the whole enciphered text is
a block with variable block size. But this doesn't really work either.
>>
>>
>> Obviously proving a cipher is insecure in ECB mode
>> casts serious doubt on its use in chaining modes.
>
>How did you reach this conclusion? More terminology skew?
>
Lets take some of the chaining modes and examine each one
Lets assume that the IV and the key are both
immune to influence by an attacker.
OFB. take a block cipher and make a stream cipher.
Since the output of previous bits gives the plaintext
used to generate new bits, if the cipher is insecure
then we can predict new output bits. The attack on
the cipher must be possible with known plaintext.
The attacker cannot influence the input to the cipher.
CFB. the ciphertext is xored with the plaintext stream and
then fed back as in the OFB mode. It may allow an attacker to
influence the input plaintext of the cipher allowing an adaptive
chosen plaintext attack.
CBC. the ciphertext is xored with the plaintext and then
the plaintext/ciphertext block is encrypted. This mode
differs from OFB and CFB in that it requires support for
both encryption and decryption. This mode also allows
an adaptive chosen plaintext attack.
All of these modes are relatively simple to implement.
OFB and CFB require unique IVs. The CBC mode is
as secure as ECB for the first block with a known IV.
They require more work on the part of the attacker.
OFB mode requires a starting point in the stream where
sufficient known plaintext can be inserted before the data
that is desired. And an attack that works for known plaintext.
The same is true for CFB. But we can alter the plaintext
to provide an adaptive chosen plaintext attack.
CBC is often used in a block like manner. For example
in disk encryption. the IV is some counter encrypted
with a key. Then each block is encrypted with CBC
using its unique IV. This tends to make attacks much
harder.
It is possible to move a block cipher into a structure
such as Rerry Ritters balanced block mixing that make
attacks even harder.
At least for these chaining modes (OFB, CFB, and CBC)
but not nessecarily for all possible chaining modes, I would
prefer a cipher that has not been 'broken'. Naturally each person
has his own threat model. Most people are only worried
about unsophisticated attack. ie. nosy spouse/sibling/visitor.
Others (NSA, CIA, etc) expect billions of dollars and thousands
of man-hours, along with those nasty related key and adaptive
chosen plaintext attacks to be spent/used cracking their ciphers.
As some one once said 'You pick your threat models and
you take your chances'
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curves encryption
Date: Wed, 02 Aug 2000 00:40:17 -0700
"Trevor L. Jackson, III" wrote:
> There appears to be a difference between domains that permit experimental
> XpXrXoXoXfX confirmation and those that do not. Sciences do this. Is it your
> position that crypto supports experimental confirmation of strength?
You are zeroing in on the difference between mathematics and
the sciences. You can approach crypto from either view. Both
views have merit. But keep in mind that there is a huge difference
between these statements:
(1) Crypto protocol X has been proven secure.
(2) Experimental evidence indicates that X is secure.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Small block ciphers
Date: 02 Aug 2000 08:09:39 GMT
>
>
>Mack wrote:
>
>> Let see an actual example.
>> This is rather long and uses ANF.
>> It is rather simple but it shows the principle.
>>
>> This can be expanded to any number of bits T.
>> B = bits of block size
>> K = bits of key size.
>> T = B + K
>>
>> The number of terms is equal to 2^T.
>> The number of equations is B
>> Obviously this is impractical for large T.
>
>Isn't it that one can have B equations where on the left sides one
>has the known values of the output bits , while on the left side one
>has functions involving the K unknown values of the key bits and the
>B known values of the input bits? If yes, then we have B equations
>and K unknowns. Or I am missing something here?
For the most part that is it. But the B equations have K unknowns
with lots of nonlinear terms. But at some point you have T unknowns.
Ie. before you have known values. Basically you have to develop
the representation in T unknowns.
>
>> It also illustrates how a non-linear term can
>> be assumed to be a variable. It shows
>> how some pairs are better than others.
>
>The point is whether, on introducing a non-linear term as a
>variable, one takes away a previously existing (simple) variable,
>or one has the non-linear term as an 'additional' (new) variable.
>This is essential, since, if I don't err, your argument of imfeasibility
>has to do with the count of number of variables with respect to
>the number of equations. To use an analogous case, the equation
>x^2+x+1=0 is normally considered to have only one variable.
>Do you want to regard x^2, which is non-linear, to be a variable
>and thus consider the equation to be of two variables?
>
No it is still one variable. Although regarding it as two variables
may make solving the system of equations easier. For some systems
it may simply be impractical to solve the set of equations without
such reductions.
The final rule is that if you have B equations in K unknowns
then it can only be solved if the B equations are nondegenerate
and consistent and B>=K.
nondegenerate and consistent having the standard meaning of
linear equations.
>> Finally it shows an example of a 'cipher'
>> that is weak and can be solved with
>> a carefully chosen ciphertext for certain
>> weak keys. Even though my 'theory'
>> says that we shouldn't be able to find
>> the key.
>>
[snip.. part of example deleted]
>> Selected at random (flipping coins)
>> Starting over if first two flips are both head (one).
>>
>> 0 = 22 = 3 2 1 0
>> 1 = 03 = 2 0 1 3
>> 2 = 11 = 1 2 3 0
>> 3 = 21 = 3 2 0 1
>>
>> We can then write out the equations
>>
>> input bits AB
>> key bits CD
>> output bits EF
>>
>> A^B is A XOR B (lowest precedent)
>> AB is A AND B (highest precedent)
>>
>> 0 = 3 2 1 0
>> E = 1^A
>> F = 1^B
>>
>> 1 = 2 0 1 3
>> E = 1^A^B
>> F = A
>>
>> 2 = 1 2 3 0
>> E = A^B
>> F = 1^B
>>
>> 3 = 3 2 0 1
>> E = 1^A
>> F = 1^A^B
>>
>> The final equations of E and F are (I think this is correct it was done by
>> hand)
>>
>> E = (1^C^D^CD)(1^A) ^ (D^CD)(1^A^B) ^ (C^CD)(A^B) ^ CD(1^A)
>> E = (1^C^D)(1^A) ^ (D^CD) ^ (D^CD)(A^B) ^ (C^CD)(A^B)
>> E = 1^C^D ^ (1^C^D)A ^ D^CD ^ (C^D)(A^B)
>> E = 1^C^CD ^ A^AC^AD ^ (C^D)A ^ (C^D)B
>> E = 1^C^CD ^ BC ^BD ^A
>>
>> F = (1^C^D^CD)(1^B) ^ (D^CD)A ^ (C^CD)(1^B) ^ CD(1^A^B)
>> F = (1^D)(1^B) ^ AD ^ CD ^ BCD
>> F = 1 ^ D ^ B ^ BD ^ AD ^ CD ^ BCD
>>
>> The input selected at random (coin flipping) is 0
>> The key is 3
>> The output will be 3
>>
>> This gives
>>
>> E=1 = 1^C^CD
>> F=1 = 1^D^CD
>>
>> Note that in this step we can assume G=CD giving
>>
>> E=1 = 1^C^G
>> F=1 = 1^D^G
>>
>> which yeilds C=D
>> since the system is degenerate we cannot do better with one text
>> This gives us an expression of the inputs and outputs in reduced form
>>
>> E= 1^A
>> F= 1^B^AC
>>
>
>With C=D, there are two possibilities, namely C=D=0 or C=D=1,
>which correspond to the cases 0 and 3 you numbered above. These
>have
>
>E = 1^A E = 1^A
>F = 1^B F = 1^A^B
>
>as was derived above. If one has C=0, then your set of equations
>immediately above should reduce to the first set and if one has
>C=1, then that should reduce to the second set. I don't see that
>can be the case. Is there a computing error on your part or I am
>simply wrong or haven't correctly understood the matter? (Could
>you please explain?) Thanks.
The equation
F=1^B^AC means exactly that.
if C=0 it reduces to F=1^B
if C=1 then it is F=1^A^B
ie AC=A if C=1
AC=0 if C=0
My calculations may have some errors but I don't think this is
one of them.
Since the pair given can't uniquely define the key
we have an equation F=1^B^AC that still contains
key material ie C.
Explained another way.
For input 0 and output 3 the
key can be either 0 or 3
For these two keys the equation for E is the
same.
The equation for F differs in the term A with dependence on
C.
>
>M. K. Shen
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
