Cryptography-Digest Digest #906, Volume #13 Thu, 15 Mar 01 15:13:01 EST
Contents:
Re: Between Silk And Cyanide - Identity checks. (Joe H. Acker)
Re: Potential of machine translation techniques? (Richard Herring)
ANSI X9.17 Key Generation and Alternatives (Bjorn Forsberg)
Re: RSA ("Joost van der Meer")
Re: Analysis of PCFB mode ("Henrick Hellström")
Re: Potential of machine translation techniques? (Mok-Kong Shen)
Re: RSA ("Tom St Denis")
How to eliminate redondancy? (br)
Re: Quantum Computing & Key Sizes (Mike Rosing)
Re: How to eliminate redondancy? ("Tom St Denis")
Re: Is SHA Copyrighted? Can It Be Exported? (Bart Bailey)
Re: RSA (Mike Rosing)
Re: Potential of machine translation techniques? (Mike Rosing)
Re: on-the-fly encryption (Christian Leber)
Re: Super strong crypto (John Savard)
Re: Is SHA Copyrighted? Can It Be Exported? (Kent Briggs)
Re: Crypto idea (Bill Unruh)
Re: An extremely difficult (possibly original) cryptogram (daniel mcgrath)
Re: Is SHA Copyrighted? Can It Be Exported? (Bill Unruh)
The Art of Cryptography (was: Super strong crypto) (John Savard)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Joe H. Acker)
Subject: Re: Between Silk And Cyanide - Identity checks.
Date: Thu, 15 Mar 2001 18:05:59 +0100
Matthew Stanfield <[EMAIL PROTECTED]> wrote:
> > Here's my second trial :)
> >
> > When Alice hands out the OTPs to Roger, she may not take a look at them.
> > Then, Roger learns some numbers of the first OTP he got, and immediately
> > destroys the OTP. From now on, he uses these numbers as identity. Alice
> > does not know the numbers, but the recipient overseas knows them. Gerald
> > does not know the numbers if he finds Rogers remaining OTPs, only when
> > he catches Roger himself.
>
> An expansion of this idea might work.
>
> On OTPs there are groupings of letters that are transmitted in plain
> text to identify which OTP is in use. What Roger could do in his first
> message to Bob is within the cypher text to specify another OTP by its
> id letter group and then specify which of this OTP's letter groupings he
> will use to modify every OTP he uses in future. Then of course he would
> destroy the OTP that he is using for his identity check. This however
> wouldn't work if Roger and Alice are captured before Roger has
> transmitted his first communication to Bob.
I can't see any reason for your expansion. My scheme works like I've
described it, given that Alice uses a selection procedure known to Bob
for handing out OTPs to new agents. The selection procedure can be
simple ordering of the OTPs, but it could also be a complicated shared
secret. One requirement could be that Bob should be able to recognize
who has recruited the new agent (Roger or Bob). So when Alice gives the
OTPs to Roger, the procedure should ensure that Bob knows which OTPs
Roger posesses when he first establishes contact with Bob. For example,
Alice could always give the second half of their OTPs to a new agent.
When Bob receives a message he cannot decipher with the next OTP in
sequence, he'll split the OTPs he has in two half. First half is for
Alice, seconds half is for a new agent recruited by Alice. The first OTP
of the second half *must* be the identity. If the second OTP of the
second half does not decipher the first message of the new agent and
does not contain the identity, he is marked as compromised and ignored.
(If Alice and Roger use the same channel, Bob needs to check if the
message can be deciphered by the first half first.)
Of course, with this simple scheme, Alice might quickly run out of OTPs
while recruiting agents. There are numerous other schemes that could
also be used as a weak check for correct recruitment. The scheme I have
described also has the disadvantage that Alice might not accidently
delete an OTP without reducing her available OTPs by one half---not very
practical...
Regards,
Erich
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Potential of machine translation techniques?
Date: 15 Mar 2001 16:51:24 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Mok-Kong Shen ([EMAIL PROTECTED])
wrote:
> JCA wrote:
> >
> > "Mok-Kong Shen"<[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Now that machine translation of natural languages has reached a fairly
> > > advanced state,
> >
> > I guess the keyphrase here is "fairly advanced". Lacking as they do any
> > understanding of what they are translating, automatic translators do a
> > pitiful job when compared to a human.
> Machine translation failed badly in its initial phase
> (in the sixties or so), but currently it isn't that bad
> as far as I am aware. EU has a project to translate documents
> from/to member countries in their own languages, though I am
> ignorant of its current state of progress.
EU languages form a very restricted subset of all natural
languages. Apart from Finnish they are all either Germanic or
Romance.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Bjorn Forsberg <[EMAIL PROTECTED]>
Subject: ANSI X9.17 Key Generation and Alternatives
Date: Thu, 15 Mar 2001 12:17:03 -0500
I have a blob of data to encrypt and persist to a file system for long
term storage.
I have a master key (fixed). I generate the actual encryption key for
the data from the master and a piece of data stored with the blob on the
file system. This piece of data is HMAC'd and included in the ciphertext
so it can be relied upon.
I use an algorithm like ANSI X9.17 to generate the encryption key from
the master. However, this process involves two encryption operations
itself and is hence very expensive in an environment were the number of
encrypts/decrypts may be high.
Given that, are there other published methods of generating a key from a
master that are secure yet less expensive? I mean, I could simply xor
the master key with the piece of data from the blob to get my encryption
key and save those two extra encryption operations. But am I exposing
myself to some sort of attack?
Hardware is not an option at this time.
Thank you.
Bjorn Forsberg
Roaring 30s
------------------------------
From: "Joost van der Meer" <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: Thu, 15 Mar 2001 18:30:12 +0100
I'm sorry, but what is a 'big num library'??? Sorry, my english is not so
well, and I don't now much technical terms...
Joost
Tom St Denis <[EMAIL PROTECTED]> schreef in berichtnieuws
ci5s6.42756$[EMAIL PROTECTED]
>
> "Joost van der Meer" <[EMAIL PROTECTED]> wrote in message
> news:98qlev$e4h$[EMAIL PROTECTED]...
> > Hello,
> >
> > I've got to make an assignment for school about the RSA encryption
system.
> I
> > want to write a example, but I can't calculate the private key D. Is
there
> > anybody who can give me a whole example (prime numbers ( P&Q) and
> exponents
> > (e&d) ???
> >
>
> What big num library are you using? Most good ones come with mod inverse
> functions.
>
> Tom
>
>
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Analysis of PCFB mode
Date: Thu, 15 Mar 2001 18:27:39 +0100
> "David Wagner" <[EMAIL PROTECTED]> skrev i meddelandet
> > First, it seems difficult to choose m so that PCFB mode becomes
> > competitive. If m is too small, PCFB mode is inefficient. With
> > m=64, PCFB mode is already twice as slow as other integrity modes
> > (IACBC, OCB, XCBC, etc.), which suggests that there will be strong
> > pressure to choose m >= 64.
BTW, I did mention a "piped" version of PCFB mode for values of n greater
than the block size of the underlying cipher. Here is the algorithm for
piped PCFB-128/256 mode (without authentication to keep the pseudo code as
clean as possible):
1. V_0 := IV0 + ctr, C_0 := IV1. (Alternatively, let V_0, C_0 be equal to
V_L, C_L of the previous message.)
2. For i := 1 to L do
2.1. V_i := E(k,V_i-1 + C_i-1).
2.2. T := E(k,V_i + V_i-1).
2.3. C_i := P_i xor T.
3. Return ctr || C_1 || C_2 || ... || C_L.
This version is still about twice as slow as the other modes (because it
requires two block encryptions per block of text), but it's security
features seems to be equivalent to those of PCFB-64/128 mode, and the piped
mode might be easier to analyze. The + operation is supposed to be addition
modulo 2**128, but I don't see any reason why one could not use xor or some
other group operation instead.
An alternative might be to simply skip the encryption at step 2.2, but then
the mode would perhaps be less secure. We would have V_i + V_i-1 = Pi xor
Ci, and that does not seem to be a desirable property. However, it is not
trivially true that such a property could be exploited by an attacker, given
that IV0 is kept secret.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Potential of machine translation techniques?
Date: Thu, 15 Mar 2001 18:41:12 +0100
Richard Herring wrote:
>
> EU languages form a very restricted subset of all natural
> languages. Apart from Finnish they are all either Germanic or
> Romance.
I heard on the other hand that there are successful
translation software between Japanese and English.
M. K. Shen
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: Thu, 15 Mar 2001 17:49:23 GMT
"Joost van der Meer" <[EMAIL PROTECTED]> wrote in message
news:98qtlm$va8$[EMAIL PROTECTED]...
> I'm sorry, but what is a 'big num library'??? Sorry, my english is not so
> well, and I don't now much technical terms...
You need to work with large integers. Normally ISO C does not include such
facilities.
"big num library" is a library of functions aimed at working with larger
integers.
Tom
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: How to eliminate redondancy?
Date: Thu, 15 Mar 2001 12:49:16 -0400
I'm trying to find any document about how to eliminate the redondancy of
english language (except compression algorithm).
Is there any work about this question?
Thank you for help
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Quantum Computing & Key Sizes
Date: Thu, 15 Mar 2001 12:20:30 -0600
"Tony L. Svanstrom" wrote:
>
> Reading the answer... hmmm... binary code that you get in dead / not
> dead cats? ;-)
Exactly. A lot of dead cats involved in quantum mechanics :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Thu, 15 Mar 2001 18:31:19 GMT
"br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> I'm trying to find any document about how to eliminate the redondancy of
> english language (except compression algorithm).
> Is there any work about this question?
Hmm compression is the only way to remove redundancy because by definition
that is what compression is.
Tom
------------------------------
From: Bart Bailey <[EMAIL PROTECTED]>
Subject: Re: Is SHA Copyrighted? Can It Be Exported?
Date: Thu, 15 Mar 2001 10:36:44 -0800
Kent Briggs wrote:
> Ace Bezerka wrote:
>
> > Does anyone know if SHA is copyrighted? Can it be freely used in programs
> > (like Blowfish)? Can it be exported?
>
> Algorithms are not subject to copyright. Patents are another story. SHA was
> developed by the U.S. government and is unencumbered. Hashing functions are
> not subject to U.S. export restrictions. So No, Yes, and Yes are the answers
> to your questions.
Now that an AES candidate has been selected, do you plan to incorporate it as
well as any of the others into Puffer?
I'm still using v3.11 and like the sda feature. Would like Rijndael and Twofish
if you ever upgrade.
~~Bart~~
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: Thu, 15 Mar 2001 12:35:40 -0600
Joost van der Meer wrote:
> I've got to make an assignment for school about the RSA encryption system. I
> want to write a example, but I can't calculate the private key D. Is there
> anybody who can give me a whole example (prime numbers ( P&Q) and exponents
> (e&d) ???
Since all you need is an example, pick numbers you can work with on a calculator.
For P and Q, choose 2 primes less than 300 (or whatever you feel like). Pick
e = 3 (a sort of standard value, for your example it's fine). Then the hard
part is finding d. You need e*d = 1 mod (P-1)*(Q-1). You can either brute force
it (*very* time consuming) or you can go thru Euclid's algorithm to find the
value of d. Since P and Q are calculator sized, that won't take you too long.
do a web search for "euclid inverse" and you'll get lots of descriptions on how
to do it. When you get confused, come back and ask more questions!
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Potential of machine translation techniques?
Date: Thu, 15 Mar 2001 12:38:36 -0600
Mok-Kong Shen wrote:
>
> I heard on the other hand that there are successful
> translation software between Japanese and English.
Yeah, but it's not all that successful! I spent a week with a
guest from Japan who had a hand held translator and a Mac with
a translator. It took us 5 minutes per concept on a good day,
and trying whole sentences was very funny. Without the translator,
it would have been much, much more difficult so they are definitly
useful. But a long ways from being "successful".
Patience, persistence, truth,
Dr. mike
------------------------------
From: Christian Leber <[EMAIL PROTECTED]>
Subject: Re: on-the-fly encryption
Date: Thu, 15 Mar 2001 19:42:58 +0100
On Wed, 14 Mar 2001 00:55:10 GMT, Neil Couture <[EMAIL PROTECTED]>
wrote:
>It is always possible to Lock memory pages in memory so that the virtual
>memory system does not swap them.
No, it is a big problem for user space applications.
Christian Leber
--
"We're still waiting for the Vatican to officially canonize
this kernel, but trust me, that's only a matter of time.
It's a little known fact, but the Pope likes penguins too."
(Linus Torvalds)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Super strong crypto
Date: Thu, 15 Mar 2001 18:40:14 GMT
On Tue, 13 Mar 2001 06:33:04 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote, in part:
>Bryan Olson wrote:
>> Douglas A. Gwyn wrote:
>> > I am concerned with taking some
>> > standard symmetric encryption algorithm, which is not
>> > proven to be secure against all possible cryptanalysis,
>> > and enhancing the way it is used to provide more security,
>> > to the point that I can have *confidence* that not even
>> > the best feasible cryptanalysis is going to be able to
>> > break it (more likely than some acceptable threshold).
>> The operative step is the lowering the standard, not the
>> changing of the key.
>I can't even parse that, and my attempts at degarbling
>all produced incomprehensible gibberish. Surely you
>cannot mean that I should let the enemy read my traffic!
I think he means: your method of changing the key very often isn't
really very important; the significant event is using a "standard
algorithm" which isn't secure enough.
Of course, using the term "lowering" to describe using an algorithm
"not proven to be secure against all possible cryptanalysis" seems
strange, since this is true of pretty well all the popular block
ciphers, even those believed more than secure enough for normal use.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Is SHA Copyrighted? Can It Be Exported?
Date: Thu, 15 Mar 2001 13:02:34 -0600
Bart Bailey wrote:
> Now that an AES candidate has been selected, do you plan to incorporate it as
> well as any of the others into Puffer?
> I'm still using v3.11 and like the sda feature. Would like Rijndael and Twofish
> if you ever upgrade.
>
> ~~Bart~~
Both Rijndael and Twofish are at the top of my to-do list for Puffer. I don't know
when that'll be however. I'm currently working on an upgrade for Directory Snoop.
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Crypto idea
Date: 15 Mar 2001 19:11:24 GMT
In <[EMAIL PROTECTED]> Panu =?iso-8859-1?Q?H=E4m=E4l=E4inen?=
<[EMAIL PROTECTED]> writes:
>br wrote:
>> Cryptanalysis use dictionaries as way to find a solution. They suppose
>> that the clear message is wrote without spelling mistakes.
>> I can write a message like "I love you" as " Ay lov u" or "Ilovu"etc....
>> So how cryptanalists could know before my specific spelling of I love
>> you.
Well, for one thing, each byte of the message uses only the bottom 7
bits of the byte. Then there is also the occurance of vowels vs
consonants (vowels occur a lot more often), etc. All order in the
message is useable to crack the encryption. If there is no order in the
message (ie it is a random string) then you cannot crack it without more
information, since any random string looks like any other.
------------------------------
From: [EMAIL PROTECTED] (daniel mcgrath)
Crossposted-To: rec.puzzles
Subject: Re: An extremely difficult (possibly original) cryptogram
Date: Thu, 15 Mar 2001 19:11:04 GMT
On Mon, 12 Mar 2001 23:44:27 -0800, David Schwartz
<[EMAIL PROTECTED]> wrote:
>
>
>daniel mcgrath wrote:
>>
>> Tysoizbyjoxs, this may be the most complicated code anyone has ever
>> done!
>>
>[snip]
>> I do want to see some comment, even if you are totally lost, as no
>> doubt quite a few of you are.
>
> I'll make a deal with. I'll decrypt your message if you can decrypt
>mine.
>
> The ciphertext is:
>
> X
>
> To make it easier, I'll give you an example ciphertext and plaintext
>using the same cipher _and_ the same key.
>
> Ciphertext:
>
> Y
>
> Plaintext:
>
> Now is the time for all good men to come to the aid of their party.
>
> Good luck.
>
OK, I'll try...
I think I've got it. The plaintext says:
Eppur si muove
Key:
":-)" => W
"Eppur si muove" => X
"Now is the time for all good men to come to the aid of their
party." => Y
Everything else is spelled out and a "Z" is put in front of
each character, thus, "DANIEL" -> "ZDZAZNZIZEZL"
Seriously, for anyone who is actually interested in breaking my
cryptogram, I'll say that it contains the phrase "Eppur si muove". (I
was hoping that Jim Gillogly would be interested and respond to my
posting.)
Here is a shorter message that is (basically) in the same code:
34619 24112 61612 20346 69455 75457 12060 11296 67744 12504
63708 94452 04025 04608 14435 61402 04608 04137 57610 09465
14575 04025 04408 14609 24407 61007 28947 55044 57144 35641
02022 40367 37201 00506 67751 00524 03672 04687 58946 07610
09165 64657 64452 04459 34435 27645 59155 04266 72024 18367
87955 50241 69448 65426 67894 50804 26511 00804 13757 64576
72010 05240 36720 42151 41020 44369 45576 10071 44575 10086
44875 76100 76471 80911 51457 50421 56100 80403 55100 94675
89460 76102 50100 58448 75761 00924 21514 45204 15814 65761
00879 34435 27645 59155 04215 14102 02240 36720 42151 41021
03011 29169 46750 22403 67204 21514 10204 02504 43694 43664
75504 03677 51007 54035 54109 55672 01006 24215 64755 04408
94657 64102 04216 14425 04657 64559 55651 00941 56455 95550
44383 54420 50460 80403 67204 60804 12504 05814 17504 18694
48551 00894 15204 03672 02314 30610 09016 54039 14137 52046
08040 38020 42151 45750 46094 66910 09242 66641 37750 40365
46851 47677 50460 89100 72764 18614 45351 00714 57504 02504
43694 55878 14457 91436 78944 86736 40357 92413 75878 14186
04602 03006 75814 52010 05568 02042 67750 46081 44356 10077
89455 20476 69462 50460 89100 79447 50405 71408 64468 51455
75457 50415 91169 44250 40250 44867 76148 80946 69148 80804
55764 12504 08694 63679 24035 28946 38020 44089 46576 51316
44866 44391 10071 44575 10052 40355 41095 55044 08946 57610
08042 66614 52010 05844 87576 10092 42151 44520 41361 41860
46095 56641 58146 57610 07945 57641 36720 40869 44089 45576
41020 45076 44870 85412 50421 51410 20445 89100 79413 80924
26677 91007 64718 09115 11008 64267 88071 43656 45794 10092
42151 46020 40377 50403 65468 51476 77504 60814 43564 57504
26672 04686 94557 54575 04057 64266 77910 07110 07944 86941
02042 15145 57510 08544 88581 44579 10071 45591 16946 76706
01125 68020 46851 45750 42667 20460 94669 10086 44875 76100
92421 51445 20413 61418 60460 20421 51457 50413 85764 45204
05814 17504 18514 43564 57504 60891 00901 65403 91145 20100
53465 76455 95655 40391 10071 44575 10072 76418 61445 87814
45791 00924 48664 48759 11694 67651 00924 21514 60203 24215
14458 44585 94268 58144 57910 08145 75041 86944 85510 07789
45520 46080 40367 84415 93440 20410 91156 40366 45750 44857
20324 21514 45844 58594 26858 14457 91452 01005 74488 57610
09166 91008 64635 44205 04036 77510 07646 57645 59555 04215
14557 51007 27641 86144 53510 07145 75046 86040 38020 41089
41377 50284 03614 50764 50764 13927 61008 54488 57619 71205
61789 40589 41095 55041 38576 45520 40851 44520 40365 46851
47677 66445 76465 76455 36458 69443 56460 81443 56457 50460
80403 67841 00956 69462 59455 76100 71445 20403 65468 51476
78614 45791 00804 03757 51009 01564 48708 54125 04485 72040
25040 57641 86144 52041 58945 52046 08041 25040 36545 08040
35276 46020 44857 20408 69410 76457 50403 67751 00864 26904
13551 00934 50204 68694 55754 57672 01006 24215 64755 04036
54402 04585 14602 04108 94686 72040 59555 02240 36787 95550
28408 09463 70901 56455 35100 92421 51445 20460 80413 91100
76465 76455 95550 40869 46365 41020 40365 46851 47677 50418
56460 20460 89100 85426 85761 00804 03709 01614 40955 50413
85764 55204 03579 24137 53706 012
..... tysoizbyjoxs ... good luck
... daniel mcgrath
==================================================
daniel g. mcgrath
a subscriber to _word ways: the journal of recreational linguistics_
http://www.wordways.com/
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Is SHA Copyrighted? Can It Be Exported?
Date: 15 Mar 2001 19:16:01 GMT
In <[EMAIL PROTECTED]> "Ace Bezerka" <[EMAIL PROTECTED]> writes:
>Does anyone know if SHA is copyrighted? Can it be freely used in programs
>(like Blowfish)? Can it be exported?
Copyright only covers the a specific implimentation -- not the
algorithm itself. Ie, you can write an implimentation yourself which is
then not covered by any copyright of any other implimentation.
SHA can als be exported. Is is an Authentication code, not a crypto
code. Authentication codes do not have US export restrictrions (assuming
you are talking about the USA. Other countries may vary).
(This is not legal advice. If you are concerned, consult a lawyer.)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: The Art of Cryptography (was: Super strong crypto)
Date: Thu, 15 Mar 2001 19:10:16 GMT
On Thu, 15 Mar 2001 08:20:40 GMT, "nospam"@"nonsuch.org" ("Bryan
Olson") wrote, in part:
>Nonsense. Several of us have been repeatedly asking you
>just to define your assumptions and goals in precise terms.
>To this day you have not. Quoting Wagner, "In the absence
>of a precise statement of assumptions, claims of security
>for this mode are `not even wrong'; no sensible truth value
>can be assigned to them."
Certainly, this is a valid point.
However, I think making this _kind_ of point does miss an important
fact.
In many cases, the goal of cryptography is to ensure that one's cipher
cannot be broken. This goal applies to all possible cryptanalytic
attackers. Thus, intelligence agencies with abilities not noted in the
open literature are included. Thus, attackers who might begin their
attacks 50 years from now, after advances in the field, are included.
Thus, to design a cipher that is adequate where high security is
desired, it is *necessary* to extend one's reach into the realms where
cryptography ceases to be a science, and becomes an art.
Douglas Gwyn's proposed mode, for those who are late to this debate,
is basically as follows:
With a given key, encrypt:
- a very short stretch of plaintext,
- a new key to encrypt the next stretch of plaintext.
The short stretch of plaintext is so short that more than one possible
candidate plaintext could have been encrypted with some key to produce
the ciphertext seen.
One explicit assumption is stated: the key size of the cipher used
must be large enough so that brute-force search is infeasible.
Otherwise, the splitting of the plaintext into short segments does not
achieve anything; searching on the first key will obtain plausible
plaintexts of the entire message, not of a single segment, and that
will lead to uniqueness.
The consequence of this assumption is that an attack on the cipher
must be an _analytic_ attack.
This mode does place obstacles in the way of an analytic attack. (In
fact, it belongs to a family of frequently seen amateur suggestions
that do this, I believe.)
An analytic attack normally works with an adequate amount of plaintext
enciphered in a single key. Here, only an *inadequate* amount is
available in any one key - plus a _random_ series of bits.
The route to an attack lies only through the fact that the random
series of bits thus encrypted is used as the key to encipher some
additional plaintext.
Thus, such an attack would be possible if the cipher were so designed
that partial information about the plaintext in one segment first
translated into usable information about the key in that segment, and
then translated into usable information about the key for use with the
next segment - which could be correlated with the fact that what it is
used to encipher is also plaintext.
With a normal block cipher like DES, one needs a lot of known
plaintext under one key to learn a few bits of the key. Here, though,
we have to learn something about the key that is useful from a *tiny*
piece of plaintext.
Then we have to take what we've learned, and use it to learn something
useful about the plaintext from an additional ciphertext block -
because that plaintext is the random value that is the key for the
next segment.
Only then - once we've carried forwards something we've learned from
our first inadequately long plaintext - have we connected more than
one block of plaintext, and only then do we have enough plaintext
involved in the analysis to, even in theory, solve for the key.
We have to involve multiple segments in any cryptanalysis, but the
segments are linked in a way that seems - subjectively perhaps - to
make linking multiple segments together and working with them
analytically to find the key *very* difficult, unless the block cipher
and its key schedule are _both_ very poorly designed.
For example, this cipher would still be secure if the block cipher
involved had a low resistance to differential and linear
cryptanalysis, but the key schedule was such that decryptions
performed on the same block by related keys had no usable
correlations.
I view this as belonging to the same family as "message splitting",
where one sends, under two different keys, (and preferably in two
structurally different, but both secure, cipher systems)
message 1: plaintext message XOR random bits
message 2: random bits
Under each key, only random data is sent, so neither half of the
message can be attacked by itself. The kind of attack required is
something that can use differentials between encryptions under
different keys. Again, this seems, at least subjectively, to make all
the simple attacks much harder. Of course there may still be attacks,
but it seems as though the requirements for known plaintext will be
much larger.
The question that would be very *nice* to be able to answer about both
of these systems, with their bandwidth costs, is whether (for the
brute-force infeasible case, so the meet-in-the-middle attack is not a
concern) they have an advantage over double encryption.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
** 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
******************************
