Cryptography-Digest Digest #210, Volume #13 Wed, 22 Nov 00 20:13:00 EST
Contents:
10 Pcs. Of Paper Money From Around the World 7848 ([EMAIL PROTECTED])
Re: RSA Signature ! (Steve Portly)
Re: Entropy paradox ("Harvey Rook")
Re: 10 Pcs. Of Paper Money From Around the World 7848 (Steve Portly)
Re: why scramdisk menu don't work on win95 ? ("Sam Simpson")
Re: Q: fast block ciphers (David Wagner)
Re: New Dynamic Algo + Contest + Doc (David Wagner)
Re: New Dynamic Algo + Contest + Doc (David Wagner)
OCR Encryption ([EMAIL PROTECTED])
Re: Mode of operation to maintain input size with block ciphers? (Jerry Leichter)
Re: Mode of operation to maintain input size with block ciphers? (David Hopwood)
Re: New Dynamic Algo + Contest + Doc (proton)
Re: Entropy paradox ([EMAIL PROTECTED])
Re: New Dynamic Algo + Contest + Doc (David Wagner)
Re: A Simple Voting Procedure (Stanley Chow)
Re: Question regarding OS's. ("Juri")
Re: Mode of operation to maintain input size with block ciphers?
([EMAIL PROTECTED])
Re: Question regarding OS's. ("Juri")
Re: A Simple Voting Procedure (David Schwartz)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: 10 Pcs. Of Paper Money From Around the World 7848
Date: Wed, 22 Nov 2000 18:25:45 GMT
Two days ago I ordered 10 pieces of paper money from 10 different countries from a
company called Perth Numismatics. Lo and behold they arrived today and they are very
nice and colourful. They even have a bill from Antarctica. I didn't even know they
existed. These are perfect for stocking stuffers or people who are hard to buy for.
The website address is www.perthmoney.com
Good luck and Merry Christmas
Cynthia Reeves
zsivyowvzkwvixyrsdmfiwsepftjkqykqxgivvkodhqjjukeufmmnhitrhoujwygjekgskgoqcvvvomcwkj
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: RSA Signature !
Date: Wed, 22 Nov 2000 16:05:23 -0500
Fr�d�ric Donnat wrote:
> Hi !
> I'd need to make my own Signature with RSA , but i first want to know
> how works RSA Signature. Ususaly you made a hash of you're data (using
> MD5 or SHA for example) and after you signed them ! but how do you
> signed them ? is it an encryption ?
>
> If someone can help me or tell me where to find information about
> digital signature i'll be very greatfull !
>
> Best regards
> Fred
Any one way hash that will provide a unique identifier should work.
Your choice of hash will depend on the number of bits your signature will
contain.
For most signatures of 24 characters or less a hash such as MD5 should be
adequate.
Lots of information can be found in the RFC's. RFC1750 for example.
------------------------------
From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 13:24:59 -0800
The problem is with your use of the phrase "the u bits are provably secure."
Provably secure does mean that m can never be calculated and that u is
perfectly random. It means that the best available attack is brute force.
Such a brute force attack would take about O(sqrt(m)) work/space to execute.
Since u >> m, you've provided more than enough material to calculate m.
So there is no paradox.
Harv
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> This is a re-formulation of an issue that I questioned
> previously. Suppose one has m perfectly random bits and
> uses that in some appropriate way to get a BBS generator
> to generate u bits, with u >> m. We know that (accepting
> certain plausible assumptions) the u bits are provably
> secure. It seems thus that we have obtained more entropy
> that way, i.e. having obtained an amount of additional
> entropy from nothing. How is this apparent paradox to be
> properly explained? (Or does each bit of the generated
> sequence have in average m/u bits of entropy?) Thanks in
> advance.
>
> M. K. Shen
> ------------------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: 10 Pcs. Of Paper Money From Around the World 7848
Date: Wed, 22 Nov 2000 16:28:02 -0500
[EMAIL PROTECTED] wrote:
> Two days ago I ordered 10 pieces of paper money from 10 different countries from a
>company called Perth Numismatics. Lo and behold they arrived today and they are very
>nice and colourful. They even have a bill from Antarctica. I didn't even know they
>existed. These are perfect for stocking stuffers or people who are hard to buy for.
>The website address is www.perthmoney.com
> Good luck and Merry Christmas
>
> Cynthia Reeves
>
> zsivyowvzkwvixyrsdmfiwsepftjkqykqxgivvkodhqjjukeufmmnhitrhoujwygjekgskgoqcvvvomcwkj
Ok I got one.
zsvyowvzkwvixyrsmfispfjkqykqxgivvkodhqjjukeufmmhihojwyjekgkgqcvvvomcwkj
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: why scramdisk menu don't work on win95 ?
Date: Wed, 22 Nov 2000 22:13:45 -0000
Please direct this post to alt.security.scramdisk. FWIW, I haven't got a
clue - I use SD 3.01 on win95b and it works fine...
Regards,
Sam
http://www.scramdisk.clara.net/
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have just tried to install scramdisk 3.01a, in a win98 pc, and work
fine, but,
> installing it in with win95b the interface menu don' t work, I just see
two
> "box" and the menu bar is not visible.
>
> It's a bug in my computer or a software defect ?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Q: fast block ciphers
Date: 22 Nov 2000 22:28:19 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Joseph Ashwood wrote:
>for round = 1 to 16
> right = right XOR (left * rand(n/2) + rand(n/2)) mod 2^(n/2)
> swap(right, left)
That's not secure. If you flip the high bit of one word of the plaintext,
only the high bit of each half of the ciphertext can be affected.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New Dynamic Algo + Contest + Doc
Date: 22 Nov 2000 22:31:16 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Why are you designing your own algorithm?
If you're going to build something that you suggest other people
could use, I *strongly* encourage you to instead use a widely-scrutinized
algorithm like 3DES or Rijndael. (Did I emphasize that strongly enough?)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New Dynamic Algo + Contest + Doc
Date: 22 Nov 2000 22:33:14 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Sylvain Martinez wrote:
>You are right, what I tried to say is that I think (hope !) BUGS could
>be just a bit more difficult to understand than Vignere or Caesar is.
>And could therefore be still interesting to look at for a newbie.
I hope you recognize that "look at" is very different from suggesting
that others can use it and expect it to be reasonably secure.
If the point is just to have fun, sure, post your algorithm; but if
you recommend that others use it, you might be doing them a major
disservice.
If the point is to use it operationally, don't invent a new cipher;
use a trusted cipher, like 3DES or Rijndael.
That's my advice, anyway.
------------------------------
From: [EMAIL PROTECTED]
Subject: OCR Encryption
Date: Wed, 22 Nov 2000 22:45:28 GMT
In the mac community a group of people have got
a rather bad idea that the following icon in Mac
OS X has a readable text in it. I doubt that.
http://johnlockard.tripod.com/ReadMeICON.png
Anyway, there must be a limit say an area of 25
pixels per character that prevents text from being
read by man or machine. Am I right?
Cheers!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jerry Leichter <[EMAIL PROTECTED]>
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: Wed, 22 Nov 2000 18:10:54 -0500
| >Is it possible to work with input size smaller then the cipher block
| >size and keep the output size as the input size?
| >(NB: no dynamic IV needed)
|
| That would be pretty difficult.
|
| You can't invert a block cipher if you don't have the whole output to
| put back in.
That's not quite true. I've been playing around with a method which
works for "short" (a byte or so) and "long" (within a byte or so of the
block length) messages; I still have no way to deal with intermediate
lengths.
Let's take the short one first. Suppose we with to send a single byte
P; assume, for uniformity, a 128-bit (16 byte) block. Form a block by
appending 15 zero bytes to the P, encrypt it under the the key, and send
*just the bottom byte of the encrypted value*. The receiver can't
decrypt directly, but he can compute the encryption of all 256 possible
bytes, followed by 15 zero bytes, and check to see if the bottom byte of
the result matches the cyphertext. When he finds a match, he has this
byte.
Of course, the decryption is ambiguous if two or more bytes produce the
same bottom byte of the encrypted result. How often does that happen?
If the encryption algorithm being used is good, it behaves like a random
permutation, and all bits of the output block act like random functions
of all bits of the input block. So essentially we have a particular
cypher byte C which comes from encrypting P, and 255 other random bytes
that come from encrypting the other block values. The chance that any
one of them *differs* from C is 255/256; the chance that *all* do is
(255/256)^255, which works out to somewhat more than 1/3. So we have to
do better!
However, it's not hard to do so: The *sender* can calculate the
encryption of all possible bytes (followed by zero padding). If the
encrypted byte it wants to send only shows up once, it sends it.
Otherwise, it tries again. An obvious way to try again is to change the
padding: Use '1' written as a 120-bit number for padding, then '2', and
so on. An even better way - since you already have the full 128-bit
encryptions in hand - is to try the second from the bottom byte, then
the third, etc. Since each such trial has a 30% chance of succeeding,
you get something that works very quickly. It makes no difference what
procedure you use to generate the alternate encodings, as long as it is
shared by sender and receiver and independent of P; given that
independence, the receiver can duplicate the sender's efforts and arrive
at exactly the same result and the proper decoding.
None of this depends on byte alignment - you can use it to send any
number of bits. The limitation is in the work required to find an
encoding that decodes uniquely - work that has to be repeated at both
ends. (And, of course, if you send a string of bits that's not an even
number of bytes, your channel has to be able to preserve the length, in
bits, exactly.) You can probably stretch this to sending 2 bytes, but
probably not beyond that.
There's an analogous technique for the case that you want to send, say,
15 bytes of data. (Basically, you look for a pad *byte* that gives
unique decryption, and then fall back to modifying the plaintext in some
agreed-upon fashion if you can't find one.) Again, you can probably get
to 14 bytes.
This leaves the range 3..12 bytes open for some other idea.
-- Jerry
------------------------------
Date: Wed, 22 Nov 2000 23:16:44 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Mode of operation to maintain input size with block ciphers?
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (John Savard) writes:
>
> > I understood ciphertext stealing to be a modification of ECB mode;
> > although the final encipherment could be in ECB mode while the regular
> > encipherment was in CBC mode or any other.
>
> No, CTS is a variant on CBC.
CTS can be used for either ECB or CBC mode (and almost any other
mode that works on blocks, such as PCBC).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOhsOXzkCAxeYt5gVAQG+TAf/d7QRMIm17SLF5Z5d51aTti8c+wglM/7x
M2wz3PilfWkoVBH0Qvgh7we6sV35tI9T9vX/nnSgrIl8A//P3wJplYPcYsbGCNw4
JK1gL6kmWFyfFrLTwNLgkyOGN9NkoAq4UJkjnMiaX5itUArd1bodg/99oKP69FN0
bgX6UdgPF1qCDTV1+uPbB/8vQp2cNrzn49CbULFwmOr+JBe4hqy+Li6ABUp8W16H
wzZ4Rrg5Tgsoe3K7mp1uPDKju6GZgk1+JaB6ChSj9uhcWe9/NeiGwSPQV50zJ6n6
iHFFFJKj1EbjpRMi4Ju2z4hZhb6sE4lHyszNYklmU367R+9uLs+QEg==
=E0oE
=====END PGP SIGNATURE=====
------------------------------
From: proton <[EMAIL PROTECTED]>
Subject: Re: New Dynamic Algo + Contest + Doc
Date: Wed, 22 Nov 2000 23:43:50 GMT
David Wagner wrote:
>
> Why are you designing your own algorithm?
>
> If you're going to build something that you suggest other people
> could use, I *strongly* encourage you to instead use a widely-scrutinized
> algorithm like 3DES or Rijndael. (Did I emphasize that strongly enough?)
<sarcasm>
mmm, goodie. Lets just halt innovation altogether. God forbid, some
non-crypto-savvy person might come up with a radically new idea that
might be the most secure thing for the next millenium!
</sarcasm>
New sollutions dont always come from the people `in the know'.
It can come from anyone.
/proton
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Entropy paradox
Date: Wed, 22 Nov 2000 23:41:31 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> The problem is, as I said elsewhere, explaining HOW,
> through inputting m full entropy bits into BBS (regarded
> as a black box), one can obtain u >> m bits of output
> that are normally claimed in the crypto literature to
> be unpredictable and hence having at least almost full
> entropy (using the 'same' definition of entropy, whatever
> that be that one adopts). For the user, a bit that is
> perfectly unpredictable has one bit of entropy, isn't it?
> Thanks.
Now we come to one of the finer points. The BBS proof relies on some
statements that you don't seem to recall (they may or may not have been
in the paper).
1) The entire input space is used for keying
2) There is perfect entropy in that keying cycle
Both of these seem fairly innocent, and fairly obvious. However what
you have to remember is that in this case, instead of using the entire
space you are instead using m-bits.
This becomes important during cryptanalysis because while given the
stream alone, and no information about how it was keyed, the proof
holds. However in this case we have additional information, we know
that the key is m-bits and has m-bits of entropy. The result is that
while given large quantities of output we can typically make no
predictions, we can using those same large quantities mount a large
scale search for the key value.
Stating this a different way. Assuming that BBS is deterministic (which
it is), there are at most 2^m possible output streams. Thus there
exists a compression function which will compress any given infinite
stream from BBS that has been keyed using a m-bit perfect entropy key
to at most m-bits (if there are no identical streams, then it will be
exactly m-bits), where the decompressor is simply the BBS function.
The difficulty of computing the compression function may be very high,
but that the function exists is the only matter.
This means only that there is an order in the output of BBS (and all
other pRNGs), it just so happens that BBS has a proof of resistance
against post-mortem stream analysis.
I hope this clarifies things.
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New Dynamic Algo + Contest + Doc
Date: 23 Nov 2000 00:11:02 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
proton wrote:
>Lets just halt innovation altogether.
Don't misquote me.
I said: If the point is to experiment, sure, post the algorithm,
but don't tell people to use it operationally until it has been
well-scrutinized.
Experimental research cipher ideas should not be confused with
stuff to be used operationally.
------------------------------
From: Stanley Chow <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Thu, 23 Nov 2000 00:17:25 GMT
David Schwartz wrote:
>
> Stanley Chow wrote:
>
> > You need to show how one can construct ID and receipts that have the
> > magical properties. In fact, you will probably need many more mandane
> > properties like unforgable receipts, etc. The attacks are usually not
> > on the magical properties but on how the constructions (don't quite)
> > correctly produce the properties. I recommand "Secrets and Lies" by
> > Bruce Schneier.
>
> I guess I haven't made this clear enough. I'm not suggesting specific
> schemes that are to be implemented as suggested. I'm simply trying to
> establish what the requirements are.
The concept of "requirement" is not well-formed in the sense
that there does not exist "The Unique Universal RequirementS".
For each situation, each properties may or may not be desirable
to different parties (not just political parties, but people or
entities in general).
If you narrow it to say, USA-style elections, then several people
have articulated some desirable and undesirable properties.
> The problem is, if people assume that you can't have property A and
> property B (which they want) without property C (which they don't want),
> they'll leave A and B out of the requirements. This will result in a
> poorly designed system because incorrect assumptions were built into the
> requirements.
Incorrect. It would be a poor design IFF the assumptions were
indeed incorrect. Since most people think this particular
assumption is correct, the design is not poor. One can only
build what one knows how to build; not what one wants.
> Are you alleging that it's impossible to devise a system that meets the
> requirements in my paragraph above? I'm not saying it's easy or even
> desirable, I'm simply saying it's possible. In order for the
> requirements to be contradictory, it would have to be impossible.
Your saying it is possible does not make it so. You have to prove
that it is in fact possible. In fact, an existance proof does not
allow you to build such a system; you need a constructive proof
that is also practical - a remarkly rare beast.
> The onus of proof is not on me because all I'm trying to do is show
> that someone else's impossibility claim has not met its burden of prood.
No, you have not shown that anyone's argument is wrong. You have
repeated said you are right. repetition of your assertion is not
proof (political spin may have this property).
> I would genuinely like to establish with the requirements are. But
> every time I try, someone either attacks specific implementation details
> or outright refuses to answer the question asked.
You have repeated asserted you are right. Each time you offer a
sample as an existance proof. Why should people not study the
details of your proof? That is, after all, the way that proofs
are supposed to work.
> Here's a great example -- I ask, "Would you oppose a system where it
> could be established how someone voted with that voter's consent?" And I
> get back, "Yes, because a voter could be forced to reveal how they
> voted." I can't be the only one who knows what the word "consent" means,
> can I?
"Would you like to buy a lottery ticket and be rich?"
"But you can't guarantee that I will win."
People understand what you are proposing, they just don't know how
to achieve it. Since you can't/won't show people how, the whole
point is moot.
--
Stanley Chow VP Engineering [EMAIL PROTECTED]
Cloakware Corp (613) 271-9446 x 223
------------------------------
From: "Juri" <[EMAIL PROTECTED]>
Subject: Re: Question regarding OS's.
Date: Thu, 23 Nov 2000 00:23:31 GMT
Thanks for pointing somethings out for me, I still prefer
to use NT4 because of the driver problem for my hardware
that won't work under NT5.
Shawn Willden <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> This is OT, but this whole thread is OT, really, so...
>
> Mack wrote:
>
> > NT4 is more stable than Win2k plus there are more drivers.
>
> Interesting comment. My experience re: stability is opposite of yours;
> NT4 blue-screens fairly regularly (once a month or so), while Win2K is
> reasonably solid. And as for drivers, my primary data point is that on
> every one of the half dozen machines I use Win2K on (including two
> laptops and one fairly old machine), Win2K already had drivers for
> everything.
>
> > Linux is very nice for programming work.
>
> Linux is nice for nearly everything, IMO.
>
> > Win98 does better multimedia.
>
> Also an interesting viewpoint. The platforms seem equivalent to me in
> this respect, except that there isn't a DVD player for Linux yet.
>
> I'd add: Win98 is better for games. My home machine dual-boots Win2K
> and Win98 for that reason -- 98 is for the games that won't run (or run
> well) under 2000, 2000 is for everything else. Not many (modern) games
> are available on Linux, of course.
>
> Shawn.
>
>
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Mode of operation to maintain input size with block ciphers?
Date: 22 Nov 2000 16:25:55 -0800
David Hopwood <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> >
> > No, CTS is a variant on CBC.
>
> CTS can be used for either ECB or CBC mode (and almost any other
> mode that works on blocks, such as PCBC).
In a way, you're right, although it's a matter of semantics.
CTS encryption is expressed especially simply in terms of CBC:
Pad the last block with zeros, then encrypt the whole thing with CBC
as usual. Swap the last two blocks, and truncate the new last one.
To do CTS with ECB, you'd encrypt the message as usual, except for the
last block, where you encrypt the XOR of the plaintext with the
previous block's ciphertext. Then swap and truncate the last two
ciphertext blocks.
In effect you are switching to CBC mode for those last two blocks,
since XORing the ciphertext of one block into the plaintext of the
next before encryption is the fundamental idea behind CBC. That's why
it makes most sense to think of CTS as a variant of CBC.
In PCBC you XOR both the plaintext and ciphertext of one block into
the next block before encrypting. I don't see how to do the CTS trick
with this, unless again you switch to CBC mode on the last pair of
blocks, and leave off the plaintext XOR in that step.
Ob
------------------------------
From: "Juri" <[EMAIL PROTECTED]>
Subject: Re: Question regarding OS's.
Date: Thu, 23 Nov 2000 00:24:54 GMT
Paul,
Humm, you do have a point there, thanks for sharing it with me...
I haven't thought of it that way.
I am currently looking at the url you provided, thanks.
Juri
Paul Crowley <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Juri wrote:
> > Thanks very much for telling me...
> > I always wanted to try out unix...since I am
> > running nt4 right now. I have used linux a
> > little bit and I like what I am seeing.
>
> I don't think there is a "best OS for cryptographers", but in the spirit
> of "what toothpaste does Madonna use", there's some OS advocacy on the
> home page of one of the AES designers:
>
> http://www.esat.kuleuven.ac.be/~rijmen/index.html
>
> Of course, the fact that I happen to agree in every way doesn't bias me
> at all!
> --
> __
> \/ o\ [EMAIL PROTECTED]
> /\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Wed, 22 Nov 2000 16:32:25 -0800
Stanley Chow wrote:
> > I guess I haven't made this clear enough. I'm not suggesting specific
> > schemes that are to be implemented as suggested. I'm simply trying to
> > establish what the requirements are.
> The concept of "requirement" is not well-formed in the sense
> that there does not exist "The Unique Universal RequirementS".
> For each situation, each properties may or may not be desirable
> to different parties (not just political parties, but people or
> entities in general).
> If you narrow it to say, USA-style elections, then several people
> have articulated some desirable and undesirable properties.
That is true. People may have differing sets of requirements for
different types of elections. I was primarily thinking of USA
presidential elections, but they're far from the only possible case.
> > The problem is, if people assume that you can't have property A and
> > property B (which they want) without property C (which they don't want),
> > they'll leave A and B out of the requirements. This will result in a
> > poorly designed system because incorrect assumptions were built into the
> > requirements.
> Incorrect. It would be a poor design IFF the assumptions were
> indeed incorrect. Since most people think this particular
> assumption is correct, the design is not poor. One can only
> build what one knows how to build; not what one wants.
Even if it doesn't result in a poor implementation, the requirements
are still worse than they would be if they didn't include the
assumption. This holds even if the assumption is correct. The
requirements really should include what people actually want out of the
system and should not include conclusions about what's possible and what
isn't.
One possible source of confusion is the use of the term "requirements".
Perhaps a better term would be "objectives". Not every requirement is a
literal absolute. Even requirements that seem absolute, like the
absolute inability for an election official to determine how an
individual voter voted, are really only relative. Even in present
schemes, a clever enough election official could make such a
determination. We really just want it to be sufficiently hard
(especially on a large scale).
> > Are you alleging that it's impossible to devise a system that meets the
> > requirements in my paragraph above? I'm not saying it's easy or even
> > desirable, I'm simply saying it's possible. In order for the
> > requirements to be contradictory, it would have to be impossible.
>
> Your saying it is possible does not make it so. You have to prove
> that it is in fact possible. In fact, an existance proof does not
> allow you to build such a system; you need a constructive proof
> that is also practical - a remarkly rare beast.
So you are saying you don't think it's possible to assign each voter an
ID without an official being able to map an ID to a voter? (And note
that this ability is really only subject to a 'sufficiently hard'
requirement. It needn't be literally impossible.)
> > The onus of proof is not on me because all I'm trying to do is show
> > that someone else's impossibility claim has not met its burden of prood.
>
> No, you have not shown that anyone's argument is wrong. You have
> repeated said you are right. repetition of your assertion is not
> proof (political spin may have this property).
I'm not saying anything. Really. I just want to know what the
requirements are, but I want an unbiased view of the requirements. I
don't want the requirements tainted by what someone thinks is possible
or not. If it's preferable for a system to have A and to have B but
mandatory that it not have C, I want the requirements to say that. I
don't want the requirements to leave out desirable properties A and B
just because someone thinks that that requires undesirable property C.
Just state that A is good, B is good, and C is very bad.
> > I would genuinely like to establish with the requirements are. But
> > every time I try, someone either attacks specific implementation details
> > or outright refuses to answer the question asked.
>
> You have repeated asserted you are right. Each time you offer a
> sample as an existance proof. Why should people not study the
> details of your proof? That is, after all, the way that proofs
> are supposed to work.
Because I'm not trying to establish any particular point. I just want
an unbiased statement of the requirements that's free of possibly
incorrect conclusions. This is because even if the conclusions are
correct, they don't help to make the list of requirements better.
> > Here's a great example -- I ask, "Would you oppose a system where it
> > could be established how someone voted with that voter's consent?" And I
> > get back, "Yes, because a voter could be forced to reveal how they
> > voted." I can't be the only one who knows what the word "consent" means,
> > can I?
>
> "Would you like to buy a lottery ticket and be rich?"
> "But you can't guarantee that I will win."
>
> People understand what you are proposing, they just don't know how
> to achieve it. Since you can't/won't show people how, the whole
> point is moot.
I'm not proposing anything! I just want to know what the requirements
are. After that, people can make intelligent proposals and we'll have a
standard to judge them by.
DS
------------------------------
** 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
******************************
