RE: Elcomsoft trying to patent faster GPU-based password cracker

[Trei, Peter]

I was the person who originated the DES Challenges at RSA, and also
helped set up and run them.

I knew that there was a stealth effort underway at SGI, but didn't 
know any of the details. 

A good deal of cool stuff came out of the contests.

Other prior art against this patent would include using the DSP
chip in the Amiga graphics set for non-graphics purposes, which
was often done back in the 80s.

Peter Trei

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Farquhar 
(ifarquha)
Sent: Wednesday, October 24, 2007 7:35 PM
To: 'Cryptography'
Subject: RE: Elcomsoft trying to patent faster GPU-based password cracker

ROTFL.

When SGI's "stealth" DES Challenge project was underway in 1997, it's main 
client ran on the host's (MIPS) CPU(s), implemented with a variant of Eli 
Biham's bit-slice DES implementation.  The 64-bit 195MHz R1 could do 2.5M 
keys/sec.  I was peripherally involved in the project.

One of the things I was looking into was offloading the client into the VICE 
ASIC on the O2.  The VICE ASIC was a compression offload engine, and combined 
with the MACE ASIC (which had the 3D rendering pipeline), provided graphics 
support on the O2.  At the time, SGI put a workstation on everyone's desk in 
the company, so there were thousands of O2's around the company.

The VICE itself had two CPU's in it, the "MSP" which was a R4000-derived core 
with a 128bit vector unit, and the "BSP" which was a custom little RISC core 
designed for efficiently slicing non-word-aligned multimedia bit streams.  
Biham's algorithm would have run beautifully on the VICE.

I'd just gotten the devkit when the project came to an end with DESCHALL's 
successful keyfind.

So I'm feeling a little bit of déjà vu about Elcomsoft's patent here.  
Offloading keyfinding algorithms to a programmable graphics accelerator.  Wow, 
sounds *very* familiar.  But alas, probably not sufficient for a prior art 
claim.  Gotta also wonder if the mailing list traffic would still exist in SGI 
too.

Mind you, if the patent system wasn't totally broken, this application would 
fail the obviousness test anyway.  The GPU's mentioned below are basically just 
optimized little co-processors anyway.  How much innovation is there in 
offloading crypto to a coprocessor? 

Ian.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Thursday, 25 October 2007 3:25 AM
To: Cryptography
Subject: Elcomsoft trying to patent faster GPU-based password cracker

From:

   

  Moscow, Russia - October 22, 2007 - ElcomSoft Co. Ltd. has
  discovered and filed for a US patent...Using the "brute force"
  technique of recovering passwords, it was possible, though
  time-consuming, to recover passwords from popular
  applications. For example...Windows Vista uses NTLM hashing
  by default, so using a modern dual-core PC you could test up to
  10,000,000 passwords per second, and perform a complete
  analysis in about two months. With ElcomSoft's new technology,
  the process would take only three to five days..Today's [GPU]
  chips can process fixed-point calculations. And with as much as
  1.5 Gb of onboard video memory and up to 128 processing
  units, these powerful GPU chips are much more effective than
  CPUs in performing many of these calculations...Preliminary
  tests using Elcomsoft Distributed Password Recovery product
  to recover Windows NTLM logon passwords show that the
  recovery speed has increased by a factor of twenty, simply by
  hooking up with a $150 video card's onboard GPU.

-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]

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

Re: question re practical use of secret sharing

[Trei, Peter]

RSA's BSAFE 6.2.1.0 supports Bloom-Shamir secret sharing.

Peter Trei
Principal Engineer
RSA: the Security Division of EMC.
Disclaimer: I am not a spokesperson for RSA or EMC.


-Original Message-
Charles Jackson asks:

> A quick question.

> Is anyone aware of a commercial product that implements secret 
> sharing? If so, can I get a pointer to some product literature?

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

RE: Russian cyberwar against Estonia?

[Trei, Peter]

Bill Stewart wrote:

> At 01:04 PM 5/18/2007, Trei, Peter wrote:
>> If the Russians aren't behind this, who else should be suspected? It 
>> isn't like Estonia has a wide selection of enemies. :-)

> There are three likely suspects
> - the actual Russian government (or some faction thereof)
> - Russian Mafia for whatever reasons (might not be distinct from a 
> faction of the government,
> and usually if the Mafia's involved they're polite enough to
> send a note demanding money or something.)
> - Some teenage hacker who got annoyed at some other teenage hacker
> because they got into an argument on WoW or Myspace
> and decided to DDOS him (usually attacks like that
> don't take down much more than a small ISP or a university,
> but like "D00d, you're so 0wn3d, I can take down ur whole
*country*" :-)

> The latter isn't as far-fetched as it sounds (well, ok a bit...)

This threatens to get off-topic. To drag it back, I'll note that NATO
has
sent electronic warfare experts to observe and advise, and there is much
speculation as to how countries should respond to such cyber attacks -
at what point do they become an act of war, and how much certainty of
the source must there be to merit a response?

I guess its possible this was a random hacker, but the timing seems 
implausible. Aside from the DDOS attacks, many Estonian websites have 
been vandalized, and the vandals made it clear the moving of the 
monument was their motivation. 

Check out:
http://www.economist.com/world/europe/displaystory.cfm?story_id=9163598

In addition, Estonia's embassy in Moscow has been blockaded, Russia has
cut off oil and coal shipments, and closed some road and rail links. 
Putin has described the move as a 'desecration'. This is a major
diplomatic feud.

In fairness, its worth noting that the issue is also mixed up
in Estonian electoral politics:

http://news.bbc.co.uk/1/hi/world/europe/6645789.stm

The timing of the electronic attacks, and the messages left by
vandals, leave little doubt that the 'Bronze Soldier' affair is
the motivating factor. Whether Russian Government agents were
involved in the attacks is not proven, but certainly seems possible.

Peter Trei

Disclaimer: My own opinions; not my employers.
Full disclosure: My ancestry is half Estonian.




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

RE: Russian cyberwar against Estonia?

[Trei, Peter]

Dave Korn wrote:
>On 18 May 2007 05:44, Alex Alten wrote:

>> This may be a bit off the crypto topic,
>  You betcha!
>>  but it is interesting nonetheless.
>> 
>> Russia accused of unleashing cyberwar to disable Estonia 
>> http://www.guardian.co.uk/print/0,,329864981-103610,00.html
>> 
>> Estonia accuses Russia of 'cyberattack'
>> http://www.csmonitor.com/2007/0517/p99s01-duts.html


>Any IP address you find in a packet of a DDoS 
> coming towards you is pretty >likely not to be the "source" 
> of the attack.  So far there's no evidence to show anything 
> other than that the russian .gov is just as liable to have 
> virused and botted machines on its internal nets as the US 
> .gov.

1. Do you have any particular evidence that any significant
number of  US .gov machines are bots? They may well be, just 
I haven't heard this.

2. If you read the articles, you'll find that there is a
lot of circumstancial evidence to support the notion that
the attacks are from Russia or Russia-sympathizers. The
government recently moved a Soviet war memorial from the
center of town out to a military cemetary in the suburbs, an
action that Putin condemned as 'desecration', and which led
to a fatal riot by ethnic Russians in Tallinn, as well as 
attacks on the Estonian embassy in Moscow.

If the Russians aren't behind this, who else should be
suspected? It isn't like Estonia has a wide selection of 
enemies. :-)

