Cryptography-Digest Digest #447, Volume #14 Sat, 26 May 01 11:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (Tim Tyler)
Re: Best, Strongest Algorithm (Tim Tyler)
Re: survey (Tom St Denis)
Re: A generic feistel cipher with hash and gf(257) mixers (Tom St Denis)
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am (Mok-Kong
Shen)
Help with 'P' in PKCS1V2.1 RSAES-OAEP (Sam)
Newbie question about algo (Martin Kiewitz)
Re: Newbie question about algo (Tom St Denis)
Essay on "The need for a look at real life crypto" (Tom St Denis)
Re: Differential cryptanalysis. ([EMAIL PROTECTED])
Re: 1st CipherText Application prototyped ("Prichard, Chuck")
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a fool ?
(Al)
Re: Small (not fast) RIPEMD-160 (Mark Wooding)
Re: 1st CipherText Application prototyped (Tom St Denis)
Re: A generic feistel cipher with hash and gf(257) mixers (Jim Steuert)
Re: A generic feistel cipher with hash and gf(257) mixers (Tom St Denis)
Re: A generic feistel cipher with hash and gf(257) mixers (Jim Steuert)
Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a fool ?
(John Savard)
Re: Good crypto or just good enough? ("Harris Georgiou")
Re: Getting back to the self-study Analysis ("Harris Georgiou")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 May 2001 09:09:56 GMT
Mark Wooding <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:> It certainly has some different properties - here is some of the upside:
:>
:> * Use of the same key on different messages is much better with BICOM, due
:> to the whitening.
:> * Bitflipping produces a huge error extension in BICOM - but none in
:> counter mode.
: Useless. If you want to detect tampering, use a MAC. If you don't, you
: probably want minimal error extension.
The advantage of this boils down to the fact that information in the
plaintext if diffused in the cyphertext.
Imagine you have an attack that allows you to go from some known
plaintext to a key.
With CTR mode this attack will produce immediate results, since the
inputs to the cypher (i.e. the counter) is not normally considered
to be part of the secret key.
However with something with good diffusion properties this attack
would be likely to fail - unless the *entire* plaintext of the message
is already known.
Of course, it is not realistic to assume the existence of a known
plaintext attack - but it should illustrate how diffusing plaintext
information in the cyphertext can be desirable in the case where one is
not 100% certain of the security of the block cypher used.
:> * BICOM compresses - files should be smaller, so there's less cyphertext
:> for the attacker to look at and messages are brought closer to the
:> unicity distance, so the likelihood of multiple correct-looking decrypts
:> is increased.
: So do gzip, bzip2 and so on. Using a cipher with a compression
: algorithm is common practice.
Yes, that's exactly what BICOM is. Are we now changing the subject to
comparing BICOM with CTR mode plus some unspecified compression
algorithm?
: Your problem is that you're actually using a really strange attack
: model. You're assuming that the best attack against the cipher is
: actually brute-force search of the keyspace, with unknown plaintext.
: This smells unreasonably optimistic to me.
I'm not assuming that. I was asked to explain how BICOM could be more
secure than CTR mode. I gave an example of one attack against which it
/is/ more secure. That attack happens to be the best attack publicly
known against the cypher in question.
There may well be other attacks against Rijndael that I don't know about,
However, the chances of these affecting BICOM and /not/ affecting CTR
mode appear to be practically nil.
:> No proof for CTR mode either.
: What? You must have been dreaming. There's a proof that attacking CTR
: under the real-or-random model is only `a bit' harder than
: distinguishing the block cipher from a random function (where `a bit' is
: carefully quantified).
Ah, that's not what I was talking about. I should perhaps have specified
more clearly that I meant there was no proof of security for *Rijndael*
in CTR mode.
There's no proof of security for Rijndael in any other mode either.
There's no proof of security for Rijndael full stop.
Rijndael will probably be broken, in the fullness of time.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 May 2001 09:14:57 GMT
Joseph Ashwood <[EMAIL PROTECTED]> wrote:
: "Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
[snip two proposed modes of operation]
:> Both depend on a proof of security for Rijndael - which doesn't exist.
: Actually that's not true, you can prove a reduction without proving
: difficulty. [...]
A "proof of security" was what was claimed.
I see that as being a different thing to a proof that a system
is as strong as another system, which itself has unknown security
properties.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Sat, 26 May 2001 09:37:51 GMT
Dave Knapp wrote:
>
> On Tue, 22 May 2001 21:43:34 GMT, "Tom St Denis"
> <[EMAIL PROTECTED]> wrote:
>
> >I don't want to be pushy, I know you guys are busy (I am out of the house
> >most of the day too). But most of my papers are under 15 pages (in fact all
> >my LaTeX formated papers are 15 or under) so they should only take about 10
> >mins to read.
>
> A typical Physical Review letter is 4 pages long, and a thorough
> reading usually takes a half hour.
>
> If you seriously believe that anyone can give you useful feedback on
> your algorithm with a 10-minute scan of a 15-page paper, then either
> (a) the information content of the 15-page paper could be condensed to
> less than 1 page, or (b) you don't consider your algorithm worthy of
> serious consideration.
>
> Reading a crypto paper is not like reading a novel.
Oh I whole heatedly agree. The thing is alot of my papers do not (yet)
involve big math proofs. In MDFC for example the description of the
attack that kills the cipher is so simple I can explain it to my
comp.sci teacher (he's not a big crypto fan).
I would assume that the level of math in my papers is far below that of
a typical paper and as such most could zoom through it.
Heck any feedback would be nice like "looks good so far" or "looks very
poor so far"...
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sat, 26 May 2001 09:39:33 GMT
Jim Steuert wrote:
>
> Now I believe that I understand some of the
> rationale for key schedules. The key be divided into smaller pieces,
> and each different piece of the key can be xor's with one of the a,b,or c
> digest variables ***at different rounds*** of the feistel network.
> This "leak-around" and subsequent avalanche of information around
> the key at those rounds can prevent the known-plaintext attacks.
> It seems I am learning the hard way some of the "why" of conventional
> cipher designs.
> Are there some other principles of key scheduling which are relevant
> to feistel ciphers like this? Thanks for your advice.
If you xor the key into the data and you simple permute the bits then
it's automatically vulnerable to a complementation property.
Your key schedule should produce vastly different round keys when two
user keys are sent in (this is called being differentially non-related).
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am
Date: Sat, 26 May 2001 12:38:44 +0200
BenZen wrote:
........
[snip]
max { n | H(m,n) > 0 } means the largest of all candidate
n values that satisfy the condition H(m,n)>0 (for a given m).
M. K. Shen
------------------------------
Date: Sat, 26 May 2001 20:49:20 +1000
From: Sam <[EMAIL PROTECTED]>
Subject: Help with 'P' in PKCS1V2.1 RSAES-OAEP
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Could somebody please tell me how to determine P required for
<p>PKCS1v2.1 RSAES-OAEP 9.1.1.1 Encoding operation
<p>DB=pHash||PS||01||M
<p>I know it says (P <= 2^61-1) for SHA-1 and Pis an octet string
specified explicitly as per Appendix A.2.1 but how do I deter mine size
and value of P for pHash function. I do not want to use any commercial
pacakages, may be just Java libraries.
<p>Is there any example code for same in Java
<p>Thanks in advance
<p>Sam</html>
------------------------------
From: [EMAIL PROTECTED] (Martin Kiewitz)
Subject: Newbie question about algo
Date: 26 May 2001 04:03:21 -0700
Hi !
I'm somehow a newbie to cryptology and i'm just building some stream
encryption algorythmn.
I don't want flames, please. I'm posting this, so other people can
post their opinions about it.
I want to encode a duplex-stream (named pipes, tcp-connection, etc.)
using a really fast
and safe algorythmn.
Handshaking is done using PGP Public Key.
The server sends its System-Key to the client.
Client checks key by proofing signature with Super Key.
Now client encodes LoginData & Crypto Hash using Public Key.
Client sends that paket to server.
Server decrypts LoginData & Crypto Hash with its own secret key.
Now server sends unencrypted (raw) success of login. (that's done, so
no byte guessing can take place).
Server sends terminal operations, till actual interactive use needs to
be done by client. (actually till Server thinks Crypt is needed).
Now my own crypt algo looks like this:
In and Out Stream, both have 2Kbyte Hash, both are generated by client
and both are "true" randomized numbers.
I suppose: CurPos = 0 (at begin of en/decryption)
To encode:
1. EncodedChar = OrgChar xor Hash[CurPos]
2. Hash[CurPos] = Hash[CurPos] xor EncodedChar
3. CurPos = CurPos+OrgChar
4. CurPos is cut down to 2k range
5. Encode further data
Decoding is performed accordingly.
Is this algo good ? Is it breakable ?
When suggesting that the hash is transmited without being captured, I
believe the encryption is somehow unbreakable, because the hash gets
modified each decoded char, no byte guessing is possible, because
there is no data to check for.
What could I improve ? Is my handshaking good ?
I read somewhere, that a good algo does not have to be long or
complex, but it has to be strong.
cu Kiewitz
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Newbie question about algo
Date: Sat, 26 May 2001 11:08:05 GMT
Martin Kiewitz wrote:
>
> Hi !
>
> I'm somehow a newbie to cryptology and i'm just building some stream
> encryption algorythmn.
> I don't want flames, please. I'm posting this, so other people can
> post their opinions about it.
>
> I want to encode a duplex-stream (named pipes, tcp-connection, etc.)
> using a really fast
> and safe algorythmn.
>
> Handshaking is done using PGP Public Key.
> The server sends its System-Key to the client.
> Client checks key by proofing signature with Super Key.
> Now client encodes LoginData & Crypto Hash using Public Key.
> Client sends that paket to server.
> Server decrypts LoginData & Crypto Hash with its own secret key.
>
> Now server sends unencrypted (raw) success of login. (that's done, so
> no byte guessing can take place).
> Server sends terminal operations, till actual interactive use needs to
> be done by client. (actually till Server thinks Crypt is needed).
>
> Now my own crypt algo looks like this:
Question: Why did you invent your own algorithm?
> In and Out Stream, both have 2Kbyte Hash, both are generated by client
> and both are "true" randomized numbers.
>
> I suppose: CurPos = 0 (at begin of en/decryption)
>
> To encode:
> 1. EncodedChar = OrgChar xor Hash[CurPos]
> 2. Hash[CurPos] = Hash[CurPos] xor EncodedChar
> 3. CurPos = CurPos+OrgChar
> 4. CurPos is cut down to 2k range
> 5. Encode further data
>
> Decoding is performed accordingly.
>
> Is this algo good ? Is it breakable ?
Um fairly easily. A known plaintext attack can learn contents of Hash
relatively easily. Also by encoding a stream of 1 bytes I can learn the
entire table with 2kb worth of text.
> When suggesting that the hash is transmited without being captured, I
> believe the encryption is somehow unbreakable, because the hash gets
> modified each decoded char, no byte guessing is possible, because
> there is no data to check for.
The problem is you are onlything thinking of known ciphertext attacks.
If I know the plaintext I can break this.
> What could I improve ? Is my handshaking good ?
>
> I read somewhere, that a good algo does not have to be long or
> complex, but it has to be strong.
Well I dunno about your PGP hand shaking.... but the stream cipher is
weak, and I think has a short period.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Essay on "The need for a look at real life crypto"
Date: Sat, 26 May 2001 12:17:55 GMT
Based on my turn about look at computer security...
http://tomstdenis.home.dhs.org/on.pdf
Please comment if possible. Does this hit the mark with what you guys
are thinking?
Tom
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Differential cryptanalysis.
Date: Sat, 26 May 2001 12:31:43 GMT
Adam O'Brien <[EMAIL PROTECTED]> wrote:
: Could someone recommend a book (ideally) or website explaining more about
: differential cryptanalysis. I've read the bit in Applied Crypto and want to
: know more.
: Adam
"Cryptography Theory and Practice" by Doug Stinson (ISBN 0-8493-8521-0)
discusses it and guides you through a few examples. The book is a little bit
on the expensive side, but well worth it.
--
Mark Wutka
------------------------------
From: "Prichard, Chuck" <[EMAIL PROTECTED]>
Subject: Re: 1st CipherText Application prototyped
Date: Sat, 26 May 2001 13:20:45 GMT
Installation bugs were fixed and new program features added.
The application now supports user preference settings. This is necessary
for setting the POP server domain, and useful for setting the return
address and default key.
Also, a random key generator was added.
There is a bug associated with some of the keys created by the random
generator. If keys are tested BEFORE creating a message, no work will be
lost.
The application has no contact management, and creates no file of sent
messages.
------------------------------
From: [EMAIL PROTECTED] (Al)
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a
fool ?
Date: 26 May 2001 06:26:27 -0700
Maybe the inverse problem which is hard could be used as the basis of a public key
system?
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Small (not fast) RIPEMD-160
Date: 26 May 2001 13:53:00 GMT
Ian Stirling <[EMAIL PROTECTED]> wrote:
> jlcooke <[EMAIL PROTECTED]> wrote:
> >I've got RIPEMD160 to 1990bytes. SHA-1 to 1360bytes.
>
> Thanks. I've got RIPEMD160 down to 3040 bytes, (with gcc) from around 7K.
>
> I know how to get down to around 2540 or so, perhaps 2200, but there
> I think it's going to stick.
I got it to 1570 bytes in C. (Implementation mailed to poster.)
-- [mdw]
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 1st CipherText Application prototyped
Date: Sat, 26 May 2001 13:57:57 GMT
"Prichard, Chuck" wrote:
>
> Installation bugs were fixed and new program features added.
Hmm who are you replying to?
> The application now supports user preference settings. This is necessary
> for setting the POP server domain, and useful for setting the return
> address and default key.
>
> Also, a random key generator was added.
What is the PRNG based on?
> There is a bug associated with some of the keys created by the random
> generator. If keys are tested BEFORE creating a message, no work will be
> lost.
>
> The application has no contact management, and creates no file of sent
> messages.
If you're program is not free, open source or "a good learning tool" you
are spamming this group. I ask that you stop.
Tom
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sat, 26 May 2001 10:15:13 -0400
My remedy, given three 32-bit digest vars (a,b,c) was to, after the
inital 30 rounds of mixing of (a,b,c) , to replace the
simple xor of all three key parts (key1,key2,key3) with the following:
Xor the first part key1 of the key with the "a", and then provide say, 8 rounds
of
mixing mix(a,b,c) , then xor only the second part of the key with "b" ,
then 8 rounds of mix(a,b,c), then xor only the final part of the key with "c".
Then proceed with the second half of the cipher, with its 30-odd mixing
phases. I know wasn't clear about that, but I am not suggesting that we just
permute the bits between applying different parts of the keys.
Is there something fundamentally wrong with this remedy, except
perhaps that it is too slow?
Tom St Denis wrote:
> Jim Steuert wrote:
> >
> > Now I believe that I understand some of the
> > rationale for key schedules. The key be divided into smaller pieces,
> > and each different piece of the key can be xor's with one of the a,b,or c
> > digest variables ***at different rounds*** of the feistel network.
> > This "leak-around" and subsequent avalanche of information around
> > the key at those rounds can prevent the known-plaintext attacks.
> > It seems I am learning the hard way some of the "why" of conventional
> > cipher designs.
> > Are there some other principles of key scheduling which are relevant
> > to feistel ciphers like this? Thanks for your advice.
>
> If you xor the key into the data and you simple permute the bits then
> it's automatically vulnerable to a complementation property.
>
> Your key schedule should produce vastly different round keys when two
> user keys are sent in (this is called being differentially non-related).
>
> Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sat, 26 May 2001 14:26:09 GMT
Jim Steuert wrote:
>
> My remedy, given three 32-bit digest vars (a,b,c) was to, after the
> inital 30 rounds of mixing of (a,b,c) , to replace the
> simple xor of all three key parts (key1,key2,key3) with the following:
> Xor the first part key1 of the key with the "a", and then provide say, 8 rounds
> of
> mixing mix(a,b,c) , then xor only the second part of the key with "b" ,
> then 8 rounds of mix(a,b,c), then xor only the final part of the key with "c".
> Then proceed with the second half of the cipher, with its 30-odd mixing
> phases. I know wasn't clear about that, but I am not suggesting that we just
> permute the bits between applying different parts of the keys.
Introducing the keys like that doesn't sound to good. You want as much
key material introduced as early as possible. That's why I like SPNs.
They work on the entire block at once and you can get alot of key
material in there. Remember that the only reason why a block cipher is
secure is because the transform is incomplete without the key. So for
example
XOR key into block
Eight Unkeyed rounds
XOR key into block
Eight Unkeyed rounds
etc...
Might work, but it's not nearly as nice as
XOR key
Round
XOR key
Round
> Is there something fundamentally wrong with this remedy, except
> perhaps that it is too slow?
If it is big, slow or confusing to look at then what's the point?
Modern crypto designs are about elegant math and very efficient
transforms. The only reason I feel my TC15a got any feedback whatsoever
is because I claimed it was super fast (which others backed me up).
Tom
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Re: A generic feistel cipher with hash and gf(257) mixers
Date: Sat, 26 May 2001 10:56:34 -0400
Thanks, Tom
I appreciate your feedback. What I am getting at, in general, though,
is a methodology which would take designing ciphers out of the hands
of the "experts" (no disrespect intended) and put it into the hands
of hobbyists, who could still come up with creative ideas, but based
on well-understood design principles. I certainly think that a hobbyist,
if he didn't understand the basic principles could design a really broken
cipher (I've been there). I think that this was part of the point
of Bruce Schneier's book, that a non-crypto-expert programmer could
use cryptography without leaving it to government or other experts.
That is a very dangerous 70's type idea, where hang-glider and homebuilt
airplane designers were getting killed. But still, some creative ideas came
out of it (Rutan, etc.) which are being used in commercial use today.
Likewise for sailboat design, a lot of fields. The hobbyist can contribute,
even to cryptography.
Tom St Denis wrote:
> Jim Steuert wrote:
> >
> > My remedy, given three 32-bit digest vars (a,b,c) was to, after the
> > inital 30 rounds of mixing of (a,b,c) , to replace the
> > simple xor of all three key parts (key1,key2,key3) with the following:
> > Xor the first part key1 of the key with the "a", and then provide say, 8 rounds
> > of
> > mixing mix(a,b,c) , then xor only the second part of the key with "b" ,
> > then 8 rounds of mix(a,b,c), then xor only the final part of the key with "c".
> > Then proceed with the second half of the cipher, with its 30-odd mixing
> > phases. I know wasn't clear about that, but I am not suggesting that we just
> > permute the bits between applying different parts of the keys.
>
> Introducing the keys like that doesn't sound to good. You want as much
> key material introduced as early as possible. That's why I like SPNs.
> They work on the entire block at once and you can get alot of key
> material in there. Remember that the only reason why a block cipher is
> secure is because the transform is incomplete without the key. So for
> example
>
> XOR key into block
> Eight Unkeyed rounds
> XOR key into block
> Eight Unkeyed rounds
> etc...
>
> Might work, but it's not nearly as nice as
> XOR key
> Round
> XOR key
> Round
>
> > Is there something fundamentally wrong with this remedy, except
> > perhaps that it is too slow?
>
> If it is big, slow or confusing to look at then what's the point?
> Modern crypto designs are about elegant math and very efficient
> transforms. The only reason I feel my TC15a got any feedback whatsoever
> is because I claimed it was super fast (which others backed me up).
>
> Tom
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Crypto NEWBIE, wants to create the 100% SAFE FRACTAL encoding... Am I a
fool ?
Date: Sat, 26 May 2001 14:57:27 GMT
On Sat, 26 May 2001 12:38:44 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>max { n | H(m,n) > 0 } means the largest of all candidate
>n values that satisfy the condition H(m,n)>0 (for a given m).
Although I could have told him _that_, I didn't see your earlier post
to find the URL to translate it more fully into layman's language.
(What's H(m,n), and why are we interested in it?)
I'd have explained
g(m) := max { n | H(m,n) > 0 }
like this:
The function of m called g, g(m), is being defined here. For any m,
the value of g(m) is the largest value of n for which H(m,n) is
positiive.
But that's still mathematical language, not layman's language: to go
to layman's language, I need the full context.
John Savard
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Sat, 26 May 2001 07:20:21 +0300
Ο Joseph Ashwood <[EMAIL PROTECTED]> έγραψε στο μήνυμα συζήτησης:
#[EMAIL PROTECTED]
> I have long been a fan not of either the just secure enough, or the bank
> vault front door. I believe in finding an ideal compromise after
> consideration of the situation. I choose a 4096-bit PGP key, not because
> ......
> Joe
>
Well said - couldn't said it better myself.
Besides, the real danger on security for commercial applications comes most
of the time from mishandling sensitive information ABOUT the cipher (i.e.
keys or passwords), not breaking the cipher itself.
It would be better for security if users knew exactly how to exploit 100%
from a simple cryptosystem, rather than heaving a super-safe crypto and
leave the passwords under the desk....
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
From: "Harris Georgiou" <[EMAIL PROTECTED]>
Subject: Re: Getting back to the self-study Analysis
Date: Sat, 26 May 2001 08:46:20 +0300
Ο Tom St Denis <[EMAIL PROTECTED]> έγραψε στο μήνυμα συζήτησης:
[EMAIL PROTECTED]
> Anyways, not like my original thread didn't go down hill...
>
> Any hints or tips? I am gonna work it out on paper a bit more later
> on... I can't figure out how to exploit the linear relationship
>
> A xor K = B
> A' xor K = B'
>
> (Dave you are not invited into this thread).
>
> Tom
Since:
(B xor B') = (A xor K) xor (A' xor K)
= (A xor K) xor (K xor A')
= A xor (K xor K) xor A'
= A xor 0 xor A'
= (A xor 0) xor A'
= A xor A'
Then (similarly):
A' = (B xor A) xor B'
It's obvious that given a single pair of plaintext-ciphertext, then for any
subsequent ciphertext the plaintext can be easily found without having the
actual key. Other than that, I don't think you have enough to retrieve A, A'
and K just from B and B' (you always have one variable more than
constraints).
--
Harris
- 'Malo e lelei ki he pongipongi!'
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
