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

2007-10-25 Thread 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:

   http://www.elcomsoft.com/EDPR/gpu_en.pdf

  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

2007-06-21 Thread 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?

2007-05-22 Thread 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?

2007-05-19 Thread 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


  shrugs  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

2007-02-27 Thread 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]


FW: Entropy of other languages

2007-02-07 Thread 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: Entropy of other languages

2007-02-07 Thread 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]


RE: SSL Cert Prices Notes

2006-08-11 Thread 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: thoughts on one time pads

2006-01-28 Thread 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

2006-01-17 Thread 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....

2005-08-25 Thread 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

2005-05-20 Thread 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

2005-03-03 Thread 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 still secure.

It is easy to 

RSA Conference, and BA Cypherpunks

2005-02-07 Thread 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

2005-02-02 Thread 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

2005-01-04 Thread 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

2004-11-30 Thread 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)

2004-11-01 Thread 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)

2004-10-25 Thread 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]


DES: Now 'really most sincerely dead'

2004-07-28 Thread 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 FIPS 

RE: Satellite eavesdropping of 802.11b traffic

2004-05-28 Thread 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

2004-05-25 Thread 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

2004-04-16 Thread 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

2004-04-09 Thread 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: 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 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: Code breakers crack GSM cellphone encryption

2003-09-08 Thread 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

2003-09-03 Thread 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:
 
 
 http://dynamic.washtimes.com/print_story.cfm?StoryID=20030901-124025-4029
 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]