Cryptography-Digest Digest #183, Volume #13 Sat, 18 Nov 00 19:13:00 EST
Contents:
Re: vote buying... (David Hopwood)
Re: Q: fast block ciphers (Paul Crowley)
Re: vote buying... (David Schwartz)
Re: vote buying... (David Schwartz)
Finite fields (was Q: fast block ciphers) (David Hopwood)
Re: Client Puzzle Protocol (Benjamin Goldberg)
Re: Cryptogram Newsletter is off the wall? (Ichinin)
Re: Criteria for Simple Substitutions? ("Paul Pires")
Hardening against known plaintext attacks? (Ichinin)
Re: Cryptogram Newsletter is off the wall? ("CMan")
Re: vote buying... (David Wagner)
Re: Client Puzzle Protocol (David Wagner)
Re: vote buying... (David Schwartz)
Re: Q: fast block ciphers (Benjamin Goldberg)
----------------------------------------------------------------------------
Date: Sat, 18 Nov 2000 22:12:33 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: vote buying...
=====BEGIN PGP SIGNED MESSAGE=====
David Schwartz wrote:
> "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.
Then how does the voter know that the receipt (s)he is given is associated
with his/her vote? Remember that a coercer may be looking over the voter's
shoulder when (s)he votes.
- --
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
iQEVAwUBOhb+tTkCAxeYt5gVAQGs1Af9EEYZcqaOf8bDSzhNlHKLzMp6DXfmkLZE
SBcjnEUqRdso5PINMDjpRZNqQmhidIRop0dro+gzQlGuwbuCpnVJpJRCWUK2Uahh
sKIwFfM2lNJsvAIUxAn3gchdOovoIKHUa0vLShmNMkEeENQ/VLBUdWmBx2A7LMs9
94QDw6ds8fmtxz/OEvXdX2dc+ngvsTNICMe67BLDQvyo3PBDKJgi7fmZaL1L5/0j
5dYaEyFSqxzTkb7l39kfo/ep8yx8vlIRoZh0oIx6KEWMUnrryKnhYbI3zpYSeGoj
XxcHP2KP9iU3jVmLrqG2vAAC0WlX3isGluS+BqjvCSYmms1ueYDcew==
=1jRf
=====END PGP SIGNATURE=====
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Sat, 18 Nov 2000 22:18:28 GMT
Simon Johnson wrote:
> Blowfish is fast, as is Rijndael. Though both can use 128-bit keys,
> Blowfish has a 64-bit block and Rijndael has a 128-bit block. Analysis
> of these ciphers shows that Rijndael requires more plain-text to break
> than Blowfish but i'm not sure of the realtive speeds.
Could you give a reference for this? AFAIK neither cipher is vulnerable
to any attack faster than brute force even given the entire codebook
(all possible plaintext/ciphertext pairs).
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sat, 18 Nov 2000 14:28:28 -0800
David Hopwood wrote:
> > > 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.
> Then how does the voter know that the receipt (s)he is given is associated
> with his/her vote? Remember that a coercer may be looking over the voter's
> shoulder when (s)he votes.
There are lots of ways to do this. One way is the way I suggested,
where in a separate process from the election each voter registers to
vote and is given a one-digit code number. The coercer could look over
the voter's shoulder when he or she votes but, not knowing the code
number, couldn't tell who the voter was voting for.
I'm not saying that this is the best way to do this. I'm just saying
that it's not difficult to envision systems that don't have this
particular weakness.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sat, 18 Nov 2000 14:26:40 -0800
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. 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!
In the present system, I can sell my vote if the person buying my vote
trusts me. So nothing would change.
DS
------------------------------
Date: Sat, 18 Nov 2000 22:43:52 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Finite fields (was Q: fast block ciphers)
=====BEGIN PGP SIGNED MESSAGE=====
Thomas Pornin wrote:
> According to Paul Crowley <[EMAIL PROTECTED]>:
> > Can you give a counterexample?
>
> No -- after verification, I found that I was mistaken. All finite fields
> of same size are isomorphic.
A proof of this is given at
<http://www-math.cudenver.edu/~wcherowi/courses/finflds.html>,
incidentally.
- --
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
iQEVAwUBOhcF5DkCAxeYt5gVAQHa4Af+L+FoDA/krh8xYbWlC3M8AFJyD0Z+u9VY
zVfUm/NNx+2NNZOJnkEKhYhbDIW5UdQIZj6cJY8gvV0EggM60BECDuVE1ag/iI1L
ljyRnc/hyyn8wLjfQ605fwnEh3R783P/GfrwSrKTI0LmbHd/Lu3jl8bNpQVJgTqI
G1EHxvegxkVBbfNnemupf9DPM3zduSnZ+in9frZoIWniREZRwKo3qS85UAdkmFGp
wk6WtP/ZBOldBCykmq+CPcBu3sPP4TNKn5KB3bGJuVxiWxKTbmKBYyWEO3UYyLm8
2j999kW09J3uJkdKnzTJ0er25s44CDocOC0poRjobDQTRC2Qa1SeFw==
=c0uL
=====END PGP SIGNATURE=====
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Client Puzzle Protocol
Date: Sat, 18 Nov 2000 23:18:05 GMT
Darren New wrote:
>
> [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?
>
> Where's this discussed?
>
> There's an interesting discussion at http://grc.com/r&d/NoMoreDoS2.htm
> that looks to me like it would work for a large class of DoS attacks.
I do see a possible attack on grc's solution, though...
Suppose an attacker obtains one valid server->client SYN/ACK packet. He
then subtracts the CISN from the SISN, to obtain the encrypted token
RC5(ClientIP). He then generates random (or even sequential) CISN
values, and makes up fake ACK packets; he does this by having a fixed
ClientIP, so that he knows RC5(ClientIP), and thus can create valid SISN
values. Of course, since flooding like this can be easily detected,
it's entirely possible that it could be prevented some other way.
The problem can be solved, however, by replacing the
(RC5(ClientIP)+CISN) with some secure (i.e. keyed), one-way
transformation of ClientIP and CISN into the SISN. The problem with
this, is of course that ISNs now aren't guaranteed to be monotonically
increasing, but will instead appear to be random -- and might even have
collisions. The likelyhood of a collision is determinable by the
birthday paradox.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Mon, 13 Nov 2000 19:53:18 +0100
Tom St Denis wrote:
> Like a trojan horse proximity is a problem. Albeit sometimes it may be
> easier to install trojans on foolish users (or anyone using outlook)
> but still for the most part the attack is remote.
Well, almost correct, if i inject a hack into a dns
server and your computer rushes of to (what it believes
to be) "update.company.com" it will instead go to the
site "meet.my.trojan.com" and get it's "updates" from
that site. There are also ways to execute remote commands
on a server by various exploits and continue onwards from
there. Some (non patched) email clients also have these
"features".
Regards,
Ichinin (.SE)
"Anything-over-IP-&-802.11"-Solutions provider.
===============================================================
NOTE: EMAIL ADDRESS IS FOR SPAMMERS, IT WILL BOUNCE REGARDLESS.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Criteria for Simple Substitutions?
Date: Sat, 18 Nov 2000 15:21:54 -0800
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.
>
> 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.)
>
> --r.e.s.
>
>
>
>
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Hardening against known plaintext attacks?
Date: Mon, 13 Nov 2000 19:56:59 +0100
Hi.
Would it be possible to make a algorithm that makes
known plaintext attacks harder?
(i.e. against file headers using keyed sboxes)
I've found indicators with such dynamic constructions
as stream ciphers with self modifying internals, that
this may be a VERY hard thing to do.
I've also found out that great emphasis should be taken
on checking if the key is crap or not before running it
in the self modification... "thing".
Any comments?
Thanks,
Glenn
--
Ichinin (.SE)
"Anything-over-IP-&-802.11"-Solutions provider.
===============================================================
NOTE: EMAIL ADDRESS IS FOR SPAMMERS, IT WILL BOUNCE REGARDLESS.
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sat, 18 Nov 2000 16:30:55 -0700
Absolutely true. I made these same arguments more than a year ago in this
forum and others.
In fact, we even wrote a demo PGP passphrase grabbing program to show how
easy it was to do (it was not a Trojan in that it was not designed to be
completely stealthy).
There is a very large and successful cottage industry which we started along
with but separately from AccessData corp. There are now many many vendors
of password recovery programs all over the world. Those programs that use
good password encryption can be bypassed in code.
To see how easy it is to invade Windows code and make it do your will,
download our Wordmon software http://www.crak.com This software prevents
application of passwords to Word, Excel and other documents.
If you want a really abject lesson on how intractable the problem is, just
write a popular piece of software and attempt to protect it with a security
code. You will soon find pirate, broken versions all over the net. It
really brings reality to the fore. If that is not enough, check out the work
of Fravia and others of his ilk.
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Bruce Schneier" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Sat, 18 Nov 2000 14:28:18 GMT, Tom St Denis <[EMAIL PROTECTED]>
> wrote:
>
> >About the signatures. Perhaps Mr Schneier forgot that private keys are
> >often password protected. Unless "Alice" has a poor or easy to guess
> >password it's not so easy to use her signature without her knowing.
> >And like real signatures I could forge it anyways without her knowing.
>
> We've reached the point where passwords do not provide security
> against off-line attacks.
>
> There is an upper limit of what people can be reasonably expected to
> remember and type in. And over the years, the efficacy of dictionary
> attacks has increased. A few years ago, the two crossed.
>
> Look at programs like L0phtCrack.
>
> In any case, passwords are besides the point. If I have a Trojan on
> your computer, I can easily wait until you type your password and
> decrypt your private key...and then steal it.
>
> Bruce
> **********************************************************************
> Bruce Schneier, Counterpane Internet Security, Inc. Tel: 408-556-2401
> 3031 Tisch Way, Suite 100PE, San Jose, CA 95128 Fax: 408-556-0889
> Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: vote buying...
Date: 18 Nov 2000 23:39:25 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Schwartz wrote:
> 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. 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!
How are you going to distribute these code numbers (and process them
once they are received) in a way that does not compromise anonymity?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Client Puzzle Protocol
Date: 18 Nov 2000 23:44:05 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
See RFC 1948 for what is arguably the right way to generate
unpredictable TCP initial sequence numbers in the way you want.
ftp://ftp.isi.edu/in-notes/rfc1948.txt
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: vote buying...
Date: Sat, 18 Nov 2000 15:58:20 -0800
David Wagner wrote:
>
> David Schwartz wrote:
> > 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. 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!
>
> How are you going to distribute these code numbers (and process them
> once they are received) in a way that does not compromise anonymity?
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.
As a second level of anonymization, you turn in this chit in exchange
for a voter identification number (no ID is requested at that time). If
you still don't think this is anonymous enough, you can turn this 'type
I chit' in for a 'type II chit' which you pull out of a large box. You
can then turn the type II chit in for a voter identification number.
This way, nobody can match your voter identification number to you
(without your help).
When you are issued your voter identification number, you are also
shown your one-digit key code, which you must memorize. The key code is
then separated from the voter identification number. The two are only
unified again when it comes time to tally the results.
Again, I'm not advocating specific systems or methods (as the method
I'm suggesting above has flaws of its own). I'm just saying that it's
possible to develop electronic voting systems that don't have the
particular weaknesses that some people seem to think they must have. It
will, however, take some very clever people to put together an excellent
system.
DS
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Sun, 19 Nov 2000 00:09:57 GMT
Douglas A. Gwyn wrote:
>
> Pranke wrote:
> > 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 ?
> > While using a block cipher as stream cipher is indeed trivial.
>
> To the contrary, a block cipher requires that PT be encrypted
> in chunks rather than a single character at a time; if you
> pervert a block cipher into a key generator, then yes the key
> can be used in a stream cipher, albeit one subject to
> exploitation, because that is not using the block cipher in
> its designed enciphering role.
How are Counter, OFB, or CFB, not "the designed enciphering role"?
> A stream cipher *is* conceptually a block cipher, if you merely
> consider the PT as occurring in chunks. A really good stream
> cipher (not a mere key generator) will in fact convolve several
> characters with, in effect, a sliding window, which differs
> from the usual block cipher only in that the latter does not
> have overlapping windows.
Given a block cipher algorithm, and a block of ciphertext in context
(eg, with the previous block if CBC was used, the previous N bits if CBC
was used, the location in the stream if counter mode was used, etc), one
can easily get the plaintext.
Given a stream cipher algorithm, and a block of ciphertext, the only way
of getting the plaintext except by running the stream cipher forward
until the current location has been reached.
I don't see how to turn the second type of algorithm into the first type
of algorithm, whereas OFB mode is a simple transformation of the first
type to the second type.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
** 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
******************************
