Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases

2004-04-07 Thread R. A. Hettinga

--- begin forwarded text


From: Nicko van Someren [EMAIL PROTECTED]
Subject: Re: [Mac_crypto] Apple should use SHA! (or stronger) to
authenticate software releases
To: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
List-Id: Macintosh Cryptography mac_crypto.vmeng.com
List-Post: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Subscribe: http://www.vmeng.com/mailman/listinfo/mac_crypto,
mailto:[EMAIL PROTECTED]
List-Archive: http://www.vmeng.com/pipermail/mac_crypto/
Date: Wed, 7 Apr 2004 12:53:56 +0100

It's not clear to me that you need all this complexity.  All you need
if to arrange that the attacker does not know exactly what will be
signed until it has been signed.  So you append some randomness from a
good random number source to the end of the file just before you sign
it, and you're safe.

Nicko

On 6 Apr 2004, at 16:43, R. A. Hettinga wrote:
 --- begin forwarded text

 Date: Tue, 6 Apr 2004 10:33:54 +0100
 To: R. A. Hettinga [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Mac_crypto] Apple should use SHA! (or stronger) to
 authenticate software releases
 User-Agent: Mutt/1.3.28i
 From: Zefram [EMAIL PROTECTED]
...
 This disucssion suggests a simple countermeasure: put something at the
 beginning of the package that depends on all the significant content
 of the package.  For example, the first file in the archive could be
 a list of digests of individual files.  This means an attacker has to
 either process the entire archive in searching for a collision or find
 tweakable space not covered by the leading checksum file.

 Having such dead space (not trivially checksummed) is quite likely in
 an uncompressed archive.  For example, tar pads each file to an
 integral
 multiple of its block size.  However, compression of the entire archive
 will make such space more difficult to arrange.

 A more extreme approach that removes that risk entirely is to take
 the digest of two concatenated copies of the package.  Precalculation
 can still be used to speed up the search for a collision, but the
 unoptimisable tail is now guaranteed to be at least as long as the
 entire package.  I see a couple of potentially useful variations on
 this:

   0. publish Digest(Digest(Archive) || Archive)
   (similar to Digest(Archive || Archive))

   1. publish Digest(Archive || Tail) where Tail is large and public
   (increases difficulty by a fixed amount that depends on
   the length of Tail -- suitable for small packages)

 Are these approaches sound?  I'm a crypto-plumber, not a cryptographer.

 I'm wondering whether we can define a new type of cryptographic
 primitive
 here: the non-precomputable message digest.  The interesting feature of
 an NPCMD would be that computing the digests of two related messages
 cannot be optimised to take any less time than the computation of the
 digests of two unrelated messages of the same sizes.  The suggestions
 I made above are clearly not NPCMDs, but if one does

   M[0] = M   ; original message
   M[i+1] = Digest(M[i]) || M[i]
   D = Digest(M[n])   ; final digest

 with Digest being a good conventional message digest, then this
 appears to
 approach a NPCMD as n approaches infinity.  Of course, computation time
 for this construction is linear in n (for a particular message size),
 so this is not a practical way to achieve this goal.  Can a NPCMD be
 done in a more reasonable time?  I imagine structures that might lead
 to O(l*log(l)) time, where l is the message length, but that's just
 my speculation.

 -zefram

 --- end forwarded text

___
mac_crypto mailing list
[EMAIL PROTECTED]
http://www.vmeng.com/mailman/listinfo/mac_crypto

--- end forwarded text


-- 
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting Corporation http://www.ibuc.com/
44 Farquhar Street, Boston, MA 02131 USA
... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Firm invites experts to punch holes in ballot software

2004-04-07 Thread Trei, Peter


Firm invites experts to punch holes in ballot software

 The company's software is designed to let voters verify that their ballots
were properly handled. It assigns random identification numbers to ballots
and candidates. After people vote, they get a receipt that shows which
candidates they chose--listed as numbers, not names. Voters can then use
the Internet and their ballot identification number to check that their
votes were correctly counted.

This is kind of broken. Allowing the voter to get a receipt which
they take away with them for verification may allow the voter to verify
that their vote was recorded as cast, but also allows coercion and 
vote buying.

To their credit, the creators thought of this, and suggest a
partial procedural fix in the threat analysis document:

P4. Let voters discard verification receipts in poll site trash 
can and let any voter take them
Result: Buyer/coercer can't be sure voter generated verification
receipt

P5. Have stacks of random printed codebooks freely available in poll
site
Result: Vote buyer/coercer can't be sure captured codebook was used

P6. Have photos of on-screen codebooks freely available on-line
Result: Vote buyer/coercer can't be sure captured codebook was used

The first problem, or course, is that a person under threat of 
coercion will need to present the coercer with a receipt showing 
exactly the mix of votes the coercer required. This is leads 
to a combinatorial explosion of fake receipts that need to be available.