Peter Trei




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

RE: padlocks with backdoors - TSA approved

[Trei, Peter]

Taral wrote:

> I'm just waiting for someone with access to photograph said keys and 
> post it all over the internet.

Let us hope that happnes - it won't make passenger security worse, and
would 
demonstrate that The Emperor Has No Clothes.

Even if that doesn't happen, it is presumabley feasible to
reverse-engineer
the keys by dismantling the locks.

Peter Trei

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

RE: Entropy of other languages

[Trei, Peter]

Travis H. wrote:

On Sun, Feb 04, 2007 at 03:46:41PM -0800, Allen wrote:
[...]

> What about other languages? Does anyone know the relative entropy of 
> other alphabetic languages? What about the entropy of ideographic 
> languages? Pictographic? Hieroglyphic?

IIRC, it turned out that Egyptian heiroglyphs were actually syllabic,
like Mesopotamian, so no fun there.  Mayan, on the other hand, remains
an enigma.  I read not long ago that they also had a way of recording
stories on bundles of knotted string, like the end of a mop.

The string-encoding system was Incan, not Mayan. They're called
'quipus', and 
while they contain a lot of numeric data, its highly debated whether
they were 
a generalized writing system (most experts seem to doubt it).

The Maya used an logosyllabic writing system which has been deciphered,
most of the progress having been made in the last 25 years or so.

Peter Trei


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

FW: Entropy of other languages

[Trei, Peter]

Steven M. Bellovin wrote:

> 
> On Sun, 04 Feb 2007 15:46:41 -0800
> Allen <[EMAIL PROTECTED]> wrote:
> 
> > Hi gang,
> > 
> > An idle question. English has a relatively low entropy as a
> language.
> > Don't recall the exact figure, but if you look at words that start 
> > with "q" it is very low indeed.
> > 
> > What about other languages? Does anyone know the relative entropy of

> > other alphabetic languages? What about the entropy of ideographic 
> > languages? Pictographic? Hieroglyphic?
> > 
> It should be pretty easy to do at least some experiments today -- 
> there's a lot of online text in many different languages.  Have a look

> at http://www.gutenberg.org/catalog/ for freely-available books that 
> one could mine for statistics.

As a very rough proxy, look at the length of the same text in different
translations. 

My father was in advertising in Europe. When they laid out a print ad,
they always did so using the German text. If the German fit, any other
language they were interested in would do so as well.

Now that I work (among other things) on cellphone applications, I'm
running into similar issues in internationalizing text on tiny screens.

Peter Trei

Disclaimer: This is a personal opinion. It may or may not jibe with my
employer's opinion.


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

RE: SSL Cert Prices & Notes

[Trei, Peter]

It is with some irony I note that this message from
Peter Saint-Andre failed a signature check - startcom
isn't among the trusted roots in my copy of Outlook.

Peter Trei
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre
Sent: Wednesday, August 09, 2006 1:05 AM
To: John Gilmore
Cc: cryptography@metzdowd.com
Subject: Re: SSL Cert Prices & Notes

[...]

Have you looked at StartCom?

https://cert.startcom.org/

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml


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

RE: Unforgeable dialog.

[Trei, Peter]

Piers Bowness wrote:

> This is concept is surprisingly complex. Once the attacker sees the
"secure" dialog, > what prevents them from using the same techniques
and/or code to create a visually >  > identical spoof? 

(Hi Piers!)

I actually dealt with this in a former job, where I wrote a proxy
for Xwindows which did similar decoration for trusted and untrusted
X clients.

The trick is to invert the indicators - your rendering engine (whether
an Xwindows server, browser, or a windowing OS) has final say over 
the outermost frame of all windows.

You mark the *untrusted* ones in the outer frame - a malicous client can
do whatever it wants inside its windows, but it can't overwrite and hide
the untrusted indicators in the outer frame. (We put a fat black border
around them).

Of course, if you run on an OS where any app can modify any binary,
you're SOL.

Peter Trei

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

RE: thoughts on one time pads

[Trei, Peter]

You missed the old standby - the microwave oven.

