Rockville MD e-vote glitch
Not really crypto, but from http://www.gazette.net/stories/110707/rocknew00608_32357.shtml election judges throughout the city noticed voters whose street addresses start with the number 5 were being denied their voter cards because the database wrongly counted them as absentee voters...Those whose street numbers start with the number 5 were designated absentee ballot applicants as part of a state test program that should not have been forwarded for Election Day use. Luckily it was an off-year election so: only about 10 people were either sent to City Hall to clear up the matter or walked away from the polls without casting a ballot My house number starts with 3 :-) -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: forward-secrecy for email? (Re: Hushmail in U.S. v. Tyler Stumbo)
Adam Back wrote: On Fri, Nov 02, 2007 at 06:23:30PM +0100, Ian G wrote: I was involved in one case where super-secret stuff was shared through hushmail, and was also dual encrypted with non-hushmail-PGP for added security. In the end, the lawyers came in and scarfed up the lot with subpoenas ... all the secrets were revealed to everyone they should never have been revealed to. We don't have a crypto tool for embarrassing secrets to fade away. What about deleting the private key periodically? Like issue one pgp sub-key per month, make sure it has expiry date etc appropriately, and the sending client will be smart enough to not use expired keys. Need support for that kind of thing in the PGP clients. And hope your months key expires before the lawyers get to it. Companies have document retention policies for stuff like this... dictating that data with no current use be deleted within some time-period to avoid subpoenas reaching back too far. Hi Adam, many people have suggested that. On paper, it looks like a solution to the problem, at least to us. I think however it is going to require quite significant support from the user tools to do this. That is, the user application is going to have to manage the sense of lifetime over the message. One tool that does approach this issue at least superficially is Skype. It can be configured to save chat messages for different periods of time, I have mine set to around 2 weeks currently. But, then we run slap-bang into the problem that the *other* client also keeps messages. How long are they kept for? I'm not told, and of course even if I was told, we can all imagine the limitations of that. I hypothesise that it might be possible to use contracts to address this issue, at least for a civil-not-criminal scope. That is, client software could arrange a contractual exchange between Alice and Bob where they both agree to keep messages for X weeks, and if not, then commitments and penalties might apply. Judges will look at contracts like that and might rule the evidence out of court, in a civil dispute. OK, so we need a lawyer to work that out, and I'm definately whiteboarding here, I'm not sure if the solution is worth the effort. Which is why I am skeptical of schemes like delete the private key periodically. Unless we solve or address the counterparty problem, it just isn't worth the effort to be totally secure on our own node. We know how to do invisible ink in cryptography. How do we do its converse, fading ink? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: forward-secrecy for email? (Re: Hushmail in U.S. v. Tyler Stumbo)
an G wrote: I was involved in one case where super-secret stuff was shared through hushmail, and was also dual encrypted with non-hushmail-PGP for added security. In the end, the lawyers came in and scarfed up the lot with subpoenas ... all the secrets were revealed to everyone they should never have been revealed to. We don't have a crypto tool for embarrassing secrets to fade away. Adam Back wrote: What about deleting the private key periodically? Mail should have the following security properties: Mail that appears to come from an entity really did come from that entity. Though the recipient can prove to himself the mail came from that sender, he cannot prove it to third parties unless the sender cooperates. If the sender and the recipient discard their copies, that mail is gone forever. No one can reconstruct it, even though they have a complete record of the bits passed between the sender and recipient and complete access at a later date to the machines of the sender and recipient and the complete cooperation, possibly under extreme duress, of both sender and recipient. If the sender or the recipient keep a copy that they can access, then the guys with rubber hoses can shake it out of them, but they can only see this stuff with the cooperation, possibly under duress, of the sender or the recipient - and they only have the sender or the recipients word that this is the real stuff. If the recipient deleted his stuff, and the guys with rubber hoses look at the sender's sent box, they cannot know it is the original and unmodified sent box, and vice versa for the recipient's in box. We have the technology to accomplish all this, but not with the present store and forward architecture. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
