Cryptography-Digest Digest #185, Volume #13 Sun, 19 Nov 00 06:13:01 EST
Contents:
Re: voting through pgp (long) ("John A. Malley")
Re: XOR Software Utility (freeware) available from Ciphile Software (Anthony Stephen
Szopa)
Re: Why remote electronic voting is a bad idea (was voting through pgp) (Anthony
Stephen Szopa)
Re: vote buying... (Paul Rubin)
QUESTION on openssl 0.95a!!!!!!!!!!!!!! ("Verd")
Re: XOR: A Very useful and important utility to have (Guy Macon)
Re: Criteria for Simple Substitutions? ("news.free.fr")
Re: DES advice (ArchimeDES)
Re: Cryptogram Newsletter is off the wall? (David Crick)
Mode of operation to maintain input size with block ciphers? ("Benny Nissen")
AES/Rijndael performance on Pentium 4? (David Crick)
----------------------------------------------------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: voting through pgp (long)
Date: Sat, 18 Nov 2000 22:26:15 -0800
Benjamin Goldberg wrote:
[snip]
>
> > (Vague hunch this Doppleganger attack can be transformed into a
> > decidability problem of some kind, and that the decidability problem
> > is undecidable - there is no algorithm for it.)
>
> Hmm, suppose we have an AI, and a human, and we can have a text only
> conversation with each. Further assume that the AI is advanced enough
> that a human being can't tell which is which better than 50% of the
> time. Is it possible to create another AI which *can* tell which is
> which?
An interesting problem, but there may be another (simpler)
representation of the man-in-the-middle "Doppleganger" attack by a rogue
application on the voter's machine and the ability of the vote taker to
discern the presence of a "Doppleganger."
The citizen voter will issue only a limited number of strings (vote
choices) to the vote taker. There's an application that interacts with
the voter with an interface, and the application interacts with the vote
taker with another interface (client-server model here.)
This application need not be complicated (such that the Turing Test
comes into play here) - it could just be a finite state machine (regular
languages) or a push-down automaton (context free languages). Every
regular language may be recognized by a finite state machine. Every
context free language may be recognized by a pushdown automaton. These
are in themselves decidable languages (sets of strings.)
Assume the application for remote voting lets the voter choose one out
of n possible candidates, applies encryption and authentication
protocols to that choice and sends the protected result to the vote
collector. The application always halts for each of the n possible
choices.
A trojan horse application does almost exactly the same thing. The
application lets the voter choose one out of n possible candidates but
always substitutes a different selection in lieu of the voter's
selection, applies encryption and authentication protocols to that
substituted choice and sends the protected result to the vote collector.
The trojan horse application halts for each of the n possible choices.
The vote collector decrypts the choice from the voter and authenticates
it. The voter checks out as true and the protocols show the choice was
not altered between the output of the application and the vote
collector. But in the case of the trojan application this choice is not
the choice actually made by the voter.
Is there an algorithm to decide if a single choice that was properly
encrypted and authenticated came only from the unadulterated client
software U and no other possible machine (such as trojan horse software
T)?
I's say "No" because there is no such finite string. There are many
other languages (sets of strings) to which any particular string
belongs. There is no finite string that belongs to just one language (or
one set of strings) out of the set of all possible sets of strings. So
just checking the string that came from the voter cannot rule out it
came from a language that is not the same as the language associated
with U.
A Turing machine M that took the user's actual input into the (unknown)
application, a description of U and the received string (choice) could
simulate U with the actual input, compute the expected selection and
compare it against the received selection and thus catch the fraud. BUT,
the vote collector never gets a copy of the actual input the voter made
into the application at voter's end of things.
In fact, the language (set of strings) of U is not the same as the
language (set of strings) from T. Suppose T only sends out the same
string (choice) no matter what the voter selects, for example.
So here's an interesting twist to this situation; try to detect the
differences in the languages of U and T:
Suppose the voter chooses each of n possible candidates in some known,
defined order and applies encryption and authentication protocols to
that choice and sends the protected result to the vote collector. The
application always halts for each of the n possible choices. The vote
collector gets n out of n possible selections, each possible choice
once.
Now suppose the voter chooses each of the n possible candidates in the
same known, defined order through the trojan horse application. The
trojan horse application lets the voter choose each candidate but always
substitutes the same selection in lieu of the voter's selection, applies
encryption and authentication protocols to that substituted choice and
sends the protected result to the vote collector. The vote collector
gets the same selection n times and the other n-1 choices never.
An algorithm can compare the set of strings from an application due to
the known input and determine if the received set is the same as
expected from U. A trojan horse's response should not ever equal U's
response.
The voter and the vote collector can use this behavior (if its present
in the trojan horse) to detect its presence.
This protocol requires the vote collector send a prearranged sequence
of agreed-upon test choices in some order with one unspecified choice
interspersed in that sequence where the voter will enter the actual
choice s/he wishes to make at the time of voting. Call this a vote
script.
So a vote script looks something like "choice 1", "choice 4", "choice
2," "free choice", "choice 3" for 4 choices.
Every permutation of these sequences is made available with a unique
serial number on each. The vote collector knows how many such voting
scripts it made, which serial numbers go with which sequences, etc. The
vote collector expects to see choice 1, choice 4, choice 2, the voter's
choice, and then choice 3.
The voter gets one of these scripts from a communications channel not
shared with the client application and thus the trojan horse application
never knows which of the choices is the actual free choice position the
voter filled in. The vote collector detects the trojan horse application
when it changes every choice entered by the voter into the same
selection and thus sends the same choice multiple times. The voter can
be warned (but not through the application, through some other channel)
to get another voting mechanism.
What if the trojan horse tries to guess which of the choice positions in
the sequence is to be the actual vote taken from the voter? If it
alters one of the expected choices it's detected. If it alters the open
choice position it succeeds in committing fraud. So success is now
probabilistic ( 1 out of k choices) and not deterministic.
This means of detecting the trojan horse application (a.k.a.
"Doppleganger" attack ) involves so much coordination and work, though.
Voting protocols need to be efficient, too, and this scheme just does
not exude efficiency :-)
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,talk.politics.misc
Subject: Re: XOR Software Utility (freeware) available from Ciphile Software
Date: Sat, 18 Nov 2000 23:12:42 -0800
Alan Mackenzie wrote:
>
> Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote on Tue, 07 Nov 2000
> 20:39:23 -0800:
>
> [ .... ]
>
> > If you downloaded OAP-L3 and checked it out, you would have found that
> > there are tutorials that test every aspect of the encryption software.
> > You are also at liberty to design your own files to test the various
> > processes.
>
> > You can be sure that OAP-L3 performs exactly as described and you can
> > prove it to yourself.
>
> Anthony, I think you are mistaken here. Suppose a copy of OAP-L3 somehow
> got infected with a virus - it happens, some people are not as careful as
> they might be.
>
> The infected copy of the software would pass all tests, whether supplied
> by the author or constructed by the user, apparently behaving identically
> to the clean version. Yet OAP-L3-infected does _not_ perform exactly as
> OAP-L3-clean. Since these tests do not distinguish between the clean and
> dirty versions of the software, they cannot be said to test every aspect
> of it.
>
> > I don't know how many crypto software products provide you with the
> > means to check every process included with the software and allow you
> > to create your own verification files?
>
> The point people are making is that they cannot know that OAP-L3 is
> totally clean without having access to the source code, and no amount of
> testing can demonstrate this cleanliness.
>
> I think it's been mathematically proven that testing _cannot_ demonstrate
> a program to be flawless.
>
> [ .... ]
>
> --
> Alan Mackenzie (Munich, Germany)
> Email: [EMAIL PROTECTED]; to decode, wherever there is a repeated letter
> (like "aa"), remove one of them (leaving, say, "a").
Sounds like this is a possibility that every software program in
the world is susceptible to. Have you checked all your software
lately?
But if one were to get the software from a reputable source and maybe
make a CD-R copy so it could not be altered and compare it with other
copies of the software using perhaps the MSDOS fc command, then you
would know you had a pristine copy.
Next you will suggest that the manufacturer has been hacked and his
copies of his own software have been infected so the manufacturer
himself will be distributing infected software. But I realize you and
others are holding out the possibility that I have intentionally
tampered with my own software.
Of course, a dirty trick would be for someone or group to take some
software and infect it then redistribute it themselves. For
instance, do what you suggested with a copy of Microsoft Windows ME,
or Office 2000, or Adobe Photoshop, etc. then sell it on the black
market. You'd get plenty of buyers because you would sell it cheap.
You might even just give it away.
So what, super spy?
No amount of love can guarantee that your wife is not cheating on
you, either.
What are you willing to accept?
You know, the Old Testament tells numerous stories about the Jews
taking vengeance on their enemies. How does Germany know that
before it ever becomes a threat to anyone ever again in the world
that Israel will not incinerate all of Germany with its nuclear
weapons? Or maybe Israel is planning to do this anyway as surely
as they believe in their god, no matter what.
What are you going to do about it?
Make your own tests based on the specification of OAP-L3. Then test
the software. You do this by testing one function at a time. And
the functions are simple shuffle / transform functions and the XOR
function.
I mean, do you actually think that the software is going to let all
the test files process normally but when the fate of the world is at
stake the software will recognize this and the virus or bug or
trojan or whatever will activate and allow the world to be destroyed?
That's an extraordinary suggestion.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Date: Sat, 18 Nov 2000 23:14:19 -0800
Roger Schlafly wrote:
>
> David Hopwood wrote:
> > binary digit wrote:
> > ? Imagine if everyone had pgp in the world and voted through pgp, every
> > ? single vote could be verified and everyone would be happy,
> >
> > Problems with remote electronic voting systems (in no particular order):
> > 1. obtaining voter anonymity *and* adequate authentication,
> > 2. vote buying and coercion,
> > 3. authenticating computers and not individual voters is not sufficient,
> > 4. targetted denial of service,
> > 5. verifiability of software and hardware,
> > 6. some voters may have problems with electronic interfaces that they
> > would not have with paper ballots,
> > 7. attacks against insecure end-points (both voters' PCs, and servers),
> > 8. there is arguably more scope for *undetectable* corruption than in
> > a paper-based system,
> > 9. existing weaknesses in paper-based systems [*1] are magnified if
> > voting is remote and anonymous, because it is easier to get away
> > with attacks,
> > 10. bias due to poorer social groups having less access to computers.
> >
> > It might be possible to address 1, 2, and possibly 3 by a cryptographic
> > protocol, and 6 by careful interface design [*2], but I don't see the
> > other problems being solved any time soon, if they are solvable at all.
>
> I don't see how you can do (1) by a crypto protocol. In Calif (and
> everywhere else?) a voter can register with a postcard and then vote
> in person with no ID at all. The only thing that keeps the system honest
> is that very few people are willing to violate federal election law
> in person and in front of witnesses just to get one lousy vote.
>
> With a PGP-type approach, there are various authentication methods
> possible, such as certs. But ISTM it would be a much greater burden
> on the voter, requiring special ID and registration requirements.
> And all it would take would be some flawed CA procedure, and someone
> will anonymously vote 1000s of times. I just don't see how you'd
> manage the fraud problem. (But go ahead and make suggestions.)
The dangers of digital democracy
Think about it and more.
http://news.bbc.co.uk/hi/english/sci/tech/newsid_1026000/1026155.stm
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: 18 Nov 2000 23:32:44 -0800
David Hopwood <[EMAIL PROTECTED]> writes:
> All the attempted solutions I've seen fail to solve the problem that
> voters' authentication credentials can be bought. (Authentication
> credentials are whatever a voter knows or has that proves that they
> are eligible to vote, and that distinguishes them from another voter -
> e.g. keys or smartcards.)
If we're talking about poll voting, they authenticate you at the polls
(photo ID etc). If we're talking about voting over the internet,
that's a bad idea because it sacrifices non-coercability (the
receipt-free property) by letting you vote with someone else watching.
Even if there is some kind of foolproof biometric authentication
device that you can plug into your computer when you vote, you can
still sell your vote by just letting the buyer see how you vote.
------------------------------
From: "Verd" <[EMAIL PROTECTED]>
Subject: QUESTION on openssl 0.95a!!!!!!!!!!!!!!
Date: Sun, 19 Nov 2000 09:33:51 GMT
Used open-ssl version is 0.95a ...
Is the usage below valid? if invalid, let me get the right usage please..
FILE* fp;
EVP_PKEY* pkey;
char keyfile[] = "user1.pem";
fp = fopen (keyfile, "r");
if (fp == NULL) return -2;
pkey = PEM_read_PrivateKey(fp, NULL, NULL, NULL);
if (pkey == NULL)
ERR_print_errors_fp (stderr);
return -2;
}
fclose (fp);
The result is :
Enter PEM pass phrase:
1564:error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:d:\work\evp_enc.c:243:
1564:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal
error:D:\work\p12_decr.c:95:
1564:error:2306A075:PKCS12 routines:PKCS12_decrypt_d2i:pkcs12 pbe crypt
error:D:\work\p12_decr.c:121:
1564:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1
lib:d:\work\pem_lib.c:290:
Thanks for reading...
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: Re: XOR: A Very useful and important utility to have
Date: 19 Nov 2000 09:55:15 GMT
Anthony Stephen Szopa wrote:
>
>XOR: A Very useful and important utility to have
>
>A few people in this news group said any XOR program is less than
>useless.
>
Balderdash. What people have said is that *YOUR*
XOR program is less than useless. Which it is.
Why?
[1] It's 156KB zipped. Bloatware Alert! Bloatware Alert!
[2] You haven't published the source code. Security Risk! Security Risk!
[3] You have a random number generator and an encryption system that
you don't advertise, yet you push this little utitity. **A lot**...
A reasonable persoin would suspect that you have something hidden in
the code that you don't want users to know about. Which makes it
less than useless.
------------------------------
From: "news.free.fr" <[EMAIL PROTECTED]>
Subject: Re: Criteria for Simple Substitutions?
Date: Sun, 19 Nov 2000 10:26:08 GMT
An interesting question
How can we measure the "strength" of a permutation ?
Is there some references in books or web site ?
------------------------------
From: ArchimeDES <[EMAIL PROTECTED]>
Subject: Re: DES advice
Date: Sun, 19 Nov 2000 10:28:52 GMT
On Tue, 14 Nov 2000 13:04:04 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>>Also why buy a C compiler when you can easily download one for free?
>You mean you can write a program with gcc that runs under Windows?
With lcc you can write win(95,98) programs.
>And even if there is a port of gcc like that - I know you can use it
>for writing DOS programs - how easy is it to use?
An easy compiler? a compiler generate machine code from source code,
when you write at the dos prompt "gcc source.cpp" or "make all" what
else that make your life easier could you have?
>Version 3 of C++ Builder is still available at large discounts in some places, and it
>is very useful. (There's a free download of the compiler engine from
>version 5 of that, although it's unclear to me how useful that is by
>itself.)
Version 3 of C++ Builder is free. The point with this sort of programs
is that they are IDE and you'll learn to program in C++ Builder or in
Visual C++, but NOT in C++.
ArchimeDES
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 10:32:29 +0000
Roger Schlafly wrote:
>
> A lot of paper contracts have these problems. Yes, I have signed
> paper contracts that I have never read, and most other people
> have also. Almost no one read insurance forms, loan agreements,
> lease agreements, etc.
While I agree with what you are saying, the distinction here is that
the signer CHOSE not to read the paper contract.
What Bruce is saying, I believe, is that you can THINK you are
signing what is being presented, but in fact you could be signing
something different.
I guess it's one of those "cheating attacks" that don't necessarily
attack the algorithms, etc directly, but uses other, more subtle
means to achieve the compromise.
David.
--
+-------------------------------------------------------------------+
| David A Crick <[EMAIL PROTECTED]> PGP: (NOV-2000 KEY) 0x710254FA |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: "Benny Nissen" <[EMAIL PROTECTED]>
Subject: Mode of operation to maintain input size with block ciphers?
Date: Sun, 19 Nov 2000 11:33:41 +0100
Hi All
Is there a mode of operation where I can maintain the size in all cases
(input/output). I know that CFB mode can be used, but with this mode a new
IV need to be generated each time to maintain security. I am looking for a
way to maintain the size at all times and without the need to make a new IV
(a fixed one is OK).
I have heard about a method called byte stealing, but I do not know what it
is all about!
Thanks
Benny
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: AES/Rijndael performance on Pentium 4?
Date: Sun, 19 Nov 2000 11:00:31 +0000
I seem to remember talk of (some of) the AES candidates being
*slower* on the Pentium 4 platform, due to the different (longer)
times needed to execute certain instructions, etc.
Any idea if Rijndael gets slower or faster on the Pentium 4 platform
over Pentium II/III?
--
+-------------------------------------------------------------------+
| David A Crick <[EMAIL PROTECTED]> PGP: (NOV-2000 KEY) 0x710254FA |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
