Cryptography-Digest Digest #178, Volume #13 Fri, 17 Nov 00 17:13:00 EST
Contents:
Re: Hitachi - on what grounds ?? (Terry Ritter)
Re: vote buying... (David Schwartz)
Re: vote buying... (David Schwartz)
Re: vote buying... (David Schwartz)
Re: [Question] XOR encryption (David Schwartz)
Re: DES question: Has this ever been proven before? (Bill Unruh)
Re: Q: fast block ciphers (David Schwartz)
Re: Q: fast block ciphers (David Schwartz)
Re: DES question: Has this ever been proven before? (David Wagner)
Re: help on user authentication protocol (David Wagner)
Re: vote buying... (Dan Oetting)
Re: DES question: Has this ever been proven before? (John Myre)
Re: Why remote electronic voting is a bad idea (was voting through pgp) (George
Weinberg)
Re: help on user authentication protocol (Mike Rosing)
Re: Why remote electronic voting is a bad idea (was voting through pgp) (Dan Oetting)
Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS (Scott Craver)
Re: help on user authentication protocol ([EMAIL PROTECTED])
Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom (Andre)
Re: [Question] XOR encryption ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 17:26:43 GMT
On Fri, 17 Nov 2000 14:36:54 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Fri, 17 Nov 2000 00:55:21 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>http://www.io.com/~ritter/PATS/VSBCPAT.HTM
>
>Although this appears to be a patent on a particular means of
>achieving a variable block size, it seems to cover one particular
>technique which I would tend to call the "lazy man's cipher".
>
>Suppose a programmer is faced with the problem of encrypting a string
>to another string of the same length, using another string as the key.
>
>But the programmer knows that Vigenere is insecure. (He may be writing
>the subroutine to replace one that uses Vigenere in an existing
>programming environment!)
>
>An obvious technique would be the following:
>
>Use the key string as an S-box. (essentially, repeat it to fill a
>255-character, or 95-character, or whatever, table - but use a mod
>function instead)...
>
>Let N be the length of the string to be enciphered.
>
>Pass 1:
>For I from 2 to N, replace plain(I) by plain(I) + S( plain(I-1) ).
At first glance, that does not seem to be a good pattern for a block
cipher: a bit-change in plain(i) apparently affects only cipher(i) and
cipher(i+1). That is not good diffusion.
>From the patent:
"One Way Diffusion
In the context of a block cipher, a one way diffusion layer will
carry any changes in the data block in a direction from one side of
the block to the other, but not in the opposite direction. This is the
usual situation for fast, effective diffusion layer realizations.
In the context of a variable size block cipher, one way
diffusion must conduct a change in one element to all succeeding
elements, no matter how large the block."
>Pass 2:
>For I from N-1 to 1, step -1, replace plain(I) by plain(I) + S(
>plain(I+1) )
>
>with various elaborations, such as subtracting instead of adding
>during some passes, or going from 3 to N and N-2 to 1, and including
>plain(I +/- 2), perhaps without the S-box, having more passes, say
>four or even six, and throwing in a Vigenere pass at some point.
Nevertheless, the diffusion distance appears to increase only linearly
with the number of "rounds." And here diffusion is tied to the number
of rounds, so expanding the block size either requires more rounds, or
accepting poor diffusion. I would not say that any of this supports
variable size blocks.
>At one point, a description of Scott16 suggested to me that it was
>based on something similar.
>
>This sort of technique, I suspect, is very commonly used
First of all, is this like my stuff? No.
Is it covered by the term "one way diffusion layer"? No.
Is it prior art? That is, is it published? Is it described in
Schneier? If not, why not, assuming it is "very commonly used"?
Have *you* used it? Do you know anyone who has? Exactly what is your
factual basis for "suspecting" that the cipher is "very commonly
used?"
>when a
>programmer wants a quick-and-dirty scrambling routine in an
>application where genuine security isn't considered to be required.
>Since it works like a Feistel round, there is no need to construct an
>invertible substitution table, which is what makes it very simple to
>do.
>
>But I'm not sure if the patent relates to what Rijndael does to
>achieve its variable block size; that depends, though, on the claims,
>which I didn't notice when I glanced at it.
As you may recall, I did ask for your personal opinion on this, and
you did assure me that none of the AES ciphers was following my path.
I had not studied those ciphers, and still have not, but I expect that
you were right.
A patent covers only what is described in the claims. The body is not
important, except to teach, or to define terms, or to become prior art
after publication.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Fri, 17 Nov 2000 09:36:01 -0800
"Trevor L. Jackson, III" wrote:
> > So long as you need the voter's help to check them, you can easily meet
> > both goals.
> Not quite. If the voter can prove the validity of his vote than a person
> threatening the voter can force him to reveal the validity token.
And he can equally well produce someone else's validity token.
> The only way to
> protect the voter is to permit him to present a fake validity token. But that
> conflicts with the fraud detection mechanism because it can be used to hide fraud.
How? So long as the same number of fake validity tokens are issued for
each candidate and the number of fake validity tokens is known, they
don't interfere with the fraud detection mechanism at all.
Again, all these arguments are based simply upon lack of imagination.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Fri, 17 Nov 2000 09:39:40 -0800
Paul Rubin wrote:
> To be more explicit about b), you might have to add:
> c) No voter can give evidence that s/he voted for or against any given
> candidate ("receipt-free").
So long as the receipt doesn't identify the particular voter, the
system doesn't have to be receipt free.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Fri, 17 Nov 2000 09:37:28 -0800
"Trevor L. Jackson, III" wrote:
> > The "anonymous receipt" as done by grocery stores fits that bill.
> > There is nothing on that cash register tape saying who bought these
> > items (unless you presented some sort of club card or credit card), but
> > presenting that receipt to the cashier is proof that yes, you did indeed
> > purchase this item that you're trying to return. All these votes could
> > be online, but without identifying information in the data, there's no
> > way to identify individual people.
>
> How does this prevent someone from demanding that a voter show his receipt?
The voter can present anybody's receipt. Since the receipts don't
identify who you are, I can post my voting receipt anonymously on the
Internet and anybody who wants to can show mine instead of theirs.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: [Question] XOR encryption
Date: Fri, 17 Nov 2000 09:34:00 -0800
Shri Desai wrote:
>
> Hi,
>
> If my key is equal or larger then the input text then can simple XOR
> of input text with key give me a good enough encryption?
Not if you ever use the same key more than once.
DS
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: DES question: Has this ever been proven before?
Date: 17 Nov 2000 17:49:28 GMT
In <8v34p2$8ra$[EMAIL PROTECTED]> Raphael Phan <[EMAIL PROTECTED]> writes:
>Hmm... John, you are positively sure that a certain DES plaintext XOR
>would not cause the same ciphertext XOR? Are there any references
>(papers, reports...) where it has been explicitly stated that such a
>situation won't happpen?
Why would you think it would? For one thing, DES shuffles the bits
around, and thus the XOR would be different even if that was all it did.
For another, it is highly non-linear-- ie the xor of the F(R)^L or
F(L)^R depends on the text in both the R and the L. Finally, The F
function through the S boxes has a very complicated dependence on the
input. One bit change in the input produces much more than one bit
change in the output. For all of these reasons, why would you expect the
input xor and the output xor to have any relation to each other?
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Fri, 17 Nov 2000 09:48:12 -0800
David Schwartz wrote:
> I got the impression this was for some sort of bulk device encryption,
> where blocks would typically be very large (at least 512 bytes).
I read back, my impression was incorrect. It looks like what he really
needs is a block cipher that's very key agile. Rijndael may well be his
best choice.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Fri, 17 Nov 2000 09:41:17 -0800
Paul Crowley wrote:
>
> Pranke wrote:
> > David Schwartz wrote:
> > > While a block cipher may be difficult to use as a stream cipher
> > > (actually, it's not hard to use but hard to be sure it's secure), any
> > > stream cipher can trivially be changed into a block cipher.
> >
> > I never have heared of the idea to use a stream cipher as a block
> > cipher, and I really would like to know how THAT should work ?
>
> I think David Schwartz is confused here, but oddly enough there are
> constructions that take a stream cipher and a hash function and return a
> block cipher. The catch is that they are large block ciphers: the
> minimum sensible block size is around 320 bits and at that size they're
> pretty slow, though they're fast for big blocks.
I got the impression this was for some sort of bulk device encryption,
where blocks would typically be very large (at least 512 bytes).
DS
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES question: Has this ever been proven before?
Date: 17 Nov 2000 17:53:45 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Paul Crowley wrote:
>It seems almost certain that there must exist *some* (K, X, Y) such that
>
>X XOR Y = DES_k(X) XOR DES_k(Y)
>
>though I think searching for one such tuple would be slightly slower
>than breaking DES keys by brute force
Irrelevant tangent: If for some reason you cared about finding such
a (K,X,Y), you could find one with 2^29 encryptions using birthday
paradox techniques. Fix an arbitrary k; re-write the equation as
X XOR DES_k(X) = Y XOR DES_k(Y);
generate 2^28 random values of X, and sort them by X XOR DES_k(X);
generate 2^28 random values of Y, sorted by Y XOR DES_k(Y); finally,
merge the two sorted lists and look for duplicates.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: help on user authentication protocol
Date: 17 Nov 2000 18:00:05 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
> 1. A->B: A
> 2. B->A: E_k(r)
> 3. A->B: E_r(k)
> where k is A's hashed password, and r is a random number selected by B.
This is subject to offline dictionary attacks. If a passive eavesdropper
intercepts a single communication, he can try all possible passwords and
see which ones fit the observed transcript. (If k' is your guess at the
password, let r' := D_{k'}(E_k(r)), then check that E_{r'}(k') = E_r(k);
if not, you can discard k'.)
Also, the notion of using r and k as both a plaintext and a key seems like
an ill-advised idea to me.
Finally, note that Bob never authenticates himself to Alice: a malicious
attacker pretending to be Bob can just replay an old E_k(r), and Alice won't
know that she's not talking to Bob. Whether this is a problem or not depends
on your application.
------------------------------
From: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Fri, 17 Nov 2000 11:03:53 -0700
In article <[EMAIL PROTECTED]>, "Trevor L. Jackson, III"
<[EMAIL PROTECTED]> wrote:
> Dan Oetting wrote:
>
> > To make this procedure electronic use public key encryption for the
> > envelopes and a digital signature for the electors signature.
> >
> > The envelopes can be opened and the ballots shuffled by a closed
> > machine
> > to protect the secrecy of the ballots. The process can be verified by
> > repetition, testing with sample ballots and public inspection of the
> > hardware and software. Only one layer of envelope may be necessary.
>
> Here the critical shuffling step must be performed in obscurity. Not the
> same thing. Not only must it be secret, the actual shuffling must also
> be
> unrepeatable and unauditable.
When I typed that section my fingers kept wanting to type sort instead
of shuffle. I decided to use shuffle in the first message to preserve
the relation to the paper process, knowning that someone would point out
the security problem. Shuffling attempts to hide information of the
previous order while sorting completely removes the information and does
not add a covert channel to pass information out.
Also, the voters identification and digital signature are not used in
the opening process so this should be stripped from the sealed ballots
before processing.
The process of opening and sorting the ballots is repeatable in that it
can be performed as often as necessary using different hardware and
different versions of the software and the outputs should be exactly
identical.
> This requires too high a degree of trust. Could Microsoft(R), the NSA,
> or
> Crypto AG design software that appeared to be secure while actually
> violating the anonymity of voters? Worse, can we prove that they cannot?
This is why the software must be open source and run on common hardware.
You might be able to hide a trojan in the software if nobody is looking
for it. But when your output fails to match bit for bit with any other
valid version lots of people are going to look very closely at your code.
Is any current vote tabulation software open source?
The real crux that I see is the protection of the private key that opens
the ballots. Once the key is destroyed (and any internal state in the
hardware is erased) the anonymity of the vote is assured. How do you
prove to the public that an intangible private key has been destroyed
and no copies exist.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 11:31:15 -0700
David Wagner wrote:
<snip>
> generate 2^28 random values of X, and sort them by X XOR DES_k(X);
> generate 2^28 random values of Y, sorted by Y XOR DES_k(Y); finally,
> merge the two sorted lists and look for duplicates.
Um, why are there two lists? Wouldn't it be simpler to just
generate random X XOR DES_k(X) values until two were the same?
(I grant that an actual implementation would use tricks for
efficiency - but using two lists and only looking for duplicates
at the end doesn't seem like the right trick.)
JM
------------------------------
From: [EMAIL PROTECTED] (George Weinberg)
Crossposted-To: talk.politics.crypto
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Date: Fri, 17 Nov 2000 18:48:21 GMT
On 16 Nov 2000 22:00:40 -0800, Paul Rubin <[EMAIL PROTECTED]>
wrote:
>This subject is much harder than you think. Try typing "benaloh"
>and "receipt-free voting" into a search engine, to see some of the
>problems and an approach to solving them.
It's not a question of harder or easier.
It's an interesting technical challenge to develop a protocol which
guarentees
1) only registered voters can vote
2) votes can't be tampered with
3) nobody can vote more than once
4) nobody can tell who voted which way.
It's an interesting challenge, but good luck getting it implemented in
the real world even if you solve it. Too often, the people who are
overseeing elections have a vested interest in falsifying votes or
determining who voted which way.
George
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: help on user authentication protocol
Date: Fri, 17 Nov 2000 12:45:36 -0600
[EMAIL PROTECTED] wrote:
> But if, for example, C is trying to pretend to be B. The C, however,
> will not have A's hashed password. So A will not able to decrypt the
> fake data sent from C. Then A will know C is faking? Am I right?
>
How? All A knows is a random bit pattern, and C doesn't care what A
thinks the random number is - it's going to accept their data anyway
and attack it off line later.
The hashed password file is a list of secrets. A very useful thing for
anyone who wants to attack the system. Assuming it won't be compromised
is a bad idea, especially if the stakes are high enough.
There are many forms of authentication and key sharing which have fewer
problems than this method. If you have some serious data to protect,
it's worth your while to find out about them.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Dan Oetting <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Date: Fri, 17 Nov 2000 13:39:06 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (George Weinberg) wrote:
> 4) nobody can tell who voted which way.
That's precisly the problem we have today! :)
------------------------------
From: [EMAIL PROTECTED] (Scott Craver)
Subject: Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS
Date: 17 Nov 2000 21:13:32 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>Numerology and Velikovsky's absurd theories have no place in
>*any* sci.* newsgroup, let alone one concerned with cryptology.
Peat Stapleton is a usual suspect on sci.skeptic,
where he claims to be able to predict stock market
fluctuations astrologically. I'm not sure what has
suddenly caused him to start posting to sci.crypt,
but he seems to be diversifying elsewhere too.
He never really makes a lot of sense, and can not
be reasoned into leaving. Unless you have the
resources to drive to where he lives, duct tape him
into a chair and hold his eyelids open, and YELL
LOUD to him with handpuppets while making him
mouth the words along with you, he will not likely
absorb what you say. Just use your killfile.
-S
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: help on user authentication protocol
Date: Fri, 17 Nov 2000 21:36:14 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > But if, for example, C is trying to pretend to be B. The C,
however,
> > will not have A's hashed password. So A will not able to decrypt
the
> > fake data sent from C. Then A will know C is faking? Am I right?
> >
> How? All A knows is a random bit pattern, and C doesn't care what A
> thinks the random number is - it's going to accept their data anyway
> and attack it off line later.
>
That's right. Thanks.
> There are many forms of authentication and key sharing which have
fewer
> problems than this method. If you have some serious data to protect,
> it's worth your while to find out about them.
>
Can you comment on Tomas Wu's SRP? I like this protocol but would want
to know how strong SRP is with comparison to other protocols like PAK,
SNAPI, SPEKE, AMP, etc. Thanks.
c6ap
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Enigma: Stolen German Code Machine Turns Up in BBC Mailroom
Date: Fri, 17 Nov 2000 21:35:50 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> The "theory" that Nikolai Telsa had a secret for unlimited energy, and
> that these secrets were locked-away in a particular
> (secretly-different!) Enigma machine is one of those things
that "cannot
> be disproved, just as it cannot [practically] be proved," unless
> tomorrow morning someone happens to come rattling past Buckingham
Palace
> in a Model-T Ford that requires no fuel.
Already exists . Go find a surplus RTG (radio-isotope thermal
generator) and use this to power an electric car .
This would be practical apart from the safety risk in case of an
accident ... AFAIK this is the only reason why this isn't done already .
>
> This is, I believe, the logical fallacy called "begging the
question."
> If you make any proposition whatsoever .. be it that Telsa had a
secret
> and Enigma kept it hidden all these years .. and challenge me to
> disprove it and I cannot, then you *cannot* conclude by saying
> triumphantly, "therefore, what I am saying must be true!" The burden
of
> evidence is upon you, not me.
>
> If that all-electric and fuel-free version of Chitty Chitty Humm Humm
> (well, it can't exactly go "Bang Bang," now can it?) shows up, -then-
> you can start stringing together stories about that Enigma.
>
> Otherwise, please confine this thread to "talk.politics.crypto."
>
> >Anthony Stephen Szopa wrote:
> > James Felling wrote:
> > > Andre wrote:
> > > An enigma machine can be easily simulated in software.(
Ridiculously easily
> > > to do). The design of this enigma was unusual, but there was
nothing that
> > > prevenetd people from using publicly available information to
create a
> > > piece of software that would do exactly what it does. The theory
is crap.
> >
> > Are you sure the exact specification of this version of the Enigma
> > is public information?
> >
> > It might make an intriguing story if there are many Enigma
> > encryptions that are held by the government hidden away or
> > forgotten somewhere that might contain clues to hidden Nazi
> > treasure. Or there may be Enigma encryptions that reside only
> > in private hands.
> >
> > Anyway, don't you think you were rather harsh in saying that his
> > suggestion was "crap?"
>
--
Andre de Guerin :- Email <[EMAIL PROTECTED]>
Who is "General Failure" and why is he reading my hard disk ?
1+1=3 for very large values of 1
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [Question] XOR encryption
Date: Fri, 17 Nov 2000 21:47:53 GMT
[snip is XOR secure]
There's a rather continual debate going on about just that. We know the
extremes, if you use the pad more than once, all security is lost.
However, there is also whether or not your generation of the pad is
strong, and what constitutes strong. For example RC4 is generally
considered to be strong, but my simple calculation the entropy of the
output is rather low (maximum of 2048 bits of entropy in the entire
stream), but the confusion rate is very high. All we can say for sure
is that if your pad is purely/absolutely random, then the result is
perfect security called a One-Time-Pad (abbreviated OTP), and if your
generation algorithm is weak, the result is weak. Everything else lies
in the middle some where. So yes, if your pad is the size of your
plaintext you can have perfect security, but you most likely won't.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