The disk remains physically intact (at least after the
5 seconds or so I've tried), but a great deal of pretty
arcing occurs in the conductive data layer. Where the
arcs travel, the data layer is vapourized. 

The end result is an otherwise intact disk in which the
data layer is broken up into small intact islands 
surrounded by clear channels. It might be interesting
to try a longer burn, in which case you might also
want to put a glass of water in with the disk(s) to
preserve the microwave's electronics.

This is probably less effective than the other methods
you've described, but its very fast and leaves no noxious
residues. It also uses a very commonly available tool.

Peter Trei

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann
Sent: Saturday, January 28, 2006 2:25 AM
To: cryptography@metzdowd.com; [EMAIL PROTECTED]
Subject: Re: thoughts on one time pads

Jonathan Thornburg <[EMAIL PROTECTED]> writes:

>Melting the CD should work... but in practice that takes a specialized
"oven"
>(I seriously doubt my home oven gets hot enough), and is likely to 
>produce toxic fumes, and leave behind a sticky mess (stuck to the 
>surface of the specialized oven).

For no adequately explored reason I've tried various ways of physically
destroying CDs:

- Hammer on hard surface: Leaves lots of little fragments, generally
still stuck
  together by the protective coating.

- Roasting over an open fire: Produces a Salvador Dali effect until they
catch
  fire, then huge amounts of toxic smoke ("fulfilling our carbon tax
quota"
  was one comment) and equally toxic-looking residue.

- Propane torch: Melts them without producing combustion products.

- Skilsaw: Melts them together at the cutting point, rest undamaged.

- Axe: Like skilsaw but without the melting effect.

- Using the propane torch and hammer to try and drop-forge a crude
double-
  density CD: Messy.

Peter.


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

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

RE: long-term GPG signing key

[Trei, Peter]

Alexander Klimov wrote:

>On Wed, 11 Jan 2006, Ian G wrote:

>> Even though triple-DES is still considered to have avoided that trap,

>> its relatively small block size means you can now put the entire 
>> decrypt table on a dvd (or somesuch, I forget the maths).

> This would need 8 x 2^{64} bytes of storage which is approximately 
> 2,000,000,000 DVD's (~ 4 x 2^{32} bytes on each).

> Probably, you are referring to the fact that during encryption of 
> a whole DVD, say, in CBC mode two blocks are likely to be the 
> same since there are an order of 2^{32} x 2^{32} pairs.

I've actually seen something like this happen in real life. 

As you know, RSA has been running a series of 'Secret Key 
Challenges', wherein we ask people to try to brute-force 
messages encrypted with RC5 at various keystrengths. There is
a cash prize for the person turning in the correct response.
The messages are encrypted in CBC mode with 32 bit blocks. 
The start of the message has a known plaintext

Most of the recent challenges have been won by distributed.net.
While they were working on the 64 bit challenge, I received an
email saying that a proposed solution had been found, and was asked
to check it. (We set up the challenges in such a way that the
correct keys are unknown, even to us). 

The supplied key correctly decrypted the first block, but the
rest were gibberish. After scratching our heads, we realized 
that d.net had found a collision.

It was almost a year later they found the correct key, for the
$10,000 prize. They immediately started on the 72 bit challenge.
(I'm not holding my breath).

Peter Trei



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

RE: Another entry in the internet security hall of shame....

[Trei, Peter]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Peter Saint-Andre
> Sent: Wednesday, August 24, 2005 4:56 PM
> To: cryptography@metzdowd.com
> Subject: Re: Another entry in the internet security hall of shame
> 
> 
> Tim Dierks wrote:
> > [resending due to e-mail address / cryptography list 
> membership issue]
> > 
> > On 8/24/05, Ian G <[EMAIL PROTECTED]> wrote:
> > 
> >>Once you've configured iChat to connect to the Google Talk 
> service, you may
> >>receive a warning message that states your username and 
> password will be
> >>transferred insecurely. This error message is incorrect; 
> your username and
> >>password will be safely transferred.
> > 
> > 
> > iChat pops up the warning dialog whenever the password is 
> sent to the
> > server, rather than used in a hash-based authentication protocol.
> > However, it warns even if the password is transmitted over an
> > authenticated SSL connection.
> > 
> > I'll leave it to you to decide if this is:
> >  - an iChat bug
> >  - a Google security problem
> >  - in need of better documentation
> >  - all of the above
> >  - none of the above
> 
> It seems Google is assuming that SASL PLAIN is acceptable once you've 
> completed STARTTLS on port 5222 (or if you've connected via 
> SSL on the 
> old-style port 5223). Decide for yourself if that's "secure" 
> and whether 
> the iChat warning is justified.
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.shtml

Ironically, Peter's message above kicked off warning
dialogs from MS Outlook, since it was signed using a keypair
signed with Peter's own self-signed root, which was not in 
MSO's list of trusted
roots.

Self-signed certs are only useful for showing that a given
set of messages are from the same source - they don't provide
any trustworthy information as to the binding of that source
to anything.

Peter Trei
(not digitally signed, and not pretending to be)




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

From [IP] i secure cell phone via software

[Trei, Peter]

Interesting encrypted VoIP application for
Symbian GSM phones.

Peter Trei

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Behalf
> Of David Farber
> Sent: Monday, April 25, 2005 9:58 AM
> To: Ip
> Subject: [IP] i secure cell phone via software
> 
> 
> http://www.silentel.sk/default.php?lang=2
> 

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

FW: [IP] One cryptographer's perspective on the SHA-1 result

[Trei, Peter]

Full disclosure: Burt Kaliski and I share an employer.

Peter Trei

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
Of David Farber
Sent: Wednesday, February 23, 2005 7:48 PM
To: Ip
Subject: [IP] One cryptographer's perspective on the SHA-1 result



From: "Kaliski, Burt" <[EMAIL PROTECTED]>
Subject: One cryptographer's perspective on the SHA-1 result
To: <[EMAIL PROTECTED]>
Date: Wed, 23 Feb 2005 19:43:43 -0500

Hi Dave --

As you might expect, the recent breakthrough on SHA-1 hash was a topic of
widespread discussion at the annual RSA Conference last week in San
Francisco.  Commercial cryptography is one of few fields in IT which has
totally absorbed the "open review" process.  We know from experience that an
ongoing and aggressive analysis of our current technology, searching out
potential weaknesses, is a critical part of the process by which we
strengthen it for the future.

RSA Laboratories has just posted a brief note on the recent SHA-1 result, to
supplement our earlier notes about MD5 and other hashes, at
http://www.rsasecurity.com/rsalabs.

In my opinion, the latest result on SHA-1 -- once confirmed -- will be one
of the most significant results in cryptanalysis in the last decade.  Hard
work indeed brings a profit, as the proverb says, and the perseverance of
Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu appears to have paid off with
this unexpected special attack on SHA-1 that can find collisions in less
than the promised 2^80 threshold.

It is a delight to congratulate the Shandong University team on their
achievement, and especially Dr. Yiqun Lisa Yin, for many years my colleague
at RSA Laboratories, and one of the co-inventors of RSA Security's RC6 block
cipher.

This attack seems to have uncovered an unexpected weakness in one of the
essential properties of SHA-1, a one-way hash function with a 160-bit
output.  Essentially, this new research suggests that it is considerably
less difficult than expected to create two somewhat different data files
that can be reduced and compressed to an identical hash value.
Cryptographers call these "collisions" in hash outputs.

A hash function takes a variable-length digital input and coverts it into a
fixed-length pseudo-random hash value that can serve as a useful
"fingerprint" for the input file.  A one-way hash function like SHA-1 is
easy to compute in one direction, but it's very difficult to reconstitute
the initial file from the hash value.  A good hash function is also expected
to be "collision-free." That is, it should be hard to generate two input
files which, put through the hash function, generate the same hash value.
(Hash functions collisions must exist, of course, since the hash inputs can
be longer than the outputs -- but the design goal is to make them hard to
find in practice.)

These attributes have made the one-way hash one of the most useful
"primitives" in modern cryptography.  Hash functions are, for example,
essential in deriving message authentication codes (MACs) and "message
digests," the small file that is actually cryptographically "signed" to
create a "digital signature" for larger files, in a typical public key
crypto application.

MIT Professor Ron Rivest, one of the founders of RSA Security, created three
one-way hashes that were widely used by cryptographers over the past 20
years (MD2, MD4, and MD5), but each of those was eventually deprecated as
subtle weaknesses were discovered that suggested that the internal design
was less robust than desired against potential future attacks.

Any successful attack on SHA-1 based on the new result would still involve a
huge amount of computer processing, so this latest research is unlikely (as
many have said) to have any significant impact on past or current
applications.  It is, however, a wake-up call for cryptographers and the
industry leaders concerned with the long-term vitality of our technology.

The SHA (aka SHA-0) hash function was developed for the US government in
1995 for use within the Digital Signature Standard.  Its design was based on
MD4.  SHA was upgraded to SHA-1 early in its life cycle, apparently to
address undisclosed weaknesses discovered by the NSA, and today SHA-1 is the
industry standard.  It is widely used and has been trusted by both
developers and applied crypto engineers, although routine efforts to enhance
SHA-1 with longer output values have led to the quiet development of
SHA-256, SHA-385, and SHA-512 as design options for long-term applications.

Although RSA Security, and most standards organizations, have recommended
the use of SHA-1 for several years, Rivest's MD5 is still widely used in
many applications despite research in the 1990s that discovered "pseudo"
collisions within the internal operations of MD5.  Then, last summer, there
were additional results on MD5 that led many cryptographers to urge the
abandonment of MD5 for SHA-1, which had withstood a great deal of analysis
and was widely believed to be "stil

RE: SHA1 broken?

[Trei, Peter]

Actually, the final challenge was solved in 23 hours, about
1/3 Deep Crack, and 2/3 Distributed.net. They were lucky, finding
the key after only 24% of the keyspace had been searched.

More recently, RC5-64 was solved about a year ago. It took
d.net 4 *years*. 

2^69 remains non-trivial.

Peter


-Original Message-
From: [EMAIL PROTECTED] on behalf of Dave Howe
Sent: Thu 2/17/2005 5:49 AM
To: Cypherpunks; Cryptography
Subject: Re: SHA1 broken?
 
Joseph Ashwood wrote:
  > I believe you are incorrect in this statement. It is a matter of public
> record that RSA Security's DES Challenge II was broken in 72 hours by 
> $250,000 worth of semi-custom machine, for the sake of solidity let's 
> assume they used 2^55 work to break it. Now moving to a completely 
> custom design, bumping up the cost to $500,000, and moving forward 7 
> years, delivers ~2^70 work in 72 hours (give or take a couple orders of 
> magnitude). This puts the 2^69 work well within the realm of realizable 
> breaks, assuming your attackers are smallish businesses, and if your 
> attackers are large businesses with substantial resources the break can 
> be assumed in minutes if not seconds.
> 
> 2^69 is completely breakable.
>Joe
   Its fine assuming that moore's law will hold forever, but without 
that you can't really extrapolate a future tech curve. with *todays* 
technology, you would have to spend an appreciable fraction of the 
national budget to get a one-per-year "break", not that anything that 
has been hashed with sha-1 can be considered breakable (but that would 
allow you to (for example) forge a digital signature given an example)
   This of course assumes that the "break" doesn't match the criteria 
from the previous breaks by the same team - ie, that you *can* create a 
collision, but you have little or no control over the plaintext for the 
colliding elements - there is no way to know as the paper hasn't been 
published yet.



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

RSA Conference, and BA Cypherpunks

[Trei, Peter]

Once again, the RSA Conference is upon us, and many of the 
corrospondents on these lists will be in San Francisco. I'd like to
see if anyone is interested in getting together. We've done this
before.

At past conferences, we've had various levels of participation, 
from 50 down to 3. Since the BAC Physical Meetings seem
to have pretty well died out, I'd like to propose that those
of us who are interested get together for lunch or dinner 
at some point.

I'll be arriving on site Monday afternoon, and leaving Friday
morning. Thursday night, at least, is already spoken for.

At the moment, it looks like Monday or Tuesday night 
may be the best, though a lunch is also possible.

Any takers?

Peter Trei
[EMAIL PROTECTED]

RSA Data Security Conference
Dates: Feb 14-18 2005
Place: Moscone Center, San Francisco

http://www.rsaconference.com 

While the full conference is rather expensive, note
that you can get a free Expo pass if you register online
by 5pm Feb 14th.

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

RE: Dell to Add Security Chip to PCs

[Trei, Peter]

Erwann ABALEA
> On Wed, 2 Feb 2005, Trei, Peter wrote:
> 
> > Seeing as it comes out of the TCG, this is almost certainly
> > the enabling hardware for Palladium/NGSCB. Its a part of
> > your computer which you may not have full control over.
> 
> Please stop relaying FUD. You have full control 
> over your PC, even if this one is equiped with 
> a TCPA chip. See the TCPA chip as a hardware 
> security module integrated into your PC. An API 
> exists to use it, and one if the functions of 
> this API is 'take ownership', which has the effect of
> erasing it and regenerating new internal keys.

Congratulations on your new baby.

Working in the security business, paranoia is pretty
much a job requirement. "What's the worst that could 
happen?" is taken seriously.

The best that can happen with TCPA is pretty good -
it could stop a lot of viruses and malware, for one
thing.

But the worst that can happen with TCPA is 
pretty awful.

It could easily be leveraged to make motherboards
which will only run 'authorized' OSs, and OSs
which will run only 'authorized' software.

And you, the owner of the computer, will NOT
neccesarily be the authority which gets to decide
what OS and software the machine can run.

If you 'take ownership' as you put it, the internal
keys and certs change, and all of a sudden you
might not have a bootable computer anymore.

Goodbye Linux.
Goodbye Freeware.
Goodbye independent software development.

It would be a very sad world if this comes
to pass.

Peter Trei

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

RE: Dell to Add Security Chip to PCs

[Trei, Peter]

Seeing as it comes out of the TCG, this is almost certainly
the enabling hardware for Palladium/NGSCB. Its a part of
your computer which you may not have full control over.

Peter Trei


Tyler Durden
> ANyone familiar with computer architectures and chips able to 
> answer this 
> question:
> 
> That "chip"...is it likely to be an ASIC or is there already 
> such a thing as 
> a security network processor? (ie, a cheaper network 
> processor that only 
> handles security apps, etc...)

> 
> -TD
> 
> >From: "R.A. Hettinga" <[EMAIL PROTECTED]>
> >HOUSTON -- Dell Inc. today is expected to add its support to 
> an industry
> >effort to beef up desktop and notebook PC security by installing a
> >dedicated chip that adds security and privacy-specific 
> features, according
> >to people familiar with its plans.
> >
> >Dell will disclose plans to add the security features known 
> as the Trusted
> >Computing Module on all its personal computers. Its support 
> comes in the
> >wake of similar endorsements by PC industry giants Advanced 
> Micro Devices
> >Inc., Hewlett-Packard Co., Intel Corp. and International 
> Business Machines
> >Corp. The technology has been promoted by an industry 
> organization called
> >the Trusted Computing Group.
> 
> 

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

RE: Banks Test ID Device for Online Security

[Trei, Peter]

R.A. Hettinga wrote:

> Okay. So AOL and Banks are *selling* RSA keys???
> Could someone explain this to me?
> No. Really. I'm serious...
> 
> Cheers,
> RAH
> 

The slashdot article title is really, really misleading.
In both cases, this is SecurID.

Peter

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

RE: RSA Implementation in C language

[Trei, Peter]

Admittedly somewhat old and creaky, but try Googling 
RSAREF. I don't know where that stands for IP rights
(presumably we still have copyright), bout for
research it's a startin point.



Peter


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Sandeep N
> Sent: Monday, November 29, 2004 3:17 AM
> To: [EMAIL PROTECTED]
> Subject: RSA Implementation in C language
> 
> 
> Hi,
> 
> Can anybody tell me where I can get an implementation of RSA
> algorithm in C language? I searched for it, but could not locate one.
> I would be grateful to you if you could give me the location of the
> source code.
> 
> Thanks and Regards,
> Sandeep
> 
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> [EMAIL PROTECTED]
> 

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

RE: Financial identity is *dangerous*? (was re: Fake companies, real money)

[Trei, Peter]

James A. Donald wrote:

> R.A. Hettinga wrote:
> > [The mobile phone is] certainly getting to be like Chaum's
> > ideal crypto device. You own it, it has its own I/O, and it
> > never leaves your sight.
> 
> Is there a phone that is programmable enough to store secrets 
> on and sign and decrypt stuff?

I've been programming phones and PDAs for several years.
They are certainly powerful enough for symmetric operations.
Some at the higher end can to public key operations at a
reasonable speed. The lower end ones can't. Try taking a
look at the new Treos, the newer PocketPC devices, and
phones such as the Motorola A760.

> The ideal crypto device would be programmed by burning new 
> proms, thus enabling easy reprogramming, while making it 
> resistant to trojans and viruses. 

Some of the devices partition their storage, with portions
that are easily modified, and portions which are more
secure. The carriers generally want to prevent users from
modifying the SW in ways which could enable fraud or damage
the network, yet allow downloads of games, apps, etc.

Peter


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

RE: Financial identity is *dangerous*? (was re: Fake companies, real money)

[Trei, Peter]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Aaron Whitehouse
> Sent: Saturday, October 23, 2004 1:58 AM
> To: Ian Grigg
> Cc: [EMAIL PROTECTED]
> Subject: Re: Financial identity is *dangerous*? (was re: Fake 
> companies,
> real money)
> 
> 
> 
> 
> Ian Grigg wrote:
> 
> > James A. Donald wrote:
> >
> >>> we already have the answer, and have had it for a decade: 
> store it 
> >>> on a trusted machine. Just say no to Windows XP. It's easy, 
> >>> especially when he's storing a bearer bond worth a car.
> >>
> >>
> >>
> >> What machine, attached to a network, using a web browser, 
> and sending 
> >> and receiving mail, would you trust? 
> >
> >
> >
> > None. But a machine that had one purpose in life:
> > to manage the bearer bond, that could be trusted
> > to a reasonable degree. The trick is to stop
> > thinking of the machine as a general purpose
> > computer and think of it as a platform for one
> > single application. Then secure that machine/OS/
> > stack/application combination.
> >
> > Oh, and make it small enough to fit in the pocket,
> > put a display *and* a keypad on it, and tell the
> > user not to lose it.
> >
> > iang
> 
> How much difference is there, practically, between this and using a 
> smartcard credit card in an external reader with a keypad? Aside from 
> the weight of the 'computer' in your pocket...
> 
> That would seem to me a more realistic expectation on 
> consumers who are 
> going to have, before too long, credit cards that fit that 
> description 
> and quite possibly the readers to go with them.
> 
> Aaron

If we're going to insist on dedicated, trusted, physical 
devices for these bearer bonds, then how is this different
than what Chaum proposed over 15 years ago? 

If you just add a requirment for face to face transactions,
then I already have one of these - its called a wallet
containing cash.

Peter

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

How thorough are the hash breaks, anyway?

[Trei, Peter]

[Disclaimer: I've never claimed to be a mathematician, nor even a
cryptographer:my business card says 'cryptoengineer'. I've always 
tried more to understand how to  properly use cryptographic 
primitives than to understand the deep theory of their construction. 
I go to people who know the theory when I have a question, 
and they come to me when they need something designed and 
built correctly and well.]

Looking over the recent work on hash collisions, one
thing that struck me was that they all seem to be 
attacks on known plaintext - the 'plaintexts' which
collided were very close to each other,  varying in 
only a few bits. 

While any weakness is a concern, and I'm not
going to use any of the compromised algorithms
in new systems, this type of break seems to be
of limited utility. 

It allows you (if you're fortunate) to modify a signed
message and have the signature still check out. 
However, if you don't know the original plaintext
it does not seem to allow you construct a second
message with the same hash.

There are many applications where a hash may
be exposed, but the attacker does not have access
to the original plaintext. One example is password
systems, where only the hash of the pw is stored.

Thus, the breaks seem to be of utility in some 
applications, but others remain (for the moment)
secure.

Am I missing something here?

Peter Trei


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

DES: Now 'really most sincerely dead'

[Trei, Peter]

Back in late 1996, I wrote to Jim Bidzos, proposing an RSA
Challenge to break single DES by brute force computation. 

Later in 1997, the first DES Challenge was successfully
completed.

Its taken another 7 years, but NIST has finally pulled 
single DES as a supported mode. 

Favorite line: "DES is now vulnerable to key exhaustion 
using massive, parallel computations."

Triple DES is still a supported mode, as it
should be.

So, if a product claims to use DES for
protection, you can now officially diss 
them for it.

Peter Trei
--

http://edocket.access.gpo.gov/2004/04-16894.htm

[Federal Register: July 26, 2004 (Volume 69, Number 142)]
[Notices]   
[Page 44509-44510]
>From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr26jy04-31] 

---

DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

[Docket No. 040602169-4169-01]

 
Announcing Proposed Withdrawal of Federal Information Processing 
Standard (FIPS) for the Data Encryption Standard (DES) and Request for 
Comments

AGENCY: National Institute of Standards and Technology (NIST), 
Commerce.

ACTION: Notice; request for comments.

---

SUMMARY: The Data Encryption Standard (DES), currently specified in 
Federal Information Processing Standard (FIPS) 46-3, was evaluated 
pursuant to its scheduled review. At the conclusion of this review, 
NIST determined that the strength of the DES algorithm is no longer 
sufficient to adequately protect Federal government information. As a 
result, NIST proposes to withdraw FIPS 46-3, and the associated FIPS 74 
and FIPS 81.
Future use of DES by Federal agencies is to be permitted only as a 
component function of the Triple Data Encryption Algorithm (TDEA). TDEA 
may be used for the protection of Federal information; however, NIST 
encourages agencies to implement the faster and stronger algorithm 
specified by FIPS 197, Advanced Encryption Standard (AES) instead. NIST 
proposes issuing TDEA implementation guidance as a NIST Recommendation 
via its ``Special Publication'' series (rather than as a FIPS) as 
Special Publication 800-67, Recommendation for Implementation of the 
Triple Data Encryption Algorithm (TDEA).

DATES: Comments on the proposed withdrawal of DES must be received on 
or before September 9, 2004.

ADDRESSES: Official comments on the proposed withdrawal of DES may 
either be sent electronically to  [EMAIL PROTECTED]  or by regular 
mail to: Chief, Computer Security Division, Information Technology 
Laboratory, ATTN: Comments on Proposed Withdrawal of DES, 100 Bureau 
Drive, Stop 8930, National Institute of Standards and Technology, 
Gaithersburg, MD 20899-8930.

FOR FURTHER INFORMATION CONTACT: Mr. William Barker (301) 975-8443, 
[EMAIL PROTECTED], National Institute of Standards and Technology, 100 
Bureau Drive, STOP 8930, Gaithersburg, MD 20899-8930.

SUPPLEMENTARY INFORMATION: In 1977, the Federal government determined 
that, while the DES algorithm was adequate to protect against any 
practical attack for the anticipated 15-year life of the standard, DES 
would be reviewed for adequacy every five years. DES is now vulnerable 
to key exhaustion using massive, parallel computations.
The current Data Encryption Standard (FIPS 46-3) still permits the 
use of DES to protect Federal government information. Since the 
strength of the original DES algorithm is no longer sufficient to 
adequately protect Federal government information, it is necessary to 
withdraw the standard.
In addition, NIST proposes the simultaneous withdrawal of FIPS 74, 
Guidelines for Implementing and Using the NBS Data Encryption Standard 
and FIPS 81, DES Modes of Operation. FIPS 74 is an implementation 
guideline specific to the DES. An updated NIST Special Publication 800-
21, Guideline for Implementing Cryptography in the Federal Government, 
will provide generic implementation and use guidance for NIST-approved 
block cipher algorithms (e.g., TDEA and AES). Because it is DES-
specific, and DES is being withdrawn, the simultaneous withdrawal of 
FIPS 74 is proposed.
FIPS 81 defines four modes of operation for the DES that have been 
used in a wide variety of applications. The modes specify how data is 
to be encrypted (cryptographically protected)

[[Page 44510]]

and decrypted (returned to original form) using DES. The modes included 
in FIPS 81 are the Electronic Codebook (ECB) mode, the Cipher Block 
Chaining (CBC) mode, the Cipher Feedback (CFB) mode, and the Output 
Feedback (OFB) mode. NIST Special Publication 800-38A, Recommendation 
for Block Cipher Modes of Operation, specifies modes of operation for 
generic block ciphers. Together with an upcoming message authentication 
code recommendation, SP 800-38B, SP 800-38A is a functional replacement 
for FI

EZ Pass followup.

[Trei, Peter]

This may be of interest to the folks discussing EZ pass.

On ne.transportation, there is a thread regarding
the subject, titled:

Surveillance Equipment on I-95?

The most interesting post follows.

Peter Trei


From: [EMAIL PROTECTED]

"John F. Carr" wrote:


> In article  <[EMAIL PROTECTED]> ,
> Michael Moroney  <[EMAIL PROTECTED]>  wrote:

> >I noticed several unusual sensors on I-84 SB in Connecticut, just 
before
> >and at a weigh station that's just north (IIRC) of Exit 71  These 
are
> >overhead on a gantry, and some look like the old-style (large) 
security
> >camera without a lens.  I figure they are somehow related to 
catching
> >trucks bypassing the weigh station but how exactly do they work?

>
> I assumed they were part of the weigh-once scheme that is spreading
> around the country.  A truck having been confirmed to be legal in one
> state may bypass other weigh stations in that state or a cooperating
> state.  Before the weigh station a transponder is interrogated and the
> truck is not required to stop if the computers like it.
>
> Sometimes there are signs saying "follow signal in cab" or something
> like that.


It is part of the weigh station bypass system.      If
the truck has a participating transponder, it can usually skip the weigh
station if everything is in order.  The transponder will display a green
light to bypass, a red means a trip to the weigh station.  The light stays on
for a few minutes so that compliance can be checked, if needed.  Some
stations have weigh-in-motion equipment to verify that the weight

There are two major weigh station bypass programs in North America: PrePass
and NorPass.  You can see what states they are used here:
   Connecticut's weigh station(s) have been
compatible with NorPass for several years and they just joined NorPass as a
full member a few weeks ago.

NorPass doesn't have any fees once you buy your transponder.  (PrePass
charges for each bypass with a daily maximum).  All systems use a compatible
transponder, and it is possible to buy a transponder that also speaks the IAG
protocol so it can be used at E-ZPass locations for tolls (after the
transponder is registered with E-ZPass).


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

RE: Security clampdown on the home PC banknote forgers

[Trei, Peter]

[EMAIL PROTECTED] wrote:

> 
> It's time to start wearing t-shirts bearing the image of a 
> banned banknote.
> (To circumvent counterfeiting laws, wear the banknote of a 
> foreign country).
> Imagine the frustration of the police when they can't 
> photocopy your picture.
> 

>From the original article:

  "The software relies on features built into leading 
  currencies. Latest banknotes contain a pattern of 
  five tiny circles. On the £20 note, they're disguised 
  as a musical notation, on the euro they appear in a 
  constellation of stars; on the new $20 note, the 
  pattern is hidden in the zeros of a background 
  pattern. Imaging software or devices detect the 
  pattern and refuse to deal with the image."

It would be interesting to figure out exactly what the
'don't copy' information is. If it's really just five
little circles, think of the fun you could have -

- create a rubber stamp with the appropriate image, and
stamp all kinds of documents.

- sell a line of printer paper which can't be copied or
scanned.

- make web pages which can't be printed.

- draw or tattoo it on your forehead, and suddenly 
no photo of you can be printed (or perhaps, even 
taken!).

ahh - the law of unintended consequences.

Peter Trei




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

RE: Satellite eavesdropping of 802.11b traffic

[Trei, Peter]

R. A. Hettinga

> At 12:35 PM -0400 5/27/04, John Kelsey wrote:
> >Does anyone know whether the low-power nature of wireless 
> LANs protects
> >them from eavesdropping by satellite?
> 
> It seems to me that you'd need a pretty big dish in orbit to 
> get that kind
> of resolution.
> 
> The Keyholes(?) are for microwaves, right?
> 
> Cheers,
> RAH

I don't claim great expertise, but

802.11b/g operates in the microwave range - My home
net falls over every time my kid heats up a
burrito (It comes right back, though).

GSM phones run at a MAX of 0.25 watts (GSM900) or 
0.125 watts (GSM1800), but it is normal for the 
power used to be one hundredth of this maximum 
or less.

However, the base stations are much more powerful - 
50 watts. I suspect the spy-from-orbit stuff looks 
at this, not the phone transmitter. 802.11b/g 
typically runs around 0.1 watt, and there is no 
high-power base station.

If this is the case, then the power in an 802.11b/g
net is 1/500th of that for GSM phones - which seems
to fit in with the difference in range. Phones 
operate with kilometers to the base station, while
802.11b/g is lucky to cover a whole house.

A big antenna would obviously be a lot of help, but a
smaller one a lot closer would be better. If you insist
on listening from orbit, geosync is probably not the way
to go - you'd want something like the Iridium constellation
of low-orbit sats (600 miles up).

Clarke orbit (geosync) is about 35800 km up. You'd get
a 10,000 fold advantage by putting your spysats at only
358km. 

I suspect that eavesdropping on 802.11b/g from 
orbit is pretty hard. The power levels are very 
low, and there may be several nets running on the same 
channel within a satellites' antenna footprint. 
My summary: Very tough. Probably not impossible.

Peter

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

RE: EU seeks quantum cryptography response to Echelon

[Trei, Peter]

Tom Shaddack wrote:

> On Tue, 18 May 2004, Tyler Durden wrote:
> 
> > "Monyk believes there will be a global market of several 
> million users once
> > a workable solution has been developed. A political 
> decision will have to
> > be taken as to who those users will be in order to prevent 
> terrorists and
> > criminals from taking advantage of the completely secure 
> communication
> > network, he said."
> 
> Hope the technology hits the streets fast enough after getting on the
> market. Monyk apparently doesn't believe that people who 
> don't have the
> money to buy the Official Approval have no right to access to this
> technology.

Actually, I read this as the sort of puffery we more often see
from the snake-oil vendors; "Our proprietary Auto Generated
One Time Pad (TM) crypto is s strong that the government
may ban it - get it while you can!"

Peter

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

RE: voting

[Trei, Peter]

> Ed Gerck[SMTP:[EMAIL PROTECTED]
> 
> John Kelsey wrote:
> > 
> > At 11:05 AM 4/9/04 -0400, Trei, Peter wrote:
> > 
> > >1. The use of receipts which a voter takes from the voting place to
> 'verify'
> > >that their vote was correctly included in the total opens the way for
> voter
> > >coercion.
> > 
> > I think the VoteHere scheme and David Chaum's scheme both claim to solve
> > this problem.  The voting machine gives you a receipt that convinces you
> > (based on other information you get) that your vote was counted as cast,
> > but which doesn't leak any information at all about who you voted for to
> > anyone else.  Anyone can take that receipt, and prove to themselves that
> > your vote was counted (if it was) or was not counted (if it wasn't). 
> 
> The flaw in *both* cases is that it reduces the level of privacy
> protection
> currently provided by paper ballots.
> 
> Currently, voter privacy is absolute in the US and does not depend
> even on the will of the courts. For example,  there is no way for a
> judge to assure that a voter under oath is telling the truth about how
> they voted, or not. This effectively protects the secrecy of the ballot
> and prevents coercion and intimidation in all cases.
> 
> 
I'd pretty much dropped this topic after it became clear that Mr. Leichter's
only response to the problems that people pointed out in VoteHere's
scheme (in particular, its vulnerability to vote coercion, and lack of
recountability) was to attempt to redefine them as non-problems. 
However, since the topic has arisen again.

Ed's got a very good point. I always prefer security which relies for
its integrity on the laws of nature, rather than on people behaving
with integrity.

Peter Trei






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

RE: voting

[Trei, Peter]

"privacy" wrote:
[good points about weaknesses in adversarial system deleted]

> It's baffling that security experts today are clinging to the outmoded
> and insecure paper voting systems of the past, where evidence of fraud,
> error and incompetence is overwhelming.  Cryptographic voting protocols
> have been in development for 20 years, and there are dozens of proposals
> in the literature with various characteristics in terms of scalability,
> security and privacy.  The votehere.net scheme uses advanced cryptographic
> techniques including zero knowledge proofs and verifiable remixing,
> the same method that might be used in next generation anonymous remailers.
> 
Our anonymous corrospondent has not addressed the issues I raised in my 
initial post on the 7th:

1. The use of receipts which a voter takes from the voting place to 'verify'
that
their vote was correctly included in the total opens the way for voter
coercion.

2. The proposed fix - a blizzard of decoy receipts - makes recounts based
on the receipts impossible.

> Given that so many jurisdictions are moving towards electronic voting
> machines, this is a perfect opportunity to introduce mathematical
> protections instead of relying so heavily on human beings.  I would
> encourage observers on these lists to familiarize themselves with the
> cryptographic literature and the heavily technical protocol details
> at http://www.votehere.com/documents.html before passing judgement on
> these technologies.
> 
Asking the readers of this list to 'familiarize themselves with the
cryptographic
literature', is, in many cases,  a little like telling Tiger Woods that he 
needs to familiarize himself with the rules of golf. We know the 'advanced 
cryptographic techniques' you refer to. We also know what their limitations
- 
what they can and cannot do. This is not the appropriate forum to try to say

"trust me".

Answer this:

1. How does this system prevent voter coercion, while still allowing receipt
based recounts? Or do you have some mechanism by which I can
personally verify every vote which went into the total, to make sure they
are correct?

2. On what basis do you think the average voter should trust this system,
seeing as it's based on mechanisms he or she cant personally verify?

3. What chain of events do I have to beleive to trust that the code which
is running in the machine is actually and correctly derived from the 
source code I've audited? I refer you to Ken Thompsons classic paper 
"Reflections on trusting trust", as well as the recent Diebold debacle
with uncertified patches being loaded into the machine at the 
last moment.

This last is an important point - there is no way you can eliminate the
requirement of election officials to behave legitimately. Since that
requirement can't be done away with by technology, adding technology
only adds more places the system can be compromised.

Based on the tone of this letter, I'd hazard a guess that 'privacy' has a
vested interest in VoteHere. If this true, it's a little odd that they are
willing to expose their source code, but not their name. We don't
bite, unless the victim deserves it :-) Opening your source is an
admirable first step - why not step out of the shadows so we can
help you make your system better?

I fear a system which does not have a backup mechanism that the
average voter can understand. While it's true that non-electronic
systems are subject to compromise, so are electronic ones, 
regardless of their use of ZK proofs, or 'advanced cryptographic
techniques".

I do think electronic voting machines are coming, and a good
thing. But they should be promoted on the basis that they 
are easier to use, and fairer in presentation, then are manual
methods. Promoting them on the basis that they are more
secure, and less subject to vote tampering is simply false.

Peter Trei
Cryptoengineer
RSA Security

Disclaimer: The above represents my personal opinions only.






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

RE: voting

[Trei, Peter]

> Perry E. Metzger wrote:
> 
> 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]
> 
I think Perry has hit it on the head, with the one exception that
the voter should never have the receipt in his hand - that opens
the way for serial voting fraud.

The receipt should be exposed to the voter behind glass, and
when he/she presses the 'accept' button, it visibly drops into 
the sealed, opaque ballot box.

Peter

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

RE: Firm invites experts to punch holes in ballot software

[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]

RE: Firm invites experts to punch holes in ballot software

[Trei, Peter]

Major Variola (ret) wrote:

>Peter, what would be wrong with having a machine in the booth that
>prints
>any valid receipt BUT is not connected to the voting system.  "To vote
>use the red machine; if you're being coerced you can use the blue
>machine
>to print as many receipts as intimidators."

>A trade off between (mild) user complexity and the desire for receipts
>(without coercion).

The system described allows the user to take a reciept (which has
only numbers on it) and use a website to determine that the vote
was recorded correctly.

A decoy receipt would also have to pass this test.

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

* Both real and decoy receipts would have to be in the database
for verification - which bothers me a lot.

* There seems to be no provision for recounts - what are they 
supposed to do - have everybody send in their receipts? How can you
tell the decoys from the real?

I give VoteHere kudos for releasing their source, but it doesnt
solve the e-voting problem.

Peter Trei

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

RE: Firm invites experts to punch holes in ballot software

[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: Code breakers crack GSM cellphone encryption

[Trei, Peter]

> David Honig[SMTP:[EMAIL PROTECTED] wrote:
> 
> At 02:37 AM 9/9/03 +1000, Greg Rose wrote:
> >At 05:18 PM 9/7/2003 -0700, David Honig wrote:
> >>"Laughing my ass off."  Since when do governments care about patents?
> >>How would this help/harm them from exploiting it?   Not that
> >>high-end LEOs haven't already had this capacity ---Biham et al
> >>are only the first *open* researchers to reveal this.
> >
> >Actually, patenting the method isn't nearly as silly as it sounds.
> Produced 
> >in quantity, a device to break GSM using this attack is not going to cost
> 
> >much more than a cellphone (without subsidies). Patenting the attack 
> >prevents the production of the "radio shack (tm) gsm scanner", so that it
> 
> >at least requires serious attackers, not idle retirees or jealous
> teenagers.
> 
Why the heck would a government agency have to break the GSM encryption
at all? The encryption is only on the airlink, and all GSM calls travel
through 
the POTS land line system in the clear, where they are subject to 
warranted wiretaps.

Breaking GSM is only of useful if you have no access to the landline
portion of the system.

Peter Trei



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

RE: U.S. seeks OSCE pact on biometric passports

[Trei, Peter]

> Duncan Frissell[SMTP:[EMAIL PROTECTED] writes:
> 
> Anyone have any pointers to non destructive methods of rendering Smart
> Chips unreadable?  Just curious.
> 
> 
> On Mon, 1 Sep 2003, R. A. Hettinga wrote:
> 
> >
>  r>
> >
> > The Washington Times
> > www.washingtontimes.com
> >
> > U.S. seeks OSCE pact on biometric passports
> > By Nicholas Kralev
> > Published September 1, 2003
[snip]

Non-destructive, yet unreadable? Seems an odd
requirement. I suppose a dab of clear nail polish on
the contacts might work. 

Peter Trei


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