Cryptography-Digest Digest #269, Volume #12 Sat, 22 Jul 00 10:13:00 EDT
Contents:
Re: On block cipher and automata (Mok-Kong Shen)
Re: Q: Cascading multiple block algorithms (Mok-Kong Shen)
Re: Question Regarding Encrypting CD-ROM -RW Disks ("zombywuf")
Re: md5 uses, questions (Ichinin)
Re: Random Appearance (Future Beacon)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block cipher and automata
Date: Sat, 22 Jul 2000 10:19:16 +0200
Bryan Olson wrote:
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> > > The large block is not really necessary. We could use most
> > > of the same randomness across multiple blocks, while mixing
> > > in a little new randomness with each.
> [...]
> >
> > You are right. One can reserve space in the block for the random
> > bits and put into the block correspondingly less number of plaintext
> > bits.
>
> But that's beside the point. You can have much more
> randomness in each block than that the amount of reserved
> space, by re-including randomness from previous blocks.
>
> > The following scheme should also work:
> >
> > Let n = cipher block size, P_i = ith plaintext block with n-b bits,
> > R_i = ith random bit block with b bits, C_i = ciphertext block with
> > n bits. Algorithm:
> >
> > K= given key; R_0 = 0; i=0;
> > do
> > i=i+1;
> > K = K + R_(i-1) mod 2^n;
> > C_i = E(K, P_i || R_i);
>
> That seems like a waste. With one random bit per block,
> after 100 blocks there are 100 possible values for K (given
> the original K) and the middle one's are most likely. For
> the same price you could have gotten 2^100, all equally
> likely.
Yes. I intended to illustrate in an easily visible manner how the
random bits can be transmitted without modifying the block size.
I believe that dynamic (random) control informations for the
encryption process are relatively infrequently needed. In other
words, one can send these in intervals of a fixed or pseudo-randomly
determined number of blocks, so that these are sent in entirely
distinct blocks, i.e. no re-blocking of plaintext is necessary. This
way the implementation is simplified.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Cascading multiple block algorithms
Date: Sat, 22 Jul 2000 10:19:07 +0200
Mok-Kong Shen wrote:
> In Schneier's AC, p.367, about cascading two block ciphers it
> is stated:
>
> If the second algorithm is vulnerable to a chosen-plaintext
> attack, then the first algorithm might facilitate that
> attack and make the second algorithm vulnerable to a known-
> plaintext attack when used in a cascade.
Perhaps I may explain what difficulty I have in reading the
sentence above. The premise 'If the second algorithm is
vulnerable to a chosen-plaintext attack' means (to me) that,
if its (direct) input can be chosen, then it can be cracked.
Now that input is the output from the first algorithm. It
cannot be directly chosen but only indireclty through choosing
input to the first algorithm. This indirectness, assuming that
the first algorithm has any strength at all, evidently means
that the said attack is now more difficult. Given this fact,
I can't understand the phrase 'the first algorithm might
facilitate that attack', which I interpret to be the claim
that the said attack has now become easier (i.e. easier than
directly choosing input to the second algorithm). Finally I
then can't understand 'make the second algorithm vulnerable
to a known-plaintext attack'. For I can't see what this
'known-plaintext' refers to. It can't refer to the input to
the second algorithm, because that's the output of the first
algorithm and is not 'known', unless the analyst has already
cracked the first algorithm. If it is the input to the first
algorithm, then it is also senseless, since we have in the
above already assumed that the analyst can choose input to
the first algorithm so that he can obtain some (for him) more
advantageous input to the second algorithm. (Assuming chosen-
plaintext includes assuming known-plaintext, isn't it?)
I don't exclude that my inability of comprehension is simply
a result of my poor English language competence. You help will
be sincerely appreciated.
M. K. Shen
------------------------------
From: "zombywuf" <[EMAIL PROTECTED]>
Subject: Re: Question Regarding Encrypting CD-ROM -RW Disks
Date: Fri, 21 Jul 2000 17:57:25 +0100
**** Post for FREE via your newsreader at post.usenet.com ****
Microwaving CDs has a tendancy to release hydrogen cyanide and leaves the
data pretty much intact. However five minutes with some fine grain sandpaper
on the patterned side gives you a rather attractive coaster. Of course fire
is the best bulk disposer. Industrial incinerators may not be safe, depends
on how paranod you are, but a cutting torch works wonders.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
*** Usenet.com - The #1 Usenet Newsgroup Service on The Planet! ***
http://www.usenet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: md5 uses, questions
Date: Sat, 22 Jul 2000 14:41:59 +0200
Arthur Dardia wrote:
> The server, when receiving this
> output (hashed with the one-time session), won't be able to determine if
> it's a valid hash.
it will (but...)
Server A generates random value (C)
Server A sends value to client
Client B Generates the hash: FileData + C (H)
Client B now send (H) to server
Server A generates the internal hash of FileData + value (I)
Server A Compares H and I
...but as joseph showed, this protocol is flawed and doesn't work anyway
:o)
.Regs
Glenn
------------------------------
From: Future Beacon <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Sat, 22 Jul 2000 09:00:20 -0400
On 22 Jul 2000, Mack wrote:
> >
> >I forgot about pictures. It seems that merely diluting the message
> >would be possible, but I am thinking that a dense message that
> >wastes no characters might seem orderly but not be the oder which
> >is the intended message. If the ciphertext seemed to be a plausible
> >English message but was not the message and was only about as long
> >as the real message and was cryptographically strong, that would
> >qualify. I don't know if there are other approaches. As I
> >indicated in my question, I certainly don't know if anybody has
> >succeeded in such a thing.
> >
> >
> >Jim Trek
> >Future Beacon Technology
> >http://eznet.net/~progress
> >[EMAIL PROTECTED]
> >
>
> Actually this is more like the old code book ciphers. Which result
> in messages such as the classic "Father is deceased"
> while "Father is dead" would actually mean something else.
>
> Of course such systems are more like OTPs. They are
> subject to known plaintext attacks.
>
>
> Mack
> Remove njunk123 from name to reply by e-mail
>
There is also the possibility of teams of people writing obliquely
to each other through each other in messages that are fragmented and
assembled from a month's worth of transmissions, if timing isn't
urgent. In such a setting, random numbers could be received as data
and later XORed with some news group message about flowers to get
the next patent page.
Perhaps we have hardly scratched the surface. Is it worth
exploring?
Thanks for helping out.
Jim Trek
Future Beacon Technology
http://eznet.net/~progress
[EMAIL PROTECTED]
------------------------------
** 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
******************************
