Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #14Sat, 7 Apr 01 04:13:01 EDT
Contents:
Re: Data dependent arcfour via sbox feedback ("Bryan Olson")
Re: Dynamic Substitution Question (David Formosa (aka ? the Platypus))
Re: Would dictionary-based data compression violate DynSub? (David Formosa (aka ?
the Platypus))
Re: Delta patching of encrypted data ("Bryan Olson")
Re: rc4 without sbox swapping/updating (Terry Ritter)
Re: Would dictionary-based data compression violate DynSub? (Terry Ritter)
Re: Dynamic Substitution Question (Terry Ritter)
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Data dependent arcfour via sbox feedback
Date: Sat, 07 Apr 2001 06:24:00 GMT
In article [EMAIL PROTECTED], Terry Ritter wrote:
On Wed, 04 Apr 2001 19:53:09 -0700, in
[EMAIL PROTECTED], in sci.crypt Bryan Olson
[EMAIL PROTECTED] wrote:
Bryan Olson wrote:
Terry Ritter wrote:
The "second data source" is modified by said "result data" before use,
but no part of the claims excludes that possibility.
The word "source" excludes the possibility. The sequence of
y values is in fact a _product_ of the substitution process,
not a source. If unclear of the interpretation of "source",
just read the background and look at the diagrams in the
patent.
Any sequence of data values is "a source." We can see this
throughout the patent, including: "A first data source and
a second data source are combined into a complex
intermediate form or result. . . ." Note the lack of
description about the "ultimate" origin of any data sequence
treated as a "source."
It may be any sequence of values, but it must be a source,
not a product. Neither does the ultimate origin matter;
just that it comes in from the outside.
The ultimate origin is of course outside *the* *combiner*, but not
necessarily outside the system containing the combiner.
The source in question is produced _from_ the table as the
"combiner" updates it.
When you present a system which is more than just the combiner, I am
free to select what signals there are and try to match them to a
claim. You don't get to decide what signals I select. You can add
whatever you want around an invention in an attempt to obscure which
parts actually constitute the invention, but the invention is still
there somewhere, and I get to find it.
Exactly. The sequence _you_ chose depends upon the dynamic
update of the table. It is necessarily a function of the
combiner, and cannot be outside.
But, if you don't like the word "source," perhaps you would
prefer the word "value": [...]
Which is not the word in the claim at issue.
It only takes one claim. Any claim counts.
The one you had cited is claim 1. If you want to instead go
through claim 15, note that it's not only a "value" it's an
"input value". Claim 15 also states one output, and if you
use that value for the output, the cipher cannot function.
[...]
doesn't the following
algorithm fulfill the description from claim 1? How about
claims 2, 7 and 8?
Assume a (pseudo) random data source S
initialize T[0..k-1] to hold 0..k-1
for i in 0..k-2
j = S.next() scaled/shifted to be in i..k-1
output T[j]
swap(T[i], T[j])
I'm not happy with any mechanism claimed to be Dynamic
Substitution being inherently limited to a sequence of a
particular length.
Didn't you recently write:
| The appropriate way to check for infringement is to take
| the actual words from a claim and try to fit them to the
| design being checked.
What you are happy with doesn't enter into it. Why do you
not apply the same standard here that you stated previously?
As far as I can see, the standard is the same.
From "actual words from a claim" to what you are happy with
is a huge change.
The body of the patent is used as a dictionary to interpret the
meaning of words used in the claims. I have quoted several times
where it does not support your interpretations.
You have quoted such zero times. I never said it couldn't
be used to combine confusion sequences, or the various
things you cited.
It is implied throughout the patent body that there is no such
limitation.
What text from claim 1 implies that? How about claims 2, 7
and 8? Didn't you also write:
It doesn't matter. Any one claim counts. It is only necessary for
all aspects of any one claim to be satisfied for a design to read on
the claim.
Agreed. But you have no such claim.
Dependent claims further restrict the claim upon which they depend.
In this way, dependent claim 2 thus further restricts independent
claim 1.
Of course.
The reason for this is to accommodate newly-found prior
Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #13Sat, 4 Nov 00 20:13:00 EST
Contents:
Generalized Playfair ("r.e.s.")
Re: hardware RNG's (David Schwartz)
Re: Randomness from key presses and other user interaction (Terry Ritter)
Re: Randomness from key presses and other user interaction (Terry Ritter)
Protocol (David Wagner)
Re: Randomness from key presses and other user interaction (David Schwartz)
Re: Randomness from key presses and other user interaction (David Schwartz)
Re: Known-plaintext attack on chaining modes (was Re: Give it up?) (Tom St Denis)
Re: very large mult. div. ([EMAIL PROTECTED])
Re: Brute force against DES ("John A. Malley")
Re: Spanish Language Data (Roberto Santilli)
Re: BENNY AND THE MTB? ("Matt Timmermans")
From: "r.e.s." [EMAIL PROTECTED]
Subject: Generalized Playfair
Date: Sat, 4 Nov 2000 14:12:42 -0800
(This is partly in response to a recent thread that asked
about 3-dim Playfair.)
Here's a procedure that generalizes the Playfair cipher to
use an arbitrary number of alphabet squares (say M squares),
and also generalizes further to d-dimensional arrays of an
alphabet, with d=1,2,3,... (I don't know whether this method
is already in the literature.)
The generalization described first, which is for d=2, reduces
to ordinary Playfair when M=1, and reduces to the so-called
Two Square cipher when M=2.
The method for d=2, and arbitrary M (=1,2,...), is this:
(1) Use an alphabet that can be arranged into a square of
letters (e.g. 5 x 5)
(2) Make M such squares, each with a different permutation
of the same alphabet, and lay out the squares side-by-side
in a row, with all the rows aligned. (E.g., if the squares
5 x 5, this will make a 5 x 5M table.)
Suppose the plaintext is "abcde...", and the ciphertext is
"ABCDE...", where "A" simply stands for the encipherment
of "a", also being some letter in the plaintext alphabet.
Let's omit seriation, which could, however, also be done.
(3) Break the plaintext into groups of M letters
(M=#squares), padding the last group if needed.
Some examples for M=3 are
"abc def ..." = "an example" = "ane xam ple"
"abc def ..." = "padding" = "pad din gxx"
(4) Encipher one group at a time, treating it as a circular
sequence of overlapping letter-pairs (e.g. for M=3, "abc"
is seen as ab-bc-ca). Each letter of a group is enciphered
as the first half of an ordinary Playfair digraph of which
it is the first letter, while cycling through the M squares
in succession.
More precisely, define the notation ab(ij) as follows:
ab(ij) = the element in the j-th square,
that's in the same *row* as "a" of the i-th square,
and in the same *column* as "b" of the j-th square;
if "a" and "b" are in the same row, then take the
element to the right of "b" (regarding the first
letter in a row of any square to be to the "right"
of the last letter of that row).
Thus, taking M=3 to illustrate:
Encipher "abc def ..." - "ABC DEF ..."
according to
a - ab(12) = A
b - bc(23) = B
c - ca(31) = C
d - de(12) = D
e - ef(23) = E
f - fd(31) = F
etc etc
(5)
Decipher "ABC DEF ..." - "abc def ..."
according to
A - AC(21) = a
B - BA(32) = b
C - CB(13) = c
D - DF(21) = d
E - ED(32) = e
F - FE(13) = f
etc etc
Example (M=3, plaintext="an example")
1 2 3
= = =
dhtrl ctilg nerio
bqxus jbxrh suaht
kaicm siodx vdbmw
nejgo wmnfy fkyjg
fvpyw pvqak cqxpl
Encipher: ane xam ple - okh rpi art
ane - okh
according to
a - an(1-2) = o
n - ne(2-3) = k
e - ea(3-1) = h
as shown:
1 2 3
= = =
dherio
bqxus jbxrh suaht
ka--odx vdbmw
nejgo wmnkyjg
fvpyw pvqak cqxpl
Similarly,
xam - rpi:
1 2 3
= = =
dhtrl ctilg nerio
bqx--rh suaht
kai-mw
nejgo wmnfy fkyjg
fvpyw pvqa-pl
ple - art:
1 2 3
= = =
|---|
dhtrl ctil---erio
bqxus jbxrh suaht
kaicm siodx vdbmw
nejgo wmnfy fkyjg
fvp--ak cqxpl
Decipher:
okh rpi art - ane xam ple
okh - ane
according to
o - oh(2-1) = a
k - ko(3-2) = n
h - hk(1-3) = e
rpi - xam
r - ri(2-1) = x
p - pr(3-2) = a
i - ip(1-3) = m
art - ple
a - at(2-1) = p
r - ra(3-2) = l
t - tr(1-3) = e
==
Further generalizing the above method to d-dimensional arrays
of an alphabet, with d=1,2,3,..., is straightforward.
For example, with d=3, an alphabet is arranged into a cubic
array, and M such cubes are placed side-by-side. Take the case
of M=2 for example: A digraph "ab" is such that the location
of "a" in cube#1 defines in that cube a square of letters lying
in a plane "facing" the ne
Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #12 Sat, 24 Jun 00 11:13:01 EDT Contents: Re: Algo's with no easy attacks? (Simon Johnson) Re: Questions about RSA. (David Blackman) Re: security problem with Win 2000 Encryption File System (Simon Johnson) Re: Questions about RSA. (Simon Johnson) Re: exponentiation (tomstd) Re: Encryption 4 the Masses? (tomstd) Re: Encryption 4 the Masses? (Simon Johnson) Re: Encryption 4 the Masses? (tomstd) Re: Compression Encryption in FISHYLAND (tomstd) Re: Algo's with no easy attacks? (tomstd) Re: Algo's with no easy attacks? (tomstd) Re: Variability of chaining modes of block ciphers (Guy Macon) Re: XOR versur MOD (Richard Outerbridge) Re: Comments please: A protocol for Digital voting (Roadkill) Re: how to compare the securtity between ECC and RSA (DJohn37050) Re: DH - Man In The Middle (DJohn37050) How Close? (Future Beacon) Simple Key Escrow (tomstd) Re: How Close? (tomstd) Re: Encryption 4 the Masses? (Troed) Subject: Re: Algo's with no easy attacks? From: Simon Johnson [EMAIL PROTECTED] Date: Sat, 24 Jun 2000 02:12:24 -0700 Yup, Most ciphers have no *easy* attacks, but they can usally be attacked in some way, shape or form. The real question is your definition of easy, is a requirement of 2^62 known plain-texts an easy attack? Really, i can only invisige that the One Time Pad is the only attack-less cipher out there. Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com -- From: David Blackman [EMAIL PROTECTED] Subject: Re: Questions about RSA. Date: Sat, 24 Jun 2000 19:24:53 +1000 Simon Johnson wrote: Just a quick point, VB is pants for RSA, i can never generate a public-private key pair with a modulo greater than 32-bit. Out of intrest, does anyone know a way of computing large numbers in VB. Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com Did you learn the algorithms "long multiplication" and "long division" at primary school? It is actually possible to implement them in VB, though probably not much fun. Good luck. -- Subject: Re: security problem with Win 2000 Encryption File System From: Simon Johnson [EMAIL PROTECTED] Date: Sat, 24 Jun 2000 02:22:54 -0700 I don't know how that system works, but if one wants to create an encrypted file system, any data which is ever stored to that disk should NEVER be unencrypted, or else you always can get that data back, no matter if it was wiped or not. I aggree with this statement, however, if you have no choice. Wiping the deleted file down with a several-passes of a pseudo random number generator, is a good substiute. Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com -- Subject: Re: Questions about RSA. From: Simon Johnson [EMAIL PROTECTED] Date: Sat, 24 Jun 2000 02:26:53 -0700 Outch. That's all i have to say.. I don't fancy doing that :) Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com -- Subject: Re: exponentiation From: tomstd [EMAIL PROTECTED] Date: Sat, 24 Jun 2000 04:27:02 -0700 Yen-Choon Ching [EMAIL PROTECTED] wrote: tomstd wrote: Yen-Choon Ching [EMAIL PROTECTED] wrote: Hi, Can someone tell me how fast can we do an exponentiation on a 8- bit smart card for the following parameter: p = 1024 bits, q = 160 bits Does it need a crypto processor? I assume this is in the field of integers modulo a prime? Then I would suggest a math-copro if speed is a requirement otherwise a compact multiply-square can get it done in a *resonable* amount of time without serious code-bloat. What's reasonable without a crypto processor? Under 1 second? I would think with a 11mhz AVR MCU you could do a exponentiation like that in under a second. This would be ideal for logins and authentications. You wouldn't use a software only MCU device todo realtime PK crypto... Tom Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com -- Subject: Re: Encryption 4 the Masses? From: tomstd [EMAIL PROTECTED] Date: Sat, 24 Jun 2000 04:27:41 -0700 "Pig Ear" [EMAIL PROTECTED] wrote: Is this program any good? Has it stood up to the scrutiny of the crypto community? What program? PGP? Tom Got questions? Get answers over the phone at Keen.com. Up to 100 minutes free! http://www.keen.com -- Subject: Re: Encryption 4 the Masses? From: Simon Johnson [EMAIL PROTECTED] Date: Sat, 24 Jun 2000 04:31:40 -0700 tomstd [EMAIL PROTECTED] wrote: "Pig Ear" [EMAIL PROTECT
Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #11 Fri, 11 Feb 00 16:13:01 EST
Contents:
Re: "Trusted" CA - Oxymoron? (Sander Vesik)
Re: Newbie Encrypt question (Jerry Coffin)
Re: Using Gray Codes to help crack DES (Paul Schlyter)
Re: NSA opens up to US News (Email forms are lame)
Re: Have you watched the movie "PI" (actually a mathematical symbol PI) of a
mathematical genius .. breaking the code .. ("Androcles")
Re: help DES encryption (Hideo Shimizu)
Re: UK publishes 'impossible' decryption law (Mike Eisler)
Re: I'm returning the Dr Dobbs CDROM ([EMAIL PROTECTED])
Re: Message to SCOTT19U.ZIP_GUY ("Peter K. Boucher")
Re: I'm returning the Dr Dobbs CDROM (Paul Koning)
Re: Guaranteed Public Key Exchanges (Paul Koning)
Re: Period of cycles in OFB mode (Paul Koning)
Re: encryption export question (Paul Koning)
From: Sander Vesik [EMAIL PROTECTED]
Crossposted-To:
alt.privacy,alt.security.pgp,comp.security.pgp,comp.security.pgp.discuss
Subject: Re: "Trusted" CA - Oxymoron?
Date: 11 Feb 2000 20:07:56 GMT
In sci.crypt Brian Hetrick [EMAIL PROTECTED] wrote:
"Sander Vesik" wrote...
snip
Aha. I see your point. But completely delinking from the known is,
I suspect, impossible.
Incidentally, getting a circle of false notaries is a little more
cumbersome than you describe: you need to be a notary before you can
make an identity assertion. You would need a minimum of 5 identities
going through a minimum of three notarizations each to get a circle
of notary identities sufficient to get Thawte to issue a certificate
in the name of a completely fabricated identity. (An identity
assertion is specific to a notary/asserted identity pair; a new notary
can issue only 10 identity points; a notary can issue a maximum of 35
points; a minimum of 50 points is needed for an identity to be
considered "verified;" a minimum of 100 points is needed to become a
notary.)
An attempt to verify the fabricated identity would fail, of course, as
No. It would not. It would just point at another person whose face
looked different, who possibly never had even used a computer and
who has a good alibi. A false ID that didn't verify is no good.
in the described scenario all the "notaries" would have been frauds.
But the second generation notaries -- the minimum of three "good
faith" notaries -- would have copies of the falsified identity
documents of the five fradulent notary identities. While the names,
addresses, document serial numbers, and so forth, on the falsified
documents might not be of any use, the photographs are known good --
the notaries made sure they bore a "reasonable resemblance" to the
actual persons appearing before them.
How much does it cost to have a druggy go and get himself set up as a
notary using false ID?
Get a fresh asian immigrant / inner city youth to get the notary papers
and then sell them to me?
So at least you have a collection of photographs of the person(s)
involved in the fraud, at least if the fraud is detected within five
years of it starting.
Which are probably no good. It helps only against a very small and very
undetermined adversary.
To get two or more generations of fraudulent notaries, you would
need to start with ten identities, rather than five, as you would need
ten new notary identity assertions to get enough identity points to
create a notary.
And I would not doubt Thawte is watching the patterns of which
notaries are asserting which identities, with an eye to catching
exactly such attempts to build fraudulent identities. If they weren't
before, they certainly are now. :-)
Good to hear. but if you don't want a whole second gen ring, it is a
lot harder to note. Unnoticeable second gen notaries are just slightly
more expensive than those in whose case a slight suspicion might rise.
But the whole second gen. ring is not needed. you need just some second
gen notaries.
On the whole, I suspect it would be simpler to get one set of fake
IDs than five -- and simply going to "good faith" Thawte notaries
to get a minimum of two identity assertions with a single fake ID is
substantially easier than going to "good faith" Thawte notaries a
minimum of fifteen times with five fake IDs, or thirty times with ten
fake IDs.
Assuming the selection of the Thawte notaries is wide enough and that
they are sufficently apoart geographically, that's no problem. The scheme
can work in parallel and there is no way - at the time it is done -
to in any way say that some kind of (future) fraud is involved.
The only advantage of creating fradulent notaries as a step in
creating a fradulent identity is that the fradulent identity does not
have an accessable photograph on file. But, of course, the
photographs of the person(s) involved
Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #10 Mon, 23 Aug 99 17:13:03 EDT Contents: Re: Clerification of Crypto Export Laws (John) Re: CBC problems... (David A Molnar) Re: How does RC4 work ? (Tom St Denis) US export laws re Canada (dave) Re: How does RC4 work ? (David A Molnar) Re: IDEA in Applied Crypto (Stephan Eisvogel) Re: question regarding number of keys possible. . . (John Savard) Re: NIST AES FInalists are (David Wagner) Re: Attacks on RC4 ? (Tom St Denis) Re: NIST AES FInalists are (David Wagner) Re: NIST AES FInalists are (David Wagner) Re: Blowfish algorithm - Is it full proof? (Jim Dunnett) Re: Human-Readable Encryption (Newbie) (Jim Dunnett) Re: MUM (David Wagner) Re: Cryptomathic Denamrk (Bob Silverman) Re: I need strongest weak elliptic curve... (Greg) Re: CBC problems... (Anton Stiglic) Re: Unconcealed messages in RSA (Anton Stiglic) Re: Human-Readable Encryption (Newbie) (John Savard) From: John [EMAIL PROTECTED] Subject: Re: Clerification of Crypto Export Laws Date: Mon, 23 Aug 1999 10:57:01 -0700 I will grant that scenario can occur. The truth is, if you have connections, money, they'll leave you alone. http://www.aasp.net/~speechfb ps It would be hard to argue thatin court. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free! -- From: David A Molnar [EMAIL PROTECTED] Subject: Re: CBC problems... Date: 23 Aug 1999 18:25:45 GMT Anton Stiglic [EMAIL PROTECTED] wrote: Your not the only one to have asked stupid questions here! :) seconded. Indeed, stupid questions sometimes lead to interesting pointers. I am very thankful to the person who suggested looking at other methods for generating provable primes after I mistakenly thought n! + 1 was prime... -David -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: How does RC4 work ? Date: Mon, 23 Aug 1999 18:52:34 GMT In article [EMAIL PROTECTED], Paul Crowley [EMAIL PROTECTED] wrote: "Georg Zetzsche" [EMAIL PROTECTED] writes: Does anybody know, how the RC4 - encryption algorithm works ? It's AFAIK the simplest strong cipher in the world. Ciphersaber (an RC4-based cryptosystem) provides a good description: http://ciphersaber.gurus.com No offense but is that a plug? RC4 is so simple you could explain it here no need to advertise. BTW RC5 is really simple as well... so is Blowfish, TEA, X-TEA :) Tom -- PGP 6.5.1 Key http://mypage.goplay.com/tomstdenis/key.pgp PGP 2.6.2 Key http://mypage.goplay.com/tomstdenis/key_rsa.pgp Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. -- From: dave [EMAIL PROTECTED] Crossposted-To: talk.politics.crypto Subject: US export laws re Canada Date: Mon, 23 Aug 1999 19:13:38 GMT According to two articles in "Canadian Machinery and Metalworking", the USA passed amendments to the InternationalTraffic in Arms Regulations in April of this year that revoked Canada's exemption from this regulation. The CMM writers stress that this effects any technology or data that might conceivably be applied to military use will now require export permits. Canadian defense contractors are experiencing clearances on quotation details that take longer than the open time on the request for quotations, and can't even enter a bid. This seems to be applied to manufactured goodies, electronics, aircraft parts, etc, but would probably apply to the "strong" encryption products, too. Anyone up here tried to open a computerised bank account recently? I think they need the strong encryption...and I recall "swearing" that I was a Canadian citizen when I set one up some time ago before I could down-load the bank's package. Anyone know anything more about this gem? Dave -- From: David A Molnar [EMAIL PROTECTED] Subject: Re: How does RC4 work ? Date: 23 Aug 1999 19:07:29 GMT Tom St Denis [EMAIL PROTECTED] wrote: http://ciphersaber.gurus.com No offense but is that a plug? RC4 is so simple you could explain it here no need to advertise. Check out the site - it's based on that fact. : -- From: Stephan Eisvogel [EMAIL PROTECTED] Subject: Re: IDEA in Applied Crypto Date: Mon, 23 Aug 1999 21:03:22 +0200 Tom St Denis wrote: So I will ask, does anybody know of any errata from the IDEA C code from Applied Crypto? I recently messed around with side-channel attack papers to harden some of my own code against it. You can go to http://www.ascom.ch/infosec/downloads.html and download the revised IDEA 2.1 code. There's also plenty of test vectors to verify your code against. If decryption doesn't return the plaintext you started with, check for byte-ordering bugs. My f
Cryptography-Digest Digest #99
Cryptography-Digest Digest #99, Volume #9Thu, 18 Feb 99 00:13:03 EST
Contents:
Re: Foiling 56-bit export limitations: example with 70-bit DES ([EMAIL PROTECTED])
Decoding messages from ETI. ("WhiteHat")
Re: Current status of Sarah Flannery's New PKC ?? ("Bruce Christensen")
Re: Testing Algorithms (fungus)
Re: True Randomness (fungus)
Re: New high-security 56-bit DES: Less-DES (Bryan Olson)
Cyclic attack on RSA ("HypSoft")
Windoze encrypts phone number? ("Bruce Christensen")
Re: True Randomness ("Douglas A. Gwyn")
Re: Protecting Against Replay Attacks With Nonrandom IV (Bryan Olson)
Re: Telephone Encryption ("Roger Schlafly")
From: [EMAIL PROTECTED]
Subject: Re: Foiling 56-bit export limitations: example with 70-bit DES
Date: Wed, 17 Feb 1999 23:06:06 GMT
In article 79n6ld$96b$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
In article 79j465$4ej$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
[snip]
Ok -- actually, much more effective, 2^56 times more effective for DES.
I think it's closer to 2^(M-1) times more effective.
Peter: {sorry for the delay in replying]
;-) no, we went thru that before... a couple msgs ago in this very thread...
where I proved what I just quoted above. Pls check that, the workload factor
is approximately 2^56 counter the attacker.
[snip]
If Mike knows
STOP 1: No, not possible.
How does Mike know? How can he be sure that the DES key AND the message are
repeated if the unknown_key is different? Note: what DES key, what message?
The only thing Mike can see are two entirely DIFFERENT byte strings C1 and
C2 -- and, what could he rationally deduce from two entirely different and
random-looking strings?
When analyzing a cipher system, it is common practice to harden it against
impractical attacks (e.g., chosen-plaintext). Furthermore, you said that
M-DES could be implemented by adding the M-layer to any DES implementation,
in which case, you cannot control whether or not they might send the same
message twice with the same DES key, and you can't know if, or how, Mike
might know if this had happened.
;-) If you send the *same* msg twice with the *same* DES key and the *same*
unknown-key from M-DES I guess we can agree that nothing is gained regarding
that msg's content by any attacker, no? He will just see two equal ciphertexts
C1 == C2.
The point I made above is however different -- if you see two *different*
ciphertexts C1 and C2, then you have no basis to even guess anything from two
such random-looking msgs. That is why you cannot say "If Mike knows" ... when
we all know Mike knows nothing.
[snip]
STOP 2: No, nigh-impossible.
;-) Note that I was a bit "perverse" in my reply to you -- since I have been
repeating this point but without being able to convey it, so I tried a more
graphical way. Note that my previous text (that you quoted above) says
specifically: "-- of course, using the protocol given in
http://www.mcg.org.br/unicity.htm" ... thus, what does the M-DES protocol
say? Surely this question must be asked, since you cannot say M-DES has a
weakness if you provide Bob and Alice with a de-faced M-DES -- so, the given
M-DES rules MUST be followed. At the given URL, it is written:
You can't force them to use your protocol if you implement the M- as a package
that will work with other people's DES.
Note that DES key-collision is also and mainly a problem for the DES-package.
Thus, it is that package which must and will ensure that DES keys are truly
chosen at random -- on which I can rely to the same extent that I trust that
DES-package. This has nothing to do with M-DES... which, of course, benefits
from it and relies on the user to choose a good-enough DES-package.
[snip]
if you a) use a block cipher for the post-encryption,
There is a subtle point here, which I believe was not properly stressed. Can
you trust that block cipher? Can you guarantee it has no back-doors? The
answer is of course NO in both cases.
You may have a point. There's also the "meet in the middle" attack to
consider.
However, can you trust an XOR to be an XOR? Can you guarantee it has no
back-doors? Clearly, YES in both cases.
No. I don't know how you chose your table of 2^M publically known "unknown
keys."
They have by definition no back-doors since they *are* publicly-known and
they are simply numbers with no "code". For example, they can be the first
2^M 64-bits numbers from a suitably large Mersenne prime for example -- that
can be very compactly specified as 2^N - 1 and known worldwide.
You are arguing that if I 1) publish a table of 16384 "random looking" 64-bit
blocks, 2) choose one of the blocks by generating 14 random bits, and 3) XOR
the block I chose with each b