Having only one vote on each receipt might mitigate this, but it still
gets really messy.

Second, it's not clear how this protects against the coercer checking the
ballot online - will every fake also be recorded in the system, so
it passes the online check? Having both real and fake ballots in
the verification server makes me very nervous.

Its possible I've missed something - this is based on a quick glance
through the online documents, but I don't see any advantage this 
system has over the much more discussed one where the reciept is
printed in a human readable way, shown to the voter, but retained 
inside the machine as a backup for recounts.

Just my private, personal opinion.

Peter Trei

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Firm invites experts to punch holes in ballot software

2004-04-07 Thread Ian Grigg
Trei, Peter wrote:
Frankly, the whole online-verification step seems like an
unneccesary complication.


It seems to me that the requirement for after-the-vote
verification (to prove your vote was counted) clashes
rather directly with the requirement to protect voters
from coercion (I can't prove I voted in a particular
way.) or other incentives-based attacks.
You can have one, or the other, but not both, right?

It would seem that the former must give way to the latter,
at least in political voting.  I.e., no verification after
the vote.
iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


RE: Firm invites experts to punch holes in ballot software

2004-04-07 Thread Trei, Peter
 Ian Grigg[SMTP:[EMAIL PROTECTED] wrote:
 
 Trei, Peter wrote:
  Frankly, the whole online-verification step seems like an
  unneccesary complication.
 
 It seems to me that the requirement for after-the-vote
 verification (to prove your vote was counted) clashes
 rather directly with the requirement to protect voters
 from coercion (I can't prove I voted in a particular
 way.) or other incentives-based attacks.
 
 You can have one, or the other, but not both, right?
 
 It would seem that the former must give way to the latter,
 at least in political voting.  I.e., no verification after
 the vote.
 
 iang
 
Yes, that seems to be the case. Note that in the current
(non computer) systems, we have no way to assure 
that our votes  actually contributed to the total, but the 
procedural stuff of having mutually hostile observers to 
the counting process makes deliberate discarding of 
one side's votes less likely. (Non-deliberate losses - 
such as the recent failure to record cards marked 
with the wrong kind of pen - can still happen).

VoteHere, while they seem to be well-meaning, have
not solved the problem. Mercuri  Rivest have 
described how to do it right; we just need someone
to buld or retrofit the machines appropriately.

Peter Trei


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


voting

2004-04-07 Thread Perry E. Metzger

I'm a believer in the KISS principle.

A ballot that is both machine and human readable and is constructed by
machine seems ideal. You enter your votes, a card drops down, you
verify it and drop it in a slot. Ideally, the cards would be marked
with something like OCR-B so that the correspondence between machine
marking and human marking is trivial.

You can't have hanging chads or mismarks on optical cards because a
machine marks it for you. You can always do a recount, just by running
the cards through the reader again. You can prevent ballot stuffing by
having representatives of several parties physically present during
the handling of the ballot boxes -- just like now. You can verify that
the counting mechanisms are working right by manually counting if
needed.

Complicated systems are the bane of security. Systems like this are
simple to understand, simple to audit, simple to guard.


-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Firm invites experts to punch holes in ballot software

2004-04-07 Thread Paul Zuefeldt
Maybe the receipt should only allow the voter to check that his vote has
been counted. To get the detail you could require him to appear in person
with his receipt AND a photo ID or some such, then only allow him to view
his detail -- not print it.

Paul Zuefeldt

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, April 07, 2004 3:14 PM
Subject: RE: Firm invites experts to punch holes in ballot software


 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Trei, Peter
 Sent: Wednesday, April 07, 2004 1:17 PM
 [SNIP]

 Frankly, the whole online-verification step seems like an
 unnecessary complication.

Except to those of us who don't trust the system.

Implemented correctly it could be cheap and complications could be
hidden from the voter. It could be cheaper - no need to pay people to do
an audit when the people will do it for you. You only need a small
fraction of the people to verify their votes to get a high level of
confidence that the election is valid. You only need one failure to cast
doubt on the election. This requires an un-forgeable receipt that cannot
be used for coercion. Un-forgeable we have been doing for a while now
with lots of different PK options. A receipt that cannot be used for
coercion cannot give any indication to others of who you voted for.
Right now this is a big complication (at least to me - I don't know how
to create such a receipt that doesn't require mental gymnastics on the
part of the voter).

-Michael Heyman

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Blind signatures with DSA/ECDSA?

2004-04-07 Thread Eric Rescorla
Folks,

Does anyone know if there is a blind signature scheme that works with
DSA or ECDSA? I know about Camenisch, Pivetau and Stadler's Blind
Signatures Based on the Discrete Logarithm Problem (1994), but as far
as I can tell that doesn't produce straight DSA-verifiable signatures
and so is a lot less desirable than it might otherwise be.

Has there been any better work on this?

Thanks,
-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]