Cryptography-Digest Digest #184, Volume #13 Sun, 19 Nov 00 00:13:01 EST
Contents:
Re: vote buying... (Dan Oetting)
Re: Cryptogram Newsletter is off the wall? (David Hopwood)
Re: Criteria for Simple Substitutions? ("r.e.s.")
Re: vote buying... (David Hopwood)
Re: Client Puzzle Protocol (Bob Silverman)
A Question About Multi-encrypting (Bobby)
Re: Why remote electronic voting is a bad idea (was voting through pgp)
([EMAIL PROTECTED])
Re: A Question About Multi-encrypting (Mathew Hendry)
Re: A Question About Multi-encrypting (Tom St Denis)
Re: ---- Internet Voting Questions (Greggy)
Re: vote buying... (David Schwartz)
Re: A Question About Multi-encrypting (John Savard)
Re: XOR Software Utility (freeware) available from Ciphile Software (Anthony Stephen
Szopa)
Re: vote buying... (David Wagner)
XOR: A Very useful and important utility to have (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Dan Oetting <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sat, 18 Nov 2000 17:27:16 -0700
In article <[EMAIL PROTECTED]>, David Schwartz
<[EMAIL PROTECTED]> wrote:
> When you register to vote, you present identification. Once you are
> confirmed as eligible to vote, you are given a chit randomly pulled out
> of a box. No mapping is kept of who got what chit.
And you could sell this chit for cash and nobody can prove it and nobody
gets hurt. I think you have the perfect system. :)
------------------------------
Date: Sun, 19 Nov 2000 00:31:09 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Cryptogram Newsletter is off the wall?
=====BEGIN PGP SIGNED MESSAGE=====
Matt Timmermans wrote:
> And even if your software is "trusted", i.e., it contains no bugs and no
> code that was written with evil intent, and even if nobody steals your key
> or signs anything you don't want signed, digital signitures are still not
> semantically reliable.
>
> Let's say I send you a message and it's signed with my private key. What
> does that signature mean? Perhaps you take it to mean that I agree to all
> the terms and conditions in the message,
Hence the "Nothing in this message is intended to be legally binding."
in my .sig :-)
> but perhaps I only meant to assure you that the message originated with me.
For an example of exactly this attack on Microsoft's Authenticode, see
"A Comparison between Java and ActiveX Security,"
http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html
(in particular the IntraApp example, but many of the other problems
described in that paper could also be classified as semantic attacks).
Although the paper was written in 1997, all of the avenues of attack
against both Java and ActiveX are still valid. Many examples of insecure
ActiveX controls have been found, some of which are signed by Microsoft
or installed by default in software bundled by OEMs. For Java, I haven't
checked recently whether injecting unsigned classes into a signed JAR file
still works, but I think it does. The incidence of *reported* security
bugs in Java implementations has apparently gone down, but I think that
is an illusion caused by the fact that only a very small number of people
were working on finding and publicising bugs (most were found by me or
the Secure Internet Programming group at Princeton; I've not been working
on that recently, and I don't think the SIP group has either).
- --
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
iQEVAwUBOhcfAzkCAxeYt5gVAQHYqQf/fsrxpAck9kXzrOS2tlW7s4xGf+nqVwY+
sJAOND849rSxYq9GJTtY5D6jSGUi9qUr/6ORkzgCw8XOrX4hhYoP9tSiOjG3IhgC
qXw3yCD9hWbBHKBlD5aX/h1fF4tCHil+LzRgFNpk0Nw5995lTT5YQosQDJXYgYXo
H8pA1Op2eG01K1ibcR/ZhWJP5OtZA1XgpgODxWP/rrVIFgPZYq2ZuARW9aRCQRfF
XrNdi4S5FxNvWEkdjRABArjkGmOp/7Rege9OTpJsLlmzoqLNkidYaADdXFDcqxHh
zXEpspHB+kORyZhsGRijvDCml5H+UmE6lMEIqZIRh+5J4SG3KxBySw==
=4atg
=====END PGP SIGNATURE=====
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Criteria for Simple Substitutions?
Date: Sat, 18 Nov 2000 16:41:17 -0800
"Paul Pires" <[EMAIL PROTECTED]> wrote in message
news:DcER5.5601$[EMAIL PROTECTED]...
|
| r.e.s. <[EMAIL PROTECTED]> wrote in message
| news:8v6nvr$9ho$[EMAIL PROTECTED]...
| > Here's a basic question about simple substitutions
| > when the plaintext & ciphertext use the same set of
| > characters.
| >
| > For simplicity, suppose the alphabet is just abcdef,
| > so that a substitution can be described by filling
| > in the second row of a table like
| >
| > abcdef
| > ......
| >
| > meaning that each letter is to be replaced by the
| > letter below it.
| >
| > Following are some possible substitution tables
| > and their corresponding cycle structures:
| >
| > --
| >
| > S-tables Cycle Notation
| >
| > abcdef
| > ------
| > abcdef (a)(b)(c)(d)(e)(f)
| > fbcdea (af)(b)(c)(d)(e)
| > fbadec (afc)(b)(d)(e)
| > edfbac (ae)(bd)(cf)
| > acefbd (a)(df)(bce)
| > cedafb (acd)(bef)
| > dceafb (ad)(bcef)
| > cebafd (acbefd)
| > ... ...
| >
| > The first few tables in this list are presumably
| > unacceptable, since they leave all or many of the
| > letters unchanged.
|
| Wouldn't the last one be equally unacceptable
| since it leaves no letters unchanged and is therefore
| provably predictable? Having a non-overlapping
| method would allow an attacker
| to eliminate many possible keys just by seeing which ones
| violate the "All must change" rule.
It's true that the cipher would have a reduced key space,
but even if we restrict the S-tables to have only one cycle,
the number of such tables would be (N-1)!, where N is the
number of characters in the alphabet. Leaving the above
simplistic example for a moment, consider a 256-character
alphabet -- 255! tables seems a respectable number.
It seems safe to suppose that an S-table that alters
very few characters of the alphabet would generally be
unacceptable. Is this a mistake?
Do you believe that all S-tables are equally un/acceptable?
| > Question:
| > What generally accepted principles (if any) exist
| > for judging one substitution table to be less
| > "cryptographically secure" than another?
| >
| > (To make the question a bit more realistic, suppose
| > the substitution occurs as an embedded component of
| > a more sophisticated cipher, in such a way that
| > frequency analysis doesn't moot the point.)
------------------------------
Date: Sun, 19 Nov 2000 00:54:47 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: vote buying...
=====BEGIN PGP SIGNED MESSAGE=====
David Schwartz wrote:
> David Hopwood wrote:
> > 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.)
>
> The number that allows them to vote can be a single digit that's
> different for each voter that he or she is simply shown on a screen. A
> person buying that number would have no way to know whether they were in
> fact given the correct number.
>
> Suppose, for example, that if your code number was "6", pushing
> the green button was a vote for Gor but if your code number was "7", the
> green button cast a vote for Bush.
[Call this a "blinding code". I had considered this technique before, but
it's completely impractical.]
> If someone wanted to buy my right to
> vote, they'd have to trust me when I told them my code number was "6" or
> they'd be casting my vote for the wrong person!
That's all very well in theory, but do you seriously think that there
would not be a large number of errors if voters were asked to do a
modular addition of their intended vote and their blinding code? [*]
Do you think they would be able to remember or otherwise keep track of
their blinding code between being issued with it and the election, for
that matter?
[*] AFAICS a modular addition is the simplest way of doing this that would
also be secure, although the modulus doesn't have to be very large, and
could be 100, say. 10 is too small because there are frequently more
than 10 candidates.
- --
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
iQEVAwUBOhckqTkCAxeYt5gVAQH4ZAf/W0shjxOoaxiplyMl3rMXm+xr6tZI0ore
9tHAV9WDORvXB7Pf2IKqnAm0bS4ciFckXHtT4ECvtXl5J008g5u1Ce50acRNdrj3
KgxsWXFXnj02DujCxWgxJAfO+tOtnCeri9m5KaytOUHsVJ8kZeHJaZaXtVa4sZNq
XVnqFML9h2Z8ilhGPZGmJXaxAbSekPERpGN8RM3qb1JfqyLx8dSKNlZxep58iA28
5IZ+3ZTv3Quw1nC0I8z6DQSYz3X4CSEoy8P1vJd/XdzJTmxQKGM2vMK6XhxHrFn+
mB0wUzPCyi5gwA6ik/C8pULoye0ET1BFeA2pMF43VaxqEpjrtEQeJA==
=cad7
=====END PGP SIGNATURE=====
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Client Puzzle Protocol
Date: Sun, 19 Nov 2000 01:03:32 GMT
In article <8u4dit$mub$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
> It's been quiet a while since RSA announced the client puzzle
protocol,
> in the paper they claim the protocol can me layered over TCP/IP as a
> solution to TCP SYN Flooding, but is this really possible without
> modifying TCP itself?
Yes. We've done it.
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bobby)
Subject: A Question About Multi-encrypting
Date: 18 Nov 2000 03:31:46 GMT
I hope this question isn't too mundane for this group. I am not involved
professionally with encryption but am very interested in the topic for
reasons involving the security of data at my place of employment and for
purely intellectual reasons.
My question is about securing a file. I would imagine that a file
encrypted with an algorithm such as Blowfish or Twofish or PGP or what have
you, though very secure, could eventually be cracked by someone with
experience in doing such things. But that assumes that the file was only
encrypted once, with one encryption key. How much more difficult does
multi-encrypting make it to crack into a file when using algorithms such as
these and other hard encryption algorithms? By this I mean, I encrypt a
file using encryption key-1. This results in an encrypted file. Now I
encrypt the encrypted file using a second key, resulting in a second
encrypted file. I now use THAT double encrypted file as input one more
time with a third key. Based on my limited knowledge of things, it seems
to me that it would be near impossible to crack such a file. Am I correct
in that assumption? Would using the same algorithm for all three passes
make this a weaker scheme? Would using three different algorithms make it
even more difficult to crack into the file? I read once that triple
encrypting a file was the most secure way to protect anything from any and
all prying eyes.
I would appreciate any response from you folks who post to this group. And
again, I apologize for this being such an elementary question.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: Why remote electronic voting is a bad idea (was voting through pgp)
Date: 18 Nov 2000 18:25:12 -0800
Incidentally, one of our cherished beliefs about the anonymity of the
voting booth is not always true, even in the U.S. According to
http://slate.msn.com/code/explainer/explainer.asp?Show=11/15/2000&idMessage=6509:
Explainer, yesterday you said that who we voted for cannot be
traced back to us. Is that really true?
Yes. Except in Arkansas. Alert Arkansans notified Explainer that
this year their state Supreme Court upheld a 1962 law that required
ballots to be secret, but traceable. (Given the year of the law, it
has an anti-voting-rights ring, but the Arkansas secretary of
state's office is not confirming.) The ballots are numbered and so
are the stubs. Then in the case of a contested election, under
court order the number can be traced back to the individual
voter. The justification is that accuracy is more important than
secrecy. Just think if Florida had this law! Palm Beach officials
could simply pick up a stub, match a ballot, and ask that nice
Mrs. Rabinowitz if she really did intend to vote for Pat Buchanan.
------------------------------
From: Mathew Hendry <[EMAIL PROTECTED]>
Subject: Re: A Question About Multi-encrypting
Date: Sun, 19 Nov 2000 02:30:13 +0000
On 18 Nov 2000 03:31:46 GMT, [EMAIL PROTECTED] (Bobby) wrote:
>My question is about securing a file. I would imagine that a file
>encrypted with an algorithm such as Blowfish or Twofish or PGP or what have
>you, though very secure, could eventually be cracked by someone with
>experience in doing such things.
Anything (OTP excepted) can be cracked "eventually". The algorithms you mention
(it would be a bit of a stretch to call PGP an algorithm, BTW) are probably
going to be practically secure for some time.
> But that assumes that the file was only
>encrypted once, with one encryption key. How much more difficult does
>multi-encrypting make it to crack into a file when using algorithms such as
>these and other hard encryption algorithms?
In other words: lengthen both the key and the encryption algorithm. That's fine,
but it's probably less secure (and maybe slower) than using an algorithm
specifically designed for the longer key.
One particular problem is that each bit of the key has influence over only one
stage in the encryption. Most (all?) good algorithms attempt to "spread" key
bits throughout the encryption, using a carefully designed key schedule.
To give a very simple example, if you repeatedly apply a simple subsitution
cipher you don't increase security at all over a single application, and might
actually decrease it if you choose keys carelessly.
More sophisticated algorithms only have more sophisticated weaknesses:
Triple-DES (3DES) uses a 3*56 = 168-bit key, but is thought to have an effective
strength closer to 130 bits - although I guess that is partly due to weaknesses
in [single] DES itself.
-- Mat.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A Question About Multi-encrypting
Date: Sun, 19 Nov 2000 02:29:53 GMT
In article <8v4t72$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bobby) wrote:
> I hope this question isn't too mundane for this group. I am not
involved
> professionally with encryption but am very interested in the topic for
> reasons involving the security of data at my place of employment and
for
> purely intellectual reasons.
>
> My question is about securing a file. I would imagine that a file
> encrypted with an algorithm such as Blowfish or Twofish or PGP or
what have
> you, though very secure, could eventually be cracked by someone with
> experience in doing such things. But that assumes that the file was
only
> encrypted once, with one encryption key. How much more difficult does
> multi-encrypting make it to crack into a file when using algorithms
such as
> these and other hard encryption algorithms? By this I mean, I
encrypt a
> file using encryption key-1. This results in an encrypted file. Now
I
> encrypt the encrypted file using a second key, resulting in a second
> encrypted file. I now use THAT double encrypted file as input one
more
> time with a third key. Based on my limited knowledge of things, it
seems
> to me that it would be near impossible to crack such a file. Am I
correct
> in that assumption? Would using the same algorithm for all three
passes
> make this a weaker scheme? Would using three different algorithms
make it
> even more difficult to crack into the file? I read once that triple
> encrypting a file was the most secure way to protect anything from
any and
> all prying eyes.
>
> I would appreciate any response from you folks who post to this
group. And
> again, I apologize for this being such an elementary question.
PGP is not an encryption algorithm and generally multiple-encryption is
only an issue with DES due to the small key size (and not any other
inherant flaws).
Generally anything that could substantially break something like
Blowfish may work against blowthreetimesfish or what-have-you...etc...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: ---- Internet Voting Questions
Date: Sun, 19 Nov 2000 02:54:12 GMT
> These are all arguments from lack of imagination.
... snip your analysis ...
Of course you are correct, but what I asked has not been answered.
Have there been any serious considerations for internet based voting
systems and if so, what have we learned good and bad about them, their
weaknesses, etc?
Can anyone tell me where I can go on the internet for more information
on the latest technology development for internet based voting?
--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.
Al Gore - quite possibly America's greatest threat today
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sat, 18 Nov 2000 20:08:08 -0800
David Hopwood wrote:
> That's all very well in theory, but do you seriously think that there
> would not be a large number of errors if voters were asked to do a
> modular addition of their intended vote and their blinding code? [*]
> Do you think they would be able to remember or otherwise keep track of
> their blinding code between being issued with it and the election, for
> that matter?
I'm not seriously suggesting that this technique be used, I'm simply
presenting it as proof that the problems alleged are not fundamental to
electronic voting.
DS
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A Question About Multi-encrypting
Date: Sun, 19 Nov 2000 03:30:37 GMT
On 18 Nov 2000 03:31:46 GMT, [EMAIL PROTECTED] (Bobby) wrote, in
part:
>I would imagine that a file
>encrypted with an algorithm such as Blowfish or Twofish or PGP or what have
>you, though very secure, could eventually be cracked by someone with
>experience in doing such things.
It is not believed that this is the case at present.
>Based on my limited knowledge of things, it seems
>to me that it would be near impossible to crack such a file.
If you use an encryption program in its regular way, so that the
encrypted file, instead of being random binary data, has a form like
--- BEGIN THIS-PROGRAM ENCRYPTED FILE ---
aZx79w+RP...
and then encrypt, it could end up being as easy to decrypt as if you
encrypted it once.
But as long as that particular mistake is avoided, multiple encryption
does indeed make it harder to break a cipher.
Triple encryption is favored over double encryption because of the
theoretical possibility of an attack on double encryption requiring an
immense amount of memory.
As for whether using different algorithms is stronger: if the
algorithms are different in structure, then you do have protection
against cryptanalytic attacks faster than brute force. But modern
algorithms aren't "supposed" to be vulnerable to such attacks.
There is good reason to think that the conventional wisdom is right,
and today's favored algorithms _are_ strong enough. And there are ways
to go wrong in attempting to take additional precautions, but I
believe that those dangers can be simply outlined so that they can be
avoided.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
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 20:09:57 -0800
root1657 wrote:
>
> Anthony Stephen Szopa wrote:
>
> > If you know what you are talking about then you must have resources
> > to check the behavior of the software while it is running: such as
> > a firewall or virus protection?
> >
> > Some are free, you know.
> >
> > Give us some proof if you can.
> >
> > Or are you too pathetically feeble minded?
>
> Without even having seen the program, or it's code, i would caution anyone
> against using a program written or endorced by a person with an attitude like
> that..... It just gives off a "malicious code" vibe....
> xxx
I bet you could spot a pregnant chad a mile away blindfolded.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: vote buying...
Date: 19 Nov 2000 04:46:28 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Schwartz wrote:
> I'm not seriously suggesting that this technique be used, I'm simply
>presenting it as proof that the problems alleged are not fundamental to
>electronic voting.
But others have shown that your suggested system does not work.
The chits can be sold (or you can be coerced into giving your chit
to the coercer), and hence we're back to the starting point.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker,alt.computer
Subject: XOR: A Very useful and important utility to have
Date: Sat, 18 Nov 2000 20:55:57 -0800
XOR: A Very useful and important utility to have
A few people in this news group said any XOR program is less than
useless.
If a person has available random number files, an XOR program gives
you the capability to XOR (encrypt) data.
You really don't need a fancy encryption program. Just random
numbers in a file and an XOR program.
Many people say one encryption program is really great or this
other one is really great, etc.
But many people also question just exactly how secure one or the
other really is.
If a person has available a few random number generators or can
generate random numbers from a few encryption programs they can
combine shuffling several random number files from several of these
different sources together and create a very secure collection of
random number files to be used with a simple XOR program to encrypt
data.
Just name numbering your random number files such as F0001, F0002,
F0003, etc. and make several of varying lengths to be used to XOR
files of varying lengths. Have several random number files of 1KB,
2KB, 3KB, 5KB, 10KB, 15KB, etc.
Then when you XOR a file make sure its length is no longer than the
random number file used.
Then rename the output file from this XOR process the same name as
the numbered random number file used in the XOR process.
By reading the name of such a file and knowing that this file should
be XORed with the random number file you have of the same name, you
will output the original file when you XOR these two file together.
OAR-L3 is an excellent random number generation program to use, not
only to generate random numbers, but to combine shuffling random
number files from various sources using the several shuffling
routines included with the software package.
OAR-L3 is available for worldwide direct download at:
http://www.ciphile.com
Go to the Downloads Currently Available web page.
Scroll to the bottom of the page for the blue download link for
OAR-L3.
You will also find available an XOR Software Utility there for
direct download as well.
Cheerio!
------------------------------
** 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
******************************
