From rah at shipwright.com  Fri Oct  1 09:50:06 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 1 Oct 2004 09:50:06 -0400
Subject: Tor 0.0.9pre1 is out (fwd from arma@mit.edu)
Message-ID: <p06110471bd8310f7341c@[66.149.49.5]>


--- begin forwarded text


Date: Fri, 1 Oct 2004 10:46:39 +0200
From: Eugen Leitl <eugen at leitl.org>
To: cypherpunks at al-qaeda.net
Subject: Tor 0.0.9pre1 is out (fwd from arma at mit.edu)
User-Agent: Mutt/1.4i
Sender: owner-cypherpunks at al-qaeda.net

From: Roger Dingledine <arma at mit.edu>
Subject: Tor 0.0.9pre1 is out
To: or-dev at freehaven.net
Date: Fri, 1 Oct 2004 03:19:44 -0400
Reply-To: or-dev at freehaven.net

We've fixed quite a few bugs. We've also added compression for
directories, and client-side directory caching on disk so you'll have
a directory when Tor restarts.

tarball:   http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz
signature: http://freehaven.net/tor/dist/tor-0.0.9pre1.tar.gz.asc
(use -dPr tor-0_0_9pre1 if you want to check out from cvs)

Changes from 0.0.8:
  o Bugfixes:
    - Stop using separate defaults for no-config-file and
      empty-config-file. Now you have to explicitly turn off SocksPort,
      if you don't want it open.
    - Fix a bug in OutboundBindAddress so it (hopefully) works.
    - Improve man page to mention more of the 0.0.8 features.
    - Fix a rare seg fault for people running hidden services on
      intermittent connections.
    - Change our file IO stuff (especially wrt OpenSSL) so win32 is
      happier.
    - Fix more dns related bugs: send back resolve_failed and end cells
      more reliably when the resolve fails, rather than closing the
      circuit and then trying to send the cell. Also attach dummy resolve
      connections to a circuit *before* calling dns_resolve(), to fix
      a bug where cached answers would never be sent in RESOLVED cells.
    - When we run out of disk space, or other log writing error, don't
      crash. Just stop logging to that log and continue.
    - We were starting to daemonize before we opened our logs, so if
      there were any problems opening logs, we would complain to stderr,
      which wouldn't work, and then mysteriously exit.
    - Fix a rare bug where sometimes a verified OR would connect to us
      before he'd uploaded his descriptor, which would cause us to
      assign conn->nickname as though he's unverified. Now we look through
      the fingerprint list to see if he's there.
    - Fix a rare assert trigger, where routerinfos for entries in
      our cpath would expire while we're building the path.

  o Features:
    - Clients can ask dirservers for /dir.z to get a compressed version
      of the directory. Only works for servers running 0.0.9, of course.
    - Make clients cache directories and use them to seed their router
      lists at startup. This means clients have a datadir again.
    - Configuration infrastructure support for warning on obsolete
      options.
    - Respond to content-encoding headers by trying to uncompress as
      appropriate.
    - Reply with a deflated directory when a client asks for "dir.z".
      We could use allow-encodings instead, but allow-encodings isn't
      specified in HTTP 1.0.
    - Raise the max dns workers from 50 to 100.
    - Discourage people from setting their dirfetchpostperiod more often
      than once per minute
    - Protect dirservers from overzealous descriptor uploading -- wait
      10 seconds after directory gets dirty, before regenerating.

----------

--
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net

[demime 1.01d removed an attachment of type application/pgp-signature]

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Fri Oct  1 14:55:46 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Fri, 1 Oct 2004 14:55:46 -0400
Subject: 'Frustrated' U.S. Cybersecurity Chief Abruptly Resigns
Message-ID: <p061104a8bd835883f962@[66.149.49.5]>

<http://www.local6.com/print/3776699/detail.html?use=print>

local6.com

'Frustrated' U.S. Cybersecurity Chief Abruptly Resigns

POSTED: 11:32 AM EDT October 1, 2004
WASHINGTON -- The government's cybersecurity chief has abruptly resigned
after one year with the Department of Homeland Security, confiding to
industry colleagues his frustration over what he considers a lack of
attention paid to computer security issues within the agency.

 Amit Yoran, a former software executive from Symantec Corp., informed the
White House about his plans to quit as director of the National Cyber
Security Division and made his resignation effective at the end of
Thursday, effectively giving a single's day notice of his intentions to
leave.

 Yoran said Friday he "felt the timing was right to pursue other
opportunities." It was unclear immediately who might succeed him even
temporarily. Yoran's deputy is Donald "Andy" Purdy, a former senior adviser
to the White House on cybersecurity issues.

 Yoran has privately described frustrations in recent months to colleagues
in the technology industry, according to lobbyists who recounted these
conversations on condition they not be identified because the talks were
personal.

 As cybersecurity chief, Yoran and his division - with an $80 million
budget and 60 employees - were responsible for carrying out dozens of
recommendations in the Bush administration's "National Strategy to Secure
Cyberspace," a set of proposals to better protect computer networks.

 Yoran's position as a director -- at least three steps beneath Homeland
Security Secretary Tom Ridge -- has irritated the technology industry and
even some lawmakers. They have pressed unsuccessfully in recent months to
elevate Yoran's role to that of an assistant secretary, which could mean
broader authority and more money for cybersecurity issues.

 "Amit's decision to step down is unfortunate and certainly will set back
efforts until more leadership is demonstrated by the Department of Homeland
Security to solve this problem," said Paul Kurtz, a former cybersecurity
official on the White House National Security Council and now head of the
Washington-based Cyber Security Industry Alliance, a trade group.

 Under Yoran, Homeland Security established an ambitious new cyber alert
system, which sends urgent e-mails to subscribers about major virus
outbreaks and other Internet attacks as they occur, along with detailed
instructions to help computer users protect themselves.

 It also mapped the government's universe of connected electronic devices,
the first step toward scanning them systematically for weaknesses that
could be exploited by hackers or foreign governments. And it began
routinely identifying U.S. computers and networks that were victims of
break-ins.

 Yoran effectively replaced a position once held by Richard Clarke, a
special adviser to President Bush, and Howard Schmidt, who succeeded Clarke
but left government during the formation of the Department of Homeland
Security to work as chief security officer at eBay Inc.

 Yoran cofounded Riptech Inc. of Alexandria, Va., in March 1998, which
monitored government and corporate computers around the world with an
elaborate sensor network to protect against attacks. He sold the firm in
July 2002 to Symantec for $145 million and stayed on as vice president for
managed security services.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sat Oct  2 18:06:26 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sat, 2 Oct 2004 18:06:26 -0400
Subject: Reverse DMCA: Copyright Holder Held Liable in Landmark Legal
 Ruling
Message-ID: <p061104abbd844e8ba45e@[66.149.49.5]>

<http://www.linuxelectrons.com/article.php/20040930201813382>   
LinuxElectrons? -


Reverse DMCA: Copyright Holder Held Liable in Landmark Legal Ruling
  
 Thursday, September 30 2004 @ 08:18 PM
 Contributed by: ByteEnable


In a landmark case, a California district court has determined that
Diebold, Inc., a manufacturer of electronic voting machines, knowingly
misrepresented that online commentators, including IndyMedia and two
Swarthmore college students, had infringed the company's copyrights. This
makes the company the first to be held liable for violating section 512(f)
of the Digital Millennium Copyright Act (DMCA), which makes it unlawful to
use DMCA takedown threats when the copyright holder knows that infringement
has not actually occured.

The Electronic Frontier Foundation (EFF) and the Center for Internet and
Society Cyberlaw Clinic at Stanford Law School sued on behalf of nonprofit
Internet Service Provider (ISP) Online Policy Group (OPG) and the two
students to prevent Diebold's abusive copyright claims from silencing
public debate about voting.

Diebold sent dozens of cease-and-desist letters to ISPs hosting leaked
internal documents revealing flaws in Diebold's e-voting machines. The
company claimed copyright violations and used the DMCA to demand that the
documents be taken down. One ISP, OPG, refused to remove them in the name
of free speech, and thus became the first ISP to test whether it would be
held liable for the actions of its users in such a situation.

"This decision is a victory for free speech and for transparency in
discussions of electronic voting technology," said Wendy Seltzer, an EFF
staff attorney who worked on the case. "Judge Fogel recognized the fair use
of copyrighted materials in critical discussion and gave speakers a remedy
when their speech is chilled by improper claims of copyright infringement."

OPG Executive Director Will Doherty said, "This ruling means that we have
legal recourse to protect ourselves and our clients when we are sent
misleading or abusive takedown notices."

In his decision, Judge Jeremy Fogel wrote, "No reasonable copyright holder
could have believed that the portions of the email archive discussing
possible technical problems with Diebold's voting machines were proteced by
copyright . . . the Court concludes as a matter of law that Diebold
knowingly materially misrepresented that Plaintiffs infringed Diebold's
copyright interest."


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rsalz at datapower.com  Sun Oct  3 22:22:32 2004
From: rsalz at datapower.com (Rich Salz)
Date: Sun, 3 Oct 2004 22:22:32 -0400 (EDT)
Subject: NIST on TLS
Message-ID: <Pine.LNX.4.44L0.0410032221200.4820-100000@smtp.datapower.com>

Found via the RSS feed for cryptome.org:

http://csrc.nist.gov/publications/drafts.html#sp800-52
NIST is pleased to announce the first public draft of Special Publication
800-52, Guidelines on the Selection and Use of Transport Layer Security.
This document is a guideline for implementing Transport Layer Security in
the Federal Government to protect sensitive information. Care must be
taken when selecting cryptographic mechanisms for authentication,
confidentiality, and message integrity, as some choices are non-compliant
with Government standards, or may pose security risks. The comment period
for this document will be 30 days, ending on November 1st, 2004.
Please direct all comments and questions to Matthew J. Fanto at
matthew.fanto at nist.gov.


--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Sun Oct  3 15:14:30 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Sun, 3 Oct 2004 15:14:30 -0400
Subject: A Proposed Nomenclature for the Four Horseman of The Infocalypse
Message-ID: <p06110433bd85f5dcdd81@[66.149.49.5]>

I've been talking about this for the last decade, and never found a
reference on the web whenever I was thinking about it. Thanks to
Google, it was well within my prodigiously diminished attention span
this morning.

Given the events on the net over the past few years, I figure we
might as well have fun with the idea. Humor is good leverage, and
these days we need *lots* of leverage.

In arbitrary order (in other words, *I* chose it. :-)), and with
apologies to Toru Iwatani, by way of Michael Thomasson at
<http://www.gooddealgames.com/articles/Pac-Man%20Ghosts.html>, here
it is:


A Proposed Nomenclature for the Four Horseman of The Infocalypse

   Horseman             Color      Character   Nickname

1  Terrorism            Red        Shadow      "Blinky"
2  Narcotics            Pink       Speedy      "Pinky"
3  Money Laundering     Aqua       Bashful     "Inky"
4  Paedophilia          Yellow     Pokey       "Clyde"

It is acceptable to refer to a horseman by any of the above, i.e.,
"Horseman No. 1", "The Red Horseman", "Shadow", or "Blinky".

Apparently there was a, um, pre-deceased, dark-blue ghost, used in
Japanese tournament play, named "Kinky", I leave that particular
horseman for quibblers.


Cheers,
RAH


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hughejp at mac.com  Mon Oct  4 21:07:15 2004
From: hughejp at mac.com (james hughes)
Date: Mon, 4 Oct 2004 21:07:15 -0400
Subject: IBM's original S-Boxes for DES?
In-Reply-To: <20040930162520.16E341AE84@berkshire.research.att.com>
References: <20040930162520.16E341AE84@berkshire.research.att.com>
Message-ID: <E58DB40A-166A-11D9-8503-000A95A27482@mac.com>

In a personal interview with Walt Tuchman (IBM at the time, worked for 
StorageTek when I met him, now retired) he described the process for 
creating the s-boxes. A set of mathematical requirements were created 
and candidate s-boxes meeting these requirements would be printed out 
on a regular basis. The process ran over a weekend on a 360/195 and the 
results were given to the ASIC developers to determine which would 
result in the smallest ASIC size. One was selected by them. I was told 
that after the requirements were set, NSA did not have a hand in 
selecting the final S-Boxes.

jim
http://www.stortek.com/hughes


On Sep 30, 2004, at 12:25 PM, Steven M. Bellovin wrote:

> In message <1096535230.415bccbe98ef6 at webmail1.ec.auckland.ac.nz>, 
> Nicolai Moles
> -Benfell writes:
>> Hi,
>>
>> A number of sources state that the NSA changed the S-Boxes (and 
>> reduced the ke
>> y
>> size) of IBM's original DES submission, and that these change were 
>> made to
>> strengthen the cipher against differential/linear/?? cryptanalysis.
>>
>> Does anybody have a reference to, or have an electronic copy of these 
>> original
>> S-Boxes?
>>
>
> It was only to protect against differential cryptanalysis; they did not
> know about linear cryptanalysis.  See Don Coppersmith, The Data 
> Encryption
> Standard (DES) and its strength against attacks, IBM Journal of 
> Research
> and Development, Vol. 38, n. 3, pp. 243-250, May 1994.
>
>
> 		--Steve Bellovin, http://www.research.att.com/~smb
>
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dahonig at cox.net  Mon Oct  4 23:28:15 2004
From: dahonig at cox.net (David Honig)
Date: Mon, 04 Oct 2004 20:28:15 -0700
Subject: Linux-based wireless mesh suite adds crypto engine support 
In-Reply-To: <200409302225.i8UMPv8P001170@new.toad.com>
References: <Message from pgut001@cs.auckland.ac.nz (Peter Gutmann)    of "Thu, 30 Sep 2004 17:05:15 +1200." <E1CCt7z-0005TQ-00@medusa01>
 <E1CCt7z-0005TQ-00@medusa01>
Message-ID: <3.0.5.32.20041004202815.008cd7c0@pop.west.cox.net>

At 03:25 PM 9/30/04 -0700, John Gilmore wrote:
>
>Crypto hardware that generates "random" numbers can't be tested in
>production in many useful ways.  My suggestion would be to XOR a
>hardware-generated and a software-generated random number stream.  If
>one fails, whether by accident, malice, or design, the other will
>still randomize the resulting stream.  Belt AND suspenders will keep
>your source of randomness from being your weakest link.

A good idea, but also: consider that hardware based RNGs are
not so hard to make.  An FM radio soundcard, audio digitizer, and
some homebrew (perhaps standard-crypto-hash-based) software
suffices for moderate bandwidth true RNG construction.  
Using an evaluation metric like Diehard and/or a Shannon or
Mauer entropy measure ices the cake (as well as being required
for initial and continuing monitoring).  (Insert the usual caveats
about PRNGs being undetectable, OS subversion, white vans driving
your FM hiss, etc.)  Very cheap and if you can master a hash
function component, not tricky.

Obviously too much trouble for Joe Sixpack, but I think that
certain online gambling houses (not US of course) have made
their own sources, and definately not too hard for anyone who codes
and has crypto-clue.  OTOH Joe can benefit from his radio-tuner
card plus off the shelf inspectable software since he ought not
to trust Bigcorp's embedded nominal RNG.  Joe Sixpack might also
be an abbreviation for a foreign government.  Should the Pakis
really trust Intel's RNG? 

PS: your belts and suspenders argument also applies to trusting
cipher algorithms.  Best to chain a few.  Also useful to twiddle
a few S-box bits, even if you get suboptimal properties, so as 
to deter cheap crackers using COTS cipher chips.  (Doing dictionary
regexp search, not the impractical exhaustive search, of course.)
This works particularly well in large random-S-box constructs like Blowfish
(et al) compared to the more spartan (thus degradable) DES S-boxes.

The weakest link will be bipedal for the forseeable future.










=================================================
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted.  Really.

------

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Tue Oct  5 09:37:11 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Tue, 5 Oct 2004 09:37:11 -0400 (GMT-04:00)
Subject: Linux-based wireless mesh suite adds crypto engine support
Message-ID: <21504735.1096983431432.JavaMail.root@gonzo.psp.pas.earthlink.net>

>From: John Gilmore <gnu at toad.com>
>Sent: Sep 30, 2004 6:25 PM
>To: cryptography at metzdowd.com, gnu at toad.com
>Subject: Re: Linux-based wireless mesh suite adds crypto engine support 

>Crypto hardware that does algorithms can be tested by periodically
>comparing its results to a software implementation.  Production
>applications should probably be doing this -- maybe 1% of the time.

I think the need for interoperability constrains the ability for a crypto module to implement some weak algorithm in place of AES or 3DES.  Unless the designer can know which encrypted messages have to be handled by someone else's non-hacked module, he can't safely do this.  

>Crypto hardware that generates "random" numbers can't be tested in
>production in many useful ways.  My suggestion would be to XOR a
>hardware-generated and a software-generated random number stream.  If
>one fails, whether by accident, malice, or design, the other will
>still randomize the resulting stream.  Belt AND suspenders will keep
>your source of randomness from being your weakest link.

I'll note that this is supported two separate ways in the (in progress) X9.82 standard.  

a.  A standard way to produce a random bit generator with a guaranteed fallback to computational security is to XOR  the outputs of some good hardware generator with the outputs of a crypto PRNG (aka DRBG in X9.82-ese).  

b.  Any approved random bit generator can always be combined with an unapproved generator by XORing.  The only security requirement here is that the unapproved generator be independent of the approved one.

All that said, though, it's far from clear how you monitor this in the standard crypto environment, since you usually take great pains to make it hard for anyone to get key material out of the tamper-resistant modules.  You provide the random value to XOR into the RNG output, and the module says "Thanks, I XORed it in.  Trust me."  Or, you demand the random value from its RNG, XOR in your own, but now, you've exposed the key outside the tamper-resistant module, which introduces a whole different set of problems.  I'm sure there are some clever crypto protocol ways to address this (basically, do a zero-knowledge proof of the value of the random number you used in deriving the key), but I have a hard time thinking this is at all practical....

>	John

--John Kelsey


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Oct  5 10:56:29 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 5 Oct 2004 10:56:29 -0400
Subject: National IDs for everybody?
Message-ID: <p06110411bd87a895c2f7@[66.149.49.5]>

<http://news.com.com/2102-1028_3-5395386.html?tag=st.util.print>

CNET News

 National IDs for everybody?

 By  Declan McCullagh
  http://news.com.com/National+IDs+for+everybody/2010-1028_3-5395386.html

 Story last modified October 4, 2004, 12:01 PM PDT


Rep. David Dreier wants to force all Americans to carry a national ID card
around with them.

The California Republican is not about to describe his new bill in those
terms, but that's the reality.

 Dreier's legislation would prohibit employers from hiring people unless
the job applicants first obtain new federal ID cards with their photograph,
Social Security number and an "encrypted electronic strip" with additional
information. Any employer who fails to comply faces hefty fines and prison
terms of up to five years.

 Dreier is smart enough to realize that these federal IDs would be
immediately forged, so he takes the next step of linking them to an
employment eligibility database that's queried by card readers whenever the
ID is swiped. The employment database is required to include "all such data
maintained by the Department of Homeland Security," combined with what the
Social Security Administration has on file.

 Most all bills die without the dignity of a floor vote. But Dreier is a
rising star in the Republican Party with the influence to enact legislation
quickly.

 As a chairman, he's one of the youngest to head the powerful House Rules
Committee, not to mention acting as co-chair of Californians for Bush and
chairman of Gov. Arnold Schwarzenegger's transition team. In 1998, his
conservative voting record garnered a perfect 100 percent rating from the
Christian Coalition--and a zero percent rating from the left-leaning
Americans for Democratic Action. Last week, Dreier appeared on MSNBC as a
Republican spokesman before the presidential debate.

 Any employer who fails to comply faces hefty fines and prison terms of up
to five years.
 The ostensible reason Dreier gives for a federal ID: curbing illegal
immigration, the subject of a recent Time magazine cover story. "The
explosion in counterfeit identity documents and employers who are unable or
unwilling to establish the authenticity of documents presented by job
applicants severely undermines our national security," Dreier said when
introducing his bill, which he calls the Illegal Immigrant Enforcement and
Social Security Protection Act.

 The real reasons are slightly more complicated.

 Tight re-election campaign
 Dreier is used to commanding handsome victories at the polls every two
years over his Democratic rivals. But since 1996, Dreier's re-election
percentages have dipped below 60 percent a few times, and events in the
last month slammed the powerful Republican with a series of embarrassing
pre-Election Day setbacks.

 First came allegations in the LA Weekly newspaper and the New York Post
that Dreier, who has amassed a slew of anti-gay votes, is homosexual. Then
two local talk show hosts, John Kobylt and Ken Chiampou of KFI-AM 640,
became fed up with Dreier's stand on immigration.

 They organized a "Fire Dreier" rally on Sep. 15 on charges that illegal
immigrants from Mexico have wreaked havoc on California's economy. Held
outside Dreier's Glendora, Calif., office, it drew hundreds of protesters
armed with signs and bullhorns who called for a "political human
sacrifice," according to the Pasadena Star-News.

 The real problem with Dreier's plan is not that it creates an ID card.
Driver's licenses do that today.
 Conservative publications continued the attack--a worrisome sign for a
Republican who won't deny wanting to be speaker of the House someday.
WorldNetDaily columnist Jane Chastain wrote an article on Sept. 16
endorsing the Fire Dreier scheme: "It will leave congressmen, who have done
little or nothing to help stem the tide of illegal immigrates, quaking in
their boots."

 The upshot? Just hours before the Fire Dreier protest, the embattled
congressman informed the Claremont Kiwanis Club that he would introduce his
national ID bill. Six days later, Dreier did just that.

 The real problem with Dreier's plan is not that it creates an ID card.
Driver's licenses do that today.

 But Dreier would create a back-end database for authentication purposes
that could track whenever the ID is swiped. Just as the Social Security
Number's uses grew, those readers would appear just about everywhere:
banks, office buildings, supermarkets. Such a database would overflow with
detailed records of all of our life's activities and create an irresistible
temptation for misuse by corrupt officials or electronic intruders.

 Dreier isn't alone. A Senate bill introduced last month in response to the
9/11 Commission's report would give the Department of Homeland Security
unfettered power to regulate state drivers' licenses and ID cards. The
House version takes a similar approach.

 Both measures say federal agencies will only accept licenses and ID cards
that comply--a requirement that would affect anyone who wants to get a U.S.
passport, obtain Social Security benefits, or even wander into a federal
courthouse. States would be strong-armed into complying. Warns Barry
Steinhardt of the American Civil Liberties Union: "Congress shouldn't be
providing a blank check to the Department of Homeland Security to design a
national driver's license."

 It's not just a liberal sentiment. Says Stephen Lilienthal, a policy
analyst at the conservative Free Congress Foundation: "Many conservatives
have expressed concern that proposals such as the Dreier bill are placed on
the books with a limited set of objectives but will expand bit by bit to
include all sorts of other information and be monitored constantly by the
government to keep track of individuals from cradle to grave."

 Dreier should take note. Talking loudly about ID cards may boost his
re-election bid next month, but voters won't be pleased when they've
figured out what it actually means.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From DaveHowe at gmx.co.uk  Tue Oct  5 12:32:07 2004
From: DaveHowe at gmx.co.uk (Dave Howe)
Date: Tue, 05 Oct 2004 17:32:07 +0100
Subject: IBM's original S-Boxes for DES?
In-Reply-To: <20040930162520.16E341AE84@berkshire.research.att.com>
References: <20040930162520.16E341AE84@berkshire.research.att.com>
Message-ID: <4162CC87.5030200@gmx.co.uk>

Steven M. Bellovin wrote:
> It was only to protect against differential cryptanalysis; they did not 
> know about linear cryptanalysis.  
   More accurately, they didn't protect against linear cryptanalysis - 
there is no way to know if they knew about it and either didn't want to 
make changes to protect against that (they weakened the key, so may have 
wished to keep *some* attacks viable against it to weaken it still 
further), had to choose (against *either* differential or linear, as 
they didn't know how to protect against both) or simply the people doing 
the eval on DES didn't know, as it was rated above their clearance level.
   We only have a single event to go from (that DES was indeed protected 
against one not the other) so can't really judge motivation or knowledge.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Oct  5 14:27:27 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Tue, 5 Oct 2004 14:27:27 -0400
Subject: Credentica Web site is up
Message-ID: <p061104eabd8897de6292@[66.149.49.5]>


--- begin forwarded text


From: "Stefan Brands" <brands at credentica.com>
To: <SelectedContacts at credentica.com>
Subject: Credentica Web site is up
Date: Tue, 5 Oct 2004 13:55:30 -0400

Dear All,

This e-mail is to inform you that our corporate Web site at
http://www.credentica.com is up. We welcome any suggestions for
improvement, and encourage you to establish links to our home-page from
your blogs, news postings, and Web sites!

Best regards,
Stefan Brands
Credentica
740 Notre Dame W, #1500
Montreal, QC
Canada H3C 3X6
Tel: +1 (514) 866.6000

PS Pages that may be of particular interest:

- http://www.credentica.com/about.php (overview of what we do and how we
differ)

- http://www.credentica.com/solutions.php & submenus (explanations of
product benefits in key markets)

- http://www.credentica.com/the_mit_pressbook.php (the entire MIT Press
book available for free download)

White papers and product data sheets are in preparation and will be
posted in the next couple of months.

PPS The site is best viewed with a Javascript-enabled browser, and has
been tested only with leading browsers.

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at cypherspace.org  Tue Oct  5 17:18:30 2004
From: adam at cypherspace.org (Adam Back)
Date: Tue, 5 Oct 2004 17:18:30 -0400
Subject: Brands credential book online (pdf)
Message-ID: <20041005211830.GA12402@bitchcake.off.net>

Stefan Brands book on his credential / ecash technology is now
downloadable in pdf format from credentica's web site:

        http://www.credentica.com/the_mit_pressbook.php

(previously it was only available in hardcopy, and only parts of the
content was described in academic papers).

Also the credentica web site has gone live, lots of content.

Credentica is Stefan's company around digital credentials ecash /
anonymity news watchers may have seen some discussion of the
credentica startup company earlier this year.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From gnu at toad.com  Tue Oct  5 22:07:59 2004
From: gnu at toad.com (John Gilmore)
Date: Tue, 05 Oct 2004 19:07:59 -0700
Subject: Interesting report on Dutch non-use of traffic data
Message-ID: <200410060207.i9627x8P001536@new.toad.com>

 From EDRI-gram via Wendy Seltzer:

============================================================
4. Dutch police report: traffic data seldom essential
============================================================

Telephone traffic data are only necessary to solve crimes in a minority of
police investigations. Most cases can be solved without access to traffic
data, with the exception of large fraud investigations.

These are the conclusions of a Dutch police report produced at the request
of the Dutch ministry of Justice. The report was recently obtained by the
Dutch civil liberties organisation Bits of Freedom through a public access
request.

The report undermines the Dutch government's support to the EU draft
framework decision on data retention. The report makes no case for the
proposed data retention as Dutch police already uses traffic data in 90%
of all investigations. The police can already obtain, with a warrant, the
traffic data that telecommunication companies store for their own billing-
and business purposes. The report also shows that the use of traffic data
is a standard tool in police investigations and it not limited to cases of
organised crime or terrorism.

The report is the result of an evaluation of past investigations by the
Dutch police of Rotterdam. Two-thirds of all investigations could have
been solved if no traffic data would have been available at all. The three
main purposes of traffic data in police investigations are: network
analysis (searching for associations of a person to other individuals),
tactical support for surveillance and checking of alibis (through GSM
location data).

Police investigators can compensate a possible lack of traffic data by
other investigative methods such as wiretapping, surveillance, a
preservation order for traffic data and a longer investigative period. The
report states that police officers seldom ask for traffic data older than
six months.

The report was never sent to the Dutch parliament although members of
parliament previously asked for research results about the effectiveness
of mandatory data retention. After Bits of Freedom published the report
new questions have been raised in the Dutch parliament about the reason
for withholding the report.

The use of (historic) traffic data in investigations (April 2003, in Dutch)
http://www.bof.nl/docs/rapport_verkeersgegevens.pdf

(Contribution by Maurice Wessling, EDRI-member Bits of Freedom)


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rabbi at abditum.com  Wed Oct  6 05:55:28 2004
From: rabbi at abditum.com (Len Sassaman)
Date: Wed, 6 Oct 2004 02:55:28 -0700 (PDT)
Subject: CodeCon 2005 Call for Papers
Message-ID: <Pine.LNX.4.58.0410060255140.9602@thetis.deor.org>

CodeCon 4.0
February 11-13, 2005
San Francisco CA, USA
www.codecon.org

Call For Papers

CodeCon is the premier showcase of cutting edge software development. It
is an excellent opportunity for programmers to demonstrate their work and
keep abreast of what's going on in their community.

All presentations must include working demonstrations, ideally accompanied
by source code. Presenters must be done by one of the active developers of
the code in question. We emphasize that demonstrations be of *working*
code.

We hereby solicit papers and demonstrations.

    * Papers and proposals due: December 15, 2005
    * Authors notified: January 1, 2005

Possible topics include, but are by no means restricted to:

    * community-based web sites - forums, weblogs, personals
    * development tools - languages, debuggers, version control
    * file sharing systems - swarming distribution, distributed search
    * security products - mail encryption, intrusion detection, firewalls

Presentations will be a 45 minutes long, with 15 minutes allocated for
Q&A. Overruns will be truncated.

Submission details:

Submissions are being accepted immediately. Acceptance dates are November
15, and December 15. After the first acceptance date, submissions will be
either accepted, rejected, or deferred to the second acceptance date.

The conference language is English.

Ideally, demonstrations should be usable by attendees with 802.11b
connected devices either via a web interface, or locally on Windows,
UNIX-like, or MacOS platforms. Cross-platform applications are most
desirable.

Our venue will be 21+.

To submit, send mail to submissions-2005 at codecon.org including the
following information:

    * Project name
    * url of project home page
    * tagline - one sentence or less summing up what the project does
    * names of presenter(s) and urls of their home pages, if they have any
    * one-paragraph bios of presenters, optional, under 100 words each
    * project history, under 150 words
    * what will be done in the project demo, under 200 words
    * slides to be shown during the presentation, if applicable
    * future plans

General Chairs: Jonathan Moore, Len Sassaman
Program Chair: Bram Cohen

Program Committee:

    * Jeremy Bornstein, AtomShockwave Corp., USA
    * Bram Cohen, BitTorrent, USA
    * Jered Floyd, Permabit, USA
    * Ian Goldberg, Zero-Knowledge Systems, CA
    * Dan Kaminsky, Avaya, USA
    * Klaus Kursawe, Katholieke Universiteit Leuven, BE
    * Ben Laurie, A.L. Digital Ltd., UK
    * David Molnar, University of California, Berkeley, USA
    * Jonathan Moore, Mosuki, USA
    * Len Sassaman, Nomen Abditum Services, USA

Sponsorship:

If your organization is interested in sponsoring CodeCon, we would love to
hear from you. In particular, we are looking for sponsors for social meals
and parties on any of the three days of the conference, as well as
sponsors of the conference as a whole and donors of door prizes. If you
might be interested in sponsoring any of these aspects, please contact the
conference organizers at codecon-admin at codecon.org.

Press policy:

CodeCon provides a limited number of passes to bona fide press.
Complimentary press passes will be evaluated on request. Everyone is
welcome to pay the low registration fee to attend without an official
press credential.

Questions:

If you have questions about CodeCon, or would like to contact the
organizers, please mail codecon-admin at codecon.org. Please note this
address is only for questions and administrative requests, and not for
workshop presentation submissions.







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ben at algroup.co.uk  Wed Oct  6 08:39:39 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Wed, 06 Oct 2004 13:39:39 +0100
Subject: Linux-based wireless mesh suite adds crypto engine support
In-Reply-To: <200409302225.i8UMPv8P001170@new.toad.com>
References: <E1CCt7z-0005TQ-00@medusa01> <200409302225.i8UMPv8P001170@new.toad.com>
Message-ID: <4163E78B.7050509@algroup.co.uk>

John Gilmore wrote:
> Crypto hardware that generates "random" numbers can't be tested in
> production in many useful ways.  My suggestion would be to XOR a
> hardware-generated and a software-generated random number stream.  If
> one fails, whether by accident, malice, or design, the other will
> still randomize the resulting stream.  Belt AND suspenders will keep
> your source of randomness from being your weakest link.

I think it'd sometimes be better to feed them both into a pool rather 
than xoring them, since they might go at radically different rates, and 
xor would limit you to the slower of the two. Of course, for some threat 
models that would be the right thing.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Wed Oct  6 09:23:46 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Wed, 6 Oct 2004 09:23:46 -0400 (GMT-04:00)
Subject: IBM's original S-Boxes for DES?
Message-ID: <14504218.1097069031550.JavaMail.root@bigbird.psp.pas.earthlink.net>

>From: Dave Howe <DaveHowe at gmx.co.uk>
>Sent: Oct 5, 2004 12:32 PM
>To: cryptography at metzdowd.com
>Subject: Re: IBM's original S-Boxes for DES?

>   More accurately, they didn't protect against linear cryptanalysis - 
>there is no way to know if they knew about it and either didn't want to 
>make changes to protect against that (they weakened the key, so may have 
>wished to keep *some* attacks viable against it to weaken it still 
>further), had to choose (against *either* differential or linear, as 
>they didn't know how to protect against both) or simply the people doing 
>the eval on DES didn't know, as it was rated above their clearance level.

I believe people have since come up with S-boxes that resist both linear and differential cryptanalysis.  But we don't know whether there were still other attacks or constraints they were trying to address.  However, it makes no sense to assume that they left linear attacks in as a backdoor, for two reasons:

a.  They already left a 56-bit key, which was a practical backdoor for people with experience and expertise in building keysearch machines.  (Think of all the expertise in parallel and distributed keysearch that has come out in the public world in the last fifteen years; surely, that was an area NSA had worked on at great depth years earlier!  Things like time-memory tradeoffs, parallel collision search and meet-in-the-middle search, clever optimization tricks for getting the keysearch to run efficiently, etc., along with a large hardware budget, must have made a 56-bit key look much worse from inside the agency than from outside.  (Though there were plenty of people who saw the problems from outside, as well, thus leading to our current understanding of keysearch techniques.)  

b.  Linear attacks on DES, at least the ones we know about, are spectacularly impractical, requiring more plaintexts than you could ever hope to get from an innocent party using the speeds of hardware available when DES was designed and standardized.  

--John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Claudia.Diaz at esat.kuleuven.ac.be  Wed Oct  6 10:03:40 2004
From: Claudia.Diaz at esat.kuleuven.ac.be (Claudia Diaz)
Date: Wed, 6 Oct 2004 16:03:40 +0200 (CEST)
Subject: Announcement 5th APES Workshop (KULeuven, Belgium)
Message-ID: <Pine.LNX.4.58.0410061558590.19446@bezout.esat.kuleuven.ac.be>




Dear,


we are happy to announce the 5th Anonymity and Privacy in Electronic
Services Workshop. In the first part of the workshop, we will have two
invited talks (by Jan Camenisch and Dogan Kesdogan). During the second
part, the research partners of APES will present the results of the
project in the last year on anonymous connections, anonymous email and
anonymous databases.

You can find more information on this project at
https://www.cosic.esat.kuleuven.ac.be/apes

You are kindly invited to attend. In order to estimate the number of
participants, we ask you to register by sending an email to P?la Noe
(Pela.Noe at esat.kuleuven.ac.be).

Feel free to forward this email to anyone potentially interested in
attending.

Best regards,
Claudia


5th APES WORKSHOP
-----------------

Date:       Tuesday, November 23rd
Location:   Auditorium A (ESAT, K.U. Leuven)
            Kasteelpark Arenberg 10
            B-3001 Leuven-Heverlee, Belgium

Fee: Free of charge. We kindly ask you to register in advance by sending
     an email to our secretary P?la Noe (Pela.Noe at esat.kuleuven.ac.be)


AGENDA
------

13:00-13:10 Welcome and Introduction by Bart Preneel (COSIC/KULeuven)

13:10-13:50 Invited talk: "Security and Privacy for E-Transactions" by Jan
            Camenisch (IBM Zurich Research Laboratory)

13:50-14:30 Invited talk: "Personal risk management" by Dogan Kesdogan
            (University of Aachen)

14:30-14:50 Coffee break

14:50-15:30 Anonymous communication infrastructure by Claudia Diaz
            (COSIC/KULeuven)

15:30-16:10 Controlled anonymous email by Vincent Naessens
            (DISTRINET/KULAK)

16:10-16:30 Controlled anonymous databases by Svetla Nikova
            (COSIC/KULeuven)




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From DaveHowe at gmx.co.uk  Wed Oct  6 12:04:49 2004
From: DaveHowe at gmx.co.uk (Dave Howe)
Date: Wed, 06 Oct 2004 17:04:49 +0100
Subject: Quantum cryptography gets "practical"
In-Reply-To: <4163C899.5040708@gmx.co.uk>
References: <BAY24-F3407MJJQ873T000404a4@hotmail.com> <4163C899.5040708@gmx.co.uk>
Message-ID: <416417A1.8090308@gmx.co.uk>

Dave Howe wrote:
>  I think this is part of the
> purpose behind the following paper:
> http://eprint.iacr.org/2004/229.pdf
> which I am currently trying to understand and failing miserably at *sigh*
Nope, finally strugged to the end to find a section pointing out that it 
does *not* prevent mitm attacks.
Anyone seen a paper on a scheme that does?

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct  6 11:46:56 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 6 Oct 2004 11:46:56 -0400
Subject: Big guns board Intertrust DRM bandwagon
Message-ID: <p061104ccbd89c3869f7b@[66.149.49.5]>

<http://www.theregister.co.uk/2004/10/05/coral_consortium/print.html>

The Register


 Biting the hand that feeds IT

The Register ? Internet and Law ? Digital Rights/Digital Wrongs ?

 Original URL: http://www.theregister.co.uk/2004/10/05/coral_consortium/

Big guns board Intertrust DRM bandwagon
By Faultline (peter at rethinkresearch.biz)
Published Tuesday 5th October 2004 15:36 GMT

Intertrust, Philips and Sony have added more top consumer electronics,
content and technology heavyweights to their attempt to create an open
interoperable Digital Rights Management environment.

The system promised at the turn of the year in interview with Philips has
taken a step closer to becoming a reality today with a new DRM clustering
of companies calling itself the Coral Consortium. Lining up with the
expected triumvirate of Intertrust and its two owners Philips and Sony, are
more powerful names in the form of Panasonic, Samsung, Hewlett-Packard and
the News Corp controlled film company Twentieth Century Fox.


Coral describes itself as a cross-industry group to promote
interoperability between digital rights management (DRM) technologies used
in the consumer media market and it is expected to put its weight behind
the Nemo technology emerging from Intertrust. Nemo will act as a bridge
between varying DRM systems, including Intertrust's partners systems and
Microsoft Windows Media DRM.

In Nemo there are defined a set of roles such as client, authorizer,
gateway and orchestrator, and it assumes that they talk to each other over
an IP network, and work is allocated to each of them such as authorization,
peer discovery, notification, services discovery, provisioning, licensing
and membership creation.

The client simply uses the services of the other three peers, the
authorizer decides if the requesting client should have access to a
particular piece of content; the gateway takes on the role of a helper that
will provide more processing power to negotiate a bridge to another
architecture and the orchestrator is a special form of gateway that handles
non-trivial co-ordination such as committing a transaction.

The Consortium says its aim is to end up with an open technology framework
offering a simple and consistent experience to consumers. Most DRM systems,
such as Apple's Fairplay used in its iTunes service and on the iPod,
prevent consumers from playing content packaged and distributed using one
DRM technology on a device that supports a different DRM technology.

Coral's answer is to separate content interoperability from choice of DRM
technology by developing and standardizing a set of specifications focused
on interoperability between different DRM technologies rather than
specifying DRM technologies.

Interoperability

The resulting interoperability layer supports the coexistence of multiple
different DRM technologies and permits devices to find appropriately
formatted content in the time it takes to press the play button, without
consumer awareness of any disparity in format or DRM .

In a recent interview with Faultline, Ruud Peters, the chief executive of
Philips's intellectual property and standards unit told us: "We cannot
force Microsoft to join. This whole thing has to be done on a voluntary
basis, but if Microsoft systems means that there are devices which cannot
play content, and if that content can play on all other devices, then it is
Microsoft that will be seen as not friendly."

He also explained that when moving a piece of content from under the
control of one piece of DRM software to another, if it was to involve a
Trust Authority deciphering the content using an authorized key, and then
re-encrypting using another key, then there is never any need to "break"
the encryption system in a competing DRM standard.

Coral says it will provide interoperability for secure content distribution
over web and home network-based devices and services but has yet to say
anything in detail about the technology it will be using. More details will
emerge at www.coral-interop.org (http://www.coral-interop.org/).

This grouping speaks for over half the Hollywood feature films on the
planet, around 25 per cent of all popular recorded music and substantially
more of the branded consumer electronics goods, and probably has the
strength to hold a standoff with Microsoft's PC based DRM. Twentieth
Century Fox is also reported this week to have agreed to adopt the Blu-ray
disc standard for next-generation DVD players. Not surprising, considering
who its new DRM friends are.

With Sony, its recently acquired MGM Studios and Fox backing the Blu-ray
standard, it's almost a slam dunk for the Sony, Philips, Panasonic standard
over the DVD Forum's HD DVD competing standard, which is still not ready.


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct  6 20:14:41 2004
From: rah at shipwright.com (R. A. Hettinga)
Date: Wed, 6 Oct 2004 20:14:41 -0400
Subject: [ShmooCon-News] First selected BoF run by Jon Callas, CTO, 	PGP
 Corporation
Message-ID: <p0611044ebd8a3ac692ec@[66.149.49.5]>


--- begin forwarded text


Date: Wed, 6 Oct 2004 19:34:24 -0400
To: shmoocon-news at shmoo.com
Cc:
From: shmoocon-news at lists.shmoo.com
Subject: [ShmooCon-News] First selected BoF run by Jon Callas, CTO,
	PGP Corporation
Reply-To: info at shmoocon.org
List-Id: News about Shmoocon  <shmoocon-news.lists.shmoo.com>
List-Post: <mailto:shmoocon-news at lists.shmoo.com>
List-Help: <mailto:shmoocon-news-request at lists.shmoo.com?subject=help>
List-Subscribe: <https://lists.shmoo.com/mailman/listinfo/shmoocon-news>,
	<mailto:shmoocon-news-request at lists.shmoo.com?subject=subscribe>
Sender: shmoocon-news-bounces+rah=shipwright.com at lists.shmoo.com

We're pleased to announce our first selected though-provoking and
potentially controversial BoF for ShmooCon 2005 will be run by Jon
Callas, CTO, PGP Corporation.  For more information check out:

http://www.shmoocon.org/program.html#callas

We look forward to folks discussing how "Information wants to be free,
but programmers want to eat."  Check it out!

Sincerely,

Beetle
_______________________________________________
Shmoocon-News mailing list
Shmoocon-News at lists.shmoo.com
https://lists.shmoo.com/mailman/listinfo/shmoocon-news

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From orourked at eeng.dcu.ie  Thu Oct  7 09:57:50 2004
From: orourked at eeng.dcu.ie (Damien O'Rourke)
Date: Thu, 7 Oct 2004 14:57:50 +0100
Subject: Undergraduate wireless LAN security project?
Message-ID: <005201c4ac75$a2782370$4325ce88@DamienORourke>

Hi,

I was just wondering if anyone had any ideas for a project in wireless
LAN security for a final year undergraduate?
Or something along those lines.

Thanks,
Damien.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pdh at wiredyne.com  Thu Oct  7 11:32:46 2004
From: pdh at wiredyne.com (Peter Hendrickson)
Date: 7 Oct 2004 15:32:46 -0000
Subject: M-209 broken in WWII
In-Reply-To: <41599734.60407@danisch.de>
Message-ID: <20041007153246.26195.qmail@wiredyne.com>

Hadmut Danisch quoted "As a german codebreaker in World War II":
> Even experts didn't know until some years ago that german
> deciphering specialists broke ciphers of the allied in the second
> world war.

German success against the M-209 is discussed in David Kahn's "The
Codebreakers".  It cites a 1962 letter as a source, so presumably this
information was in the 1967 edition.  In other words, German
cryptanalytic success has been public for a long time.

Kahn's book has quite a bit of good information on Axis cryptanalytic
efforts.  Germany was particularly successful, and was using
automation to assist their work.

One little gem is that Italy managed to pull off an active attack
against the Yugoslav Army.  They had been reading Yugoslav traffic for
awhile, got into a difficult situation, and convinced two divisions
they had been ordered to retreat using fake messages.  By the time
this was discovered and resolved the game was over.

Peter

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dirkx at webweaving.org  Thu Oct  7 11:33:48 2004
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Thu, 7 Oct 2004 08:33:48 -0700 (PDT)
Subject: Undergraduate wireless LAN security project?
In-Reply-To: <005201c4ac75$a2782370$4325ce88@DamienORourke>
References: <005201c4ac75$a2782370$4325ce88@DamienORourke>
Message-ID: <20041007082915.S31513@skutsje.san.webweaving.org>



On Thu, 7 Oct 2004, Damien O'Rourke wrote:

> I was just wondering if anyone had any ideas for a project in wireless
> LAN security for a final year undergraduate? Or something along those

(Free)BSD implementation/BSD license implentation of a 802.1x stack usable
in a wireless environment where your links are rather _untrusted_ and
where even the level of trust in an the wireless nodes is not all that
high (so the more trust which can be build without even having private
keys on nodes the better) - ideally in combination with things like:

	http://wleiden.webweaving.org:8080/svn/node-config/other/banlist-patch/

to deal with things on radio level and avoid abuse up to a certain level.
All in all quite harrd to get right from a practical ops perspective with
just the right level of security. If you need a city wide testbed - we'll
have one for you :-).

DW


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From chris.kuethe at gmail.com  Thu Oct  7 12:01:17 2004
From: chris.kuethe at gmail.com (Chris Kuethe)
Date: Thu, 7 Oct 2004 10:01:17 -0600
Subject: Undergraduate wireless LAN security project?
In-Reply-To: <005201c4ac75$a2782370$4325ce88@DamienORourke>
References: <005201c4ac75$a2782370$4325ce88@DamienORourke>
Message-ID: <91981b3e04100709014b51e697@mail.gmail.com>

There's the ever popular wireless security gateway.

Assume you have a mixed population of users on the wireless, some of
whom are trustworthy, some are evil. Some are Admin users, some are
guests. Some are wizards, some are clueless. All of them want to "do
their thing on the wireless."

Keeping in mind all the fun attacks you can use on a wireless net, how
would you go about making network access secure (available, private,
reliable, accountable, controlled) enough and yet be usable to the
average doofus? Enumerate the risks, specific exposures, available
attacks and countermeasures.

I've done it, and it's not hugely hard to do or use.

=========

Think back to the days of thin-net (etc.) where ethernet really was a
broadcast medium. Back then, it was radio over coax, not radio over
air. Many of the same issues still apply. But it's easier to get
802.11 gear these days than it is to get 10b2....

CK

On Thu, 7 Oct 2004 14:57:50 +0100, Damien O'Rourke <orourked at eeng.dcu.ie> wrote:
> Hi,
> 
> I was just wondering if anyone had any ideas for a project in wireless
> LAN security for a final year undergraduate?
> Or something along those lines.
> 
> Thanks,
> Damien.
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> 


-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From sfurlong at acmenet.net  Thu Oct  7 15:09:50 2004
From: sfurlong at acmenet.net (Steve Furlong)
Date: 07 Oct 2004 15:09:50 -0400
Subject: Quantum cryptography gets "practical"
In-Reply-To: <4163C899.5040708@gmx.co.uk>
References: <BAY24-F3407MJJQ873T000404a4@hotmail.com>
	 <4163C899.5040708@gmx.co.uk>
Message-ID: <1097176190.6564.7.camel@daft>

On Wed, 2004-10-06 at 06:27, Dave Howe wrote:
> I have yet to see an advantage to QKE that even mildly justifies the
> limitations and cost over anything more than a trivial link (two
> buildings within easy walking distance, sending high volumes of
> extremely sensitive material between them)

But it's cool!

More seriously, it has no advantage now, but maybe something will come
up. The early telephones were about useless, too, remember. In the mean
time, the coolness factor will keep people playing with it and
researching it.



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kevinkenan at mac.com  Thu Oct  7 18:58:24 2004
From: kevinkenan at mac.com (kevinkenan at mac.com)
Date: Thu, 07 Oct 2004 15:58:24 -0700
Subject: Enterprise key management systems?
Message-ID: <4817450.1097189904851.JavaMail.kevinkenan@mac.com>

What are people using for enterprise key management systems? By enterprise I mean something (centralized) which supports multiple crypto-enabled applications.

Specifically, are there any recommended products which support crypto hardware and database encryption?

Most people I've talked to seem to roll-their-own. Is that also the consensus of this list?

Thanks,

-kenan

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ereed at novell.com  Fri Oct  8 21:32:41 2004
From: ereed at novell.com (Ed Reed)
Date: Fri, 08 Oct 2004 19:32:41 -0600
Subject: Enterprise key management systems?
Message-ID: <s166ea2e.075@sinclair.provo.novell.com>

Novell developed NICI, Novell International Crypto Infrastructure, and
has used it for much of the past decade.  It's a BSAFE wrapper with
several PKI-based applications, including a signed-code authenticating
library loader, exportable dynamic crypto libraries with continuous
authentication across the application-crypto-library interface (so the
open crypto interfaces are both closed), a modular architecture similar
to CDSA with key policy represented in a signed policy certificate
(delivered separately from the crypto engines themselves), architected
to support independent 3rd-party signed crypto modules (intended to
allow national-preferred crypto algorithms to be created and authorized
for use with the commodity-licensed crypto infrastructure).

Using this, we've used it to provide directory-based key management,
shared-key distribution, wrapped exported keys that can be reloaded
without operator intervention, directory-based, per-user secret stores
for passwords and such to allow single-signon, etc, that allows
operators to reset user passwords without losing their secrets (if that
policy is desired - it also effectively makes secrets recoverable in the
event of the loss of the assistance of the employee).

The key-escrow features were designed but never implemented, that I know
of.

And yes, we rolled our own so we could manage the conflicting
requirements for a global software company with a large number of
crypto-enabled applications:

1) must be able to be FIPS 140-1/2 certified algorithms and
implementations, which usually (stay tuned for the OpenSSL FIPS 140
certification success) means they MUST be dynamically linked,
2) exportable applications and crypto under commodity license (no
registration or reporting requirements), which usually means they MUST
be statically linked to close open crypto interface issues with export
from the US
3) single global application part numbers, as we have too many part
numbers already to manage through our direct and indirect sales channels
- we could never double (or more) the number and manage the inventory,
etc. requirements on them all

That requires "something special".  We solved it, as others have, with
dynamic libraries linked via strong authenticating loaders that verify
the crypto libraries are unchanged, and that the key-strength and
algorithms allowed are authorized by the policy certificate delivered
separately from the code (with license disks, if needed).  

Even though the export key strength issues are no longer an issue, the
FIPS 140 and exportability requirements, combined with the
single-partnumber requirement means we still need something like this.

And we've grown VERY accustomed to being able to have NICI export an
obfuscated (or hardware encrypted) key that can be reloaded without
operator intervention (under control of the strong loader) for service
bootstraps.

We're starting to think that if we ever want to move whole sale to a
non-BSAFE based crypto implementation, say, an open source one, that we
will need to port our key distribution and private key management
mechanisms to the new system, as we've not see their like in any
generally available open source framework.

For what it's worth.

Ed
 
 
>>><kevinkenan at mac.com> 10/07/04 3:58 pm >>> 
What are people using for enterprise key management systems? By
enterprise I mean something (centralized) which supports multiple
crypto-enabled applications. 
 
Specifically, are there any recommended products which support crypto
hardware and database encryption? 
 
Most people I've talked to seem to roll-their-own. Is that also the
consensus of this list? 
 
Thanks, 
 
-kenan 
 
--------------------------------------------------------------------- 
The Cryptography Mailing List 
Unsubscribe by sending "unsubscribe cryptography" to
majordomo at metzdowd.com 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Sun Oct 10 11:11:37 2004
From: iang at systemics.com (Ian Grigg)
Date: Sun, 10 Oct 2004 16:11:37 +0100
Subject: AES Modes
Message-ID: <41695129.9000900@systemics.com>

Has anyone kept up to date with AES modes?

http://csrc.nist.gov/CryptoToolkit/modes
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/

I'm looking for basic mode to encrypt blocks (using AES)
of about 1k in length, +/- an order of magnitude.  Looking
at the above table (2nd link) there are oodles of proposed
ones.

It would be nice to have a mode that didn't also require
a separate MAC operation - I get the impression that
this is behind some of the proposals?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ekr at rtfm.com  Sun Oct 10 21:16:21 2004
From: ekr at rtfm.com (Eric Rescorla)
Date: Sun, 10 Oct 2004 18:16:21 -0700
Subject: Certificate serial number generation algorithms
Message-ID: <20041011013122.73C4B7185@sierra.rtfm.com>

Does anyone know the details of the certificate generation algorithms
used by various CAs? 

In particular, Verisign's is very long and I seem to remember someone telling
me it was a hach but I don't recall the details...

Thanks,
-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From brg at gladman.plus.com  Mon Oct 11 04:16:54 2004
From: brg at gladman.plus.com (Brian Gladman)
Date: Mon, 11 Oct 2004 09:16:54 +0100
Subject: AES Modes
In-Reply-To: <41695129.9000900@systemics.com>
References: <41695129.9000900@systemics.com>
Message-ID: <416A4176.5070007@gladman.plus.com>

Ian Grigg wrote:

> Has anyone kept up to date with AES modes?
> 
> http://csrc.nist.gov/CryptoToolkit/modes
> http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
> 
> I'm looking for basic mode to encrypt blocks (using AES)
> of about 1k in length, +/- an order of magnitude.  Looking
> at the above table (2nd link) there are oodles of proposed
> ones.
> 
> It would be nice to have a mode that didn't also require
> a separate MAC operation - I get the impression that
> this is behind some of the proposals?

I provide some code and some speed comparison data for some of the AES 
modes here:

   http://fp.gladman.plus.com/AES/index.htm

I focus mainly on the combined encryption/authentication modes but I 
only cover those that I believe are free of licensing costs.

     Brian Gladman


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Mon Oct 11 08:08:13 2004
From: iang at systemics.com (Ian Grigg)
Date: Mon, 11 Oct 2004 13:08:13 +0100
Subject: AES Modes
In-Reply-To: <FFB7C71E-1B6C-11D9-A873-000A95E2A184@zooko.com>
References: <41695129.9000900@systemics.com> <32BCA8EB-1B64-11D9-A873-000A95E2A184@zooko.com> <416A5729.2030001@systemics.com> <FFB7C71E-1B6C-11D9-A873-000A95E2A184@zooko.com>
Message-ID: <416A77AD.7000904@systemics.com>

Zooko provided a bunch of useful comments in private mail,
which I've edited and forward for list consumption.

Zooko Wilcox-O'Hearn wrote:

> EAX is in the same class as CCM.  I think its slightly better.  Also 
> there is GCM mode, which is perhaps a tiny bit faster, although maybe 
> not if you have to re-key every datagram.  Not sure about the 
> key-agility of these.
> 
> ... I guess the IPv6 sec project has already specified such a thing in 
> detail.  I'm not familiar with their solution.
> 
> If you really want interop and wide adoption, then the obvious thing to 
> do is backport IPsec to IPv4.  Nobody can resist the authority of IETF!
> 
> Alternately, if you don't use a "combined mode" like EAX, then you 
> should follow the "generic composition" cookbook from Bellare and 
> Rogaway [1, 2].
> 
> Next time I do something like this for fun, I'll abandon AES entirely 
> (whee!  how exciting) and try Helix [3].  Also, I printed out this 
> intriguing document yesterday [4].  Haven't read it yet.  It focusses on 
> higher-layer stuff -- freshness and sequencing.

> Feel free to post to metzcrypt and give me credit for bringing the 
> following four URLs to your attention.
> 
> [1] http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm#alternatives
> [2] http://www.cs.ucsd.edu/users/mihir/papers/oem.html
> [3] http://citeseer.ist.psu.edu/561058.html
> [4] http://citeseer.ist.psu.edu/661955.html
> 
> 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Mon Oct 11 12:34:38 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 12 Oct 2004 05:34:38 +1300
Subject: Certificate serial number generation algorithms
In-Reply-To: <20041011013122.73C4B7185@sierra.rtfm.com>
Message-ID: <E1CH38A-0004Cb-00@medusa01>

Eric Rescorla <ekr at rtfm.com> writes:

>In particular, Verisign's is very long and I seem to remember someone telling
>me it was a hach but I don't recall the details...

It's just a SHA-1 hash.  Many CAs use this to make traffic analysis of how
many (or few) certificates they're issuing impossible.  An additional
motivation for use by Verisign was to avoid certs with low serial numbers
having special significance.  While there are a few CA's that follow the
monotonically-increasing-integers scheme that certs were originally intended
to have (and all manner of other weirdness, 32-bit integer IDs of unknown
origin seem to be popular in the "other" category), most seem to use a binary
blob of varying length.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Oct 11 15:19:00 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Mon, 11 Oct 2004 15:19:00 -0400
Subject: Cash, Credit -- or Prints?
Message-ID: <p061104a1bd908ceddbc6@[66.149.49.5]>

<http://online.wsj.com/article_print/0,,SB109744462285841431,00.html>

The Wall Street Journal


 October 11, 2004


Cash, Credit -- or Prints?
Fingerprints May Replace
 Money, Passwords and Keys;
 One Downside: Gummi Fakes

By WILLIAM M. BULKELEY
Staff Reporter of THE WALL STREET JOURNAL
October 11, 2004; Page B1


Fingerprints aren't just for criminals anymore. Increasingly, they are for
customers.

Fingerprint identification is being used to speed up checkouts at Piggly
Wiggly supermarkets in South Carolina, and to open storage lockers at the
Statue of Liberty. Fingerprints are also being used as password substitutes
in cellphones and laptop computers, and in place of combinations to open up
safes.

But these aren't the fingerprints of yore, in which the person placed his
hand on an ink pad, then on paper. Instead, the user sets his hand on a
computerized device topped with a plate of glass, and an optical reader and
special software and chips identify the ridges and valleys of the
fingertips.

Fingerprint technology seems to be reaching critical mass and is spreading
faster than other widely promoted "biometric" identification methods, such
as eyeball scanning, handprint-geometry reading and facial recognition.
Interest in these and other new security systems was heightened by the
September 2001 terror attacks.

"Fingerprints will be dominant for the foreseeable future," says Don
McKeon, the product manager for biometric security at International
Business Machines Corp.

One reason fingerprint-security is spreading is that technological advances
are bringing the cost down. Microsoft Corp. recently introduced a
stand-alone fingerprint reader for $54, and a keyboard and a mouse with
fingerprint readers. Last week, IBM said it would start selling laptop
computers with fingerprint readers built in. These products reduce the need
for personal-computer users to remember passwords.

A customer uses a fingerprint reader to pay at a Piggly Wiggly store,
cutting his checkout time.



Earlier this year, American Power Conversion Corp., a Rhode Island company
that makes backup computer batteries, started selling a fingerprint reader
for PCs with a street price of $45 -- less than half the price of
competitors at the time. American Power says it has sold tens of thousands
of the devices since.

Korea's LG Electronics Inc. has introduced a cellphone with a silicon chip
at its base that requires the owner's finger to be swiped across its
surface before the phone can be used. This summer, NTT DoCoMo Inc. started
selling a similar phone reader that is being used on Japanese trains as an
electronic wallet to pay fares or to activate withdrawals from on-board
cash machines.

Proponents have never had trouble explaining the benefits of fingerprints
as payment-and-password alternatives: Each person has a unique set, and
their use is established in the legal system as an authoritative means of
identification. But some people are uneasy about registering their
fingerprints because of the association with criminality and the potential
that such a universal identifier linked to all personal information would
reduce privacy.

Moreover, numerous businesses and governments have tested fingerprint
systems in the past only to rip them out when the hype failed to match
reality. That's partly because the optical readers have had problems with
certain people's fingers. Elderly people with dry skin, children who
pressed down too hard, even women with smaller fingers -- including many
Asians -- were often rejected as unreadable.

Security experts also have successfully fooled some systems by making
plaster molds of fingers and then creating fake fingers by filling the
molds with Silly-Putty-type plasticizers or gelatin similar to that used in
candy Gummi Bears.

But advocates say the rate of false rejections of legitimate users has been
greatly reduced by improved software. "I'd say 99% of people can register"
their fingers, says Brad Hill, who installed fingerprint-controlled lockers
at his souvenir store at the Statue of Liberty this summer when the
National Park Service forbade tourists from entering the statue while
carrying packages. Mr. Hill was worried that tourists would lose locker
keys when security screeners forced them to empty their pockets.

Some makers of readers also say their technology can solve the fake-finger
problem by taking readings from below the surface skin layer. Or they
suggest combining four-digit ID codes with fingerprint scanning to
virtually eliminate false readings.

Makers of fingerprint readers acknowledge the privacy concerns. But they
maintain that the threat of personal invasion is minimized because most
systems don't store the actual print, but instead use it to generate a
unique series of numbers that can't be reverse-engineered to re-create the
print. And public willingness to submit to fingerprint readers has soared
since the 2001 terrorist attacks, as the need for security overcomes
worries about unwarranted intrusion.

While the market for fingerprint readers is small, it is growing fast.
International Biometric Group, a New York market-research firm, predicts
that sales will rise 86% to $368 million this year from $198 million last
year. AuthenTec Inc., of Melbourne, Fla., which makes the
fingerprint-reading chips used in the LG cellphone, expects to ship more
than three million of them this year, triple the level of 2003. Their price
has fallen below $6 apiece, and Scott Moody, AuthenTec's chief executive,
sees that dropping below $4 next year.

Ubiquitous use of fingerprints could eliminate a huge consumer headache:
remembering passwords for various Web sites. With American Power's
fingerprint reader, users register all of their passwords online, along
with the associated Web sites. Then they never have to type in a password
again.

"Our parents didn't deal with the problem of remembering 20 passwords, and
our grandkids won't even know what they are," says IBM's Mr. McKeon.

Potentially, fingerprint readers also could replace credit and debit cards.
Pay by Touch Co., a closely held San Francisco company that is working with
IBM, installs fingerprint readers in retail stores where customers can
register their fingers by touching the pad five times. Then they can
register supermarket loyalty cards and several credit card-numbers. They
even can use the fingerprint reader to withdraw money from a checking
account at the cash register.

Another use: A consumer could register a driver's license and his or her
age with the system, so clerks won't have to examine identification cards
for purchases of beer or cigarettes. The next time the customer checks out,
he or she just touches the pad, enters his or her phone number and selects
from the list of payment options. Pay by Touch, which charges retailers 5
to 10 cents per transaction, claims the system reduces checkout time by 30%.

One early user of Pay by Touch are a handful of Piggly Wiggly supermarkets.
After installing the system in four stores in July, "a good, strong
percentage of our transactions are done by touch" already, says David
Schools, senior vice president of Piggly Wiggly Carolina Inc., based in
Charleston. He declined to be more specific. The chain hopes that customers
will register checking accounts and make electronic withdrawals via
fingerprint ID to pay for purchases, which would save the grocer steep
credit-card or debit-card fees.

IBM says that convenience stores are experimenting with fingerprints as an
alternative to radio-frequency identification cards like Exxon Mobil
Corp.'s Speedpass, to deal with the "sweaty jogger problem" -- cashless
runners coming in for coffee or Gatorade. The problem with RFID cards is
that anyone can use one that is lost or stolen. Not so with fingerprints.

Jeff Baughan, vice president of information technology at Catholic Health
Systems in Buffalo, N.Y., says he anticipates some day installing wireless
readers on the carts used by nursers that would read patients' fingers, to
double-check that the right patient gets the right medicine. Currently, the
health-care system is installing Ultra-Scan Corp. devices that read fingers
to register incoming patients and make sure that different people aren't
using the same insurance card.

Fingerprint-scanner authorization also is being used by business owners as
a replacement for lock combinations on safes. "Traditionally, two people
are given the same combination, and if there's a loss, how can you figure
out who took it?" says Edward McGunn, president of Corporate Safe
Specialists Inc., of Posen, Ill. He predicts that within two years, 80% of
his sales will be fingerprint safes, partly because it's much simpler to
train an unskilled manager to open one. "This is the most exciting time to
be in the safe business in my lifetime," says Mr. McGunn, a
third-generation safe maker.


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From levitte at stacken.kth.se  Mon Oct 11 12:28:59 2004
From: levitte at stacken.kth.se (Richard Levitte - VMS Whacker)
Date: Mon, 11 Oct 2004 18:28:59 +0200 (CEST)
Subject: Certificate serial number generation algorithms
In-Reply-To: <20041011013122.73C4B7185@sierra.rtfm.com>
References: <20041011013122.73C4B7185@sierra.rtfm.com>
Message-ID: <20041011.182859.64811274.levitte@stacken.kth.se>

In message <20041011013122.73C4B7185 at sierra.rtfm.com> on Sun, 10 Oct 2004 18:16:21 -0700, Eric Rescorla <ekr at rtfm.com> said:

ekr> Does anyone know the details of the certificate generation
ekr> algorithms used by various CAs?

Variants I've heard of are:

 - A simple counter starting at 0 (well, actually, I know this one, as
   that's what OpenSSL does :-))
 - A simple counter starting with a random value (OpenSSL has an
   option for this).
 - A time-based value (I don't recall who did that)
 - A hash of some sort (I believe Verisign does that, among others)

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte   \ Tunnlandsv?gen 52 \ LeViMS at stacken.kth.se
Redakteur at Stacken  \ S-168 36  BROMMA  \ T: +46-708-26 53 44
                    \      SWEDEN       \
Procurator Odiosus Ex Infernis                -- poei at bofh.se
Member of the OpenSSL development team: http://www.openssl.org/

-----------------------------------------------------------------
A: Because it fouls the order in which people normally read text. 
Q: Why is top-posting such a bad thing? 
A: Top-posting. 
Q: What is the most annoying thing on usenet and in e-mail?

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Mon Oct 11 18:07:01 2004
From: iang at systemics.com (Ian Grigg)
Date: Mon, 11 Oct 2004 23:07:01 +0100
Subject: AES Modes
In-Reply-To: <416A4176.5070007@gladman.plus.com>
References: <41695129.9000900@systemics.com> <416A4176.5070007@gladman.plus.com>
Message-ID: <416B0405.2010401@systemics.com>

Jack Lloyd also passed along lots of good comments I'd
like to forward (having gained permission) FTR.  I've
edited them for brevity and pertinence.

Jack Lloyd wrote:
 > If it's small messages, CCM would probably work pretty well. Personally I think
 > CCM is really poorly designed (in terms of easy implementation/usage), but take
 > a look. There is also EAX, which is IMO significantly nicer. There are a ton of
 > others (most of the ones on the page you link to support encrypt+MAC), but it
 > seems like EAX and CCM are the only two that are going anywhere (many of the
 > others are patented and/or rather painful to implement).
 >
 > CCM and EAX are both going to be slower than AES+HMAC because they use AES in
 > some variant of CBC-MAC. Some of the others have faster MACs, mostly ones based
 > on universal hash functions, but the best of them (OCB in particular) have been
 > patented.


I'm obviously being naive here ... I had thought that
the combined mode would be faster, as it would run through
the data once only, and that AES seems to clip along
faster than SHA1.

Are you saying that as far as speed goes, I may as well
do EAS (using CBC) and add a HMAC on the end?

Or are you saying that only the patented ones manage to
deliver the savings we all expect?  Hmm, reading about
OCB on Phil Rogaway's site does clarify this somewhat.
http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm

iang

============== To which jack replied:

 >>I'm obviously being naive here ... I had thought that the combined mode would
 >> be faster, as it would run through the data once only, and that AES seems to
 >> clip along faster than SHA1.


AFAIK all of the modes that use only one block cipher invocation per block of
input are patented. EAX+CCM both use two AES operations per block, and
byte-for-byte SHA-1 is 2-5x faster than AES (at least in the implementations
I've seen/used/written), so using AES+HMAC is probably going to be faster than
AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES chips
and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of course
be much faster than SHA-1.


 >> Are you saying that as far as speed goes, I may as well do EAS (using CBC)
 >> and add a HMAC on the end?


At least on general purpose CPUs, yes.


 >> Or are you saying that only the patented ones manage to deliver the savings
 >> we all expect?  Hmm, reading about OCB on Phil Rogaway's site does clarify
 >> this somewhat.  http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm


Pretty much. Though I just remembered that CWC has not been patented by it's
creators, but I wouldn't be at all surprised if it was covered by one of the
others. Even CWC is probably slower than AES+HMAC is software, though
apparently it's pretty fast in hardware.

-Jack


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From franks at mcs.anl.gov  Mon Oct 11 20:34:19 2004
From: franks at mcs.anl.gov (Frank Siebenlist)
Date: Mon, 11 Oct 2004 17:34:19 -0700
Subject: Cash, Credit -- or Prints?
In-Reply-To: <p061104a1bd908ceddbc6@[66.149.49.5]>
References: <p061104a1bd908ceddbc6@[66.149.49.5]>
Message-ID: <416B268B.2010908@mcs.anl.gov>

Can anyone explain how sophisticated those fingerprint readers are?

Are there readers out there that by themselves are secure devices and 
essentially are able to talk with their servers thru the 
PCs/workstations over a protocol such that any man-in-the-middle, like a 
driver, can not learn anything from the traffic?
(...and all that for less than $40, of course...)

If not, would a trojan then be able to capture your fingerprint's 
digital-fingerprint, and impersonate you from any other node on the network?

-Frank.



R.A. Hettinga wrote:

> <http://online.wsj.com/article_print/0,,SB109744462285841431,00.html>
>
> The Wall Street Journal
>
>
> October 11, 2004
>
>
> Cash, Credit -- or Prints?
> Fingerprints May Replace
> Money, Passwords and Keys;
> One Downside: Gummi Fakes
>
> By WILLIAM M. BULKELEY
> Staff Reporter of THE WALL STREET JOURNAL
> October 11, 2004; Page B1
>
>
> Fingerprints aren't just for criminals anymore. Increasingly, they are for
> customers.
>
> Fingerprint identification is being used to speed up checkouts at Piggly
> Wiggly supermarkets in South Carolina, and to open storage lockers at the
> Statue of Liberty. Fingerprints are also being used as password 
> substitutes
> in cellphones and laptop computers, and in place of combinations to 
> open up
> safes.
>
> But these aren't the fingerprints of yore, in which the person placed his
> hand on an ink pad, then on paper. Instead, the user sets his hand on a
> computerized device topped with a plate of glass, and an optical 
> reader and
> special software and chips identify the ridges and valleys of the
> fingertips.
>
> Fingerprint technology seems to be reaching critical mass and is spreading
> faster than other widely promoted "biometric" identification methods, such
> as eyeball scanning, handprint-geometry reading and facial recognition.
> Interest in these and other new security systems was heightened by the
> September 2001 terror attacks.
>
> "Fingerprints will be dominant for the foreseeable future," says Don
> McKeon, the product manager for biometric security at International
> Business Machines Corp.
>
> One reason fingerprint-security is spreading is that technological 
> advances
> are bringing the cost down. Microsoft Corp. recently introduced a
> stand-alone fingerprint reader for $54, and a keyboard and a mouse with
> fingerprint readers. Last week, IBM said it would start selling laptop
> computers with fingerprint readers built in. These products reduce the 
> need
> for personal-computer users to remember passwords.
>
> A customer uses a fingerprint reader to pay at a Piggly Wiggly store,
> cutting his checkout time.
>
>
>
> Earlier this year, American Power Conversion Corp., a Rhode Island company
> that makes backup computer batteries, started selling a fingerprint reader
> for PCs with a street price of $45 -- less than half the price of
> competitors at the time. American Power says it has sold tens of thousands
> of the devices since.
>
> Korea's LG Electronics Inc. has introduced a cellphone with a silicon chip
> at its base that requires the owner's finger to be swiped across its
> surface before the phone can be used. This summer, NTT DoCoMo Inc. started
> selling a similar phone reader that is being used on Japanese trains as an
> electronic wallet to pay fares or to activate withdrawals from on-board
> cash machines.
>
> Proponents have never had trouble explaining the benefits of fingerprints
> as payment-and-password alternatives: Each person has a unique set, and
> their use is established in the legal system as an authoritative means of
> identification. But some people are uneasy about registering their
> fingerprints because of the association with criminality and the potential
> that such a universal identifier linked to all personal information would
> reduce privacy.
>
> Moreover, numerous businesses and governments have tested fingerprint
> systems in the past only to rip them out when the hype failed to match
> reality. That's partly because the optical readers have had problems with
> certain people's fingers. Elderly people with dry skin, children who
> pressed down too hard, even women with smaller fingers -- including many
> Asians -- were often rejected as unreadable.
>
> Security experts also have successfully fooled some systems by making
> plaster molds of fingers and then creating fake fingers by filling the
> molds with Silly-Putty-type plasticizers or gelatin similar to that 
> used in
> candy Gummi Bears.
>
> But advocates say the rate of false rejections of legitimate users has 
> been
> greatly reduced by improved software. "I'd say 99% of people can register"
> their fingers, says Brad Hill, who installed fingerprint-controlled 
> lockers
> at his souvenir store at the Statue of Liberty this summer when the
> National Park Service forbade tourists from entering the statue while
> carrying packages. Mr. Hill was worried that tourists would lose locker
> keys when security screeners forced them to empty their pockets.
>
> Some makers of readers also say their technology can solve the fake-finger
> problem by taking readings from below the surface skin layer. Or they
> suggest combining four-digit ID codes with fingerprint scanning to
> virtually eliminate false readings.
>
> Makers of fingerprint readers acknowledge the privacy concerns. But they
> maintain that the threat of personal invasion is minimized because most
> systems don't store the actual print, but instead use it to generate a
> unique series of numbers that can't be reverse-engineered to re-create the
> print. And public willingness to submit to fingerprint readers has soared
> since the 2001 terrorist attacks, as the need for security overcomes
> worries about unwarranted intrusion.
>
> While the market for fingerprint readers is small, it is growing fast.
> International Biometric Group, a New York market-research firm, predicts
> that sales will rise 86% to $368 million this year from $198 million last
> year. AuthenTec Inc., of Melbourne, Fla., which makes the
> fingerprint-reading chips used in the LG cellphone, expects to ship more
> than three million of them this year, triple the level of 2003. Their 
> price
> has fallen below $6 apiece, and Scott Moody, AuthenTec's chief executive,
> sees that dropping below $4 next year.
>
> Ubiquitous use of fingerprints could eliminate a huge consumer headache:
> remembering passwords for various Web sites. With American Power's
> fingerprint reader, users register all of their passwords online, along
> with the associated Web sites. Then they never have to type in a password
> again.
>
> "Our parents didn't deal with the problem of remembering 20 passwords, and
> our grandkids won't even know what they are," says IBM's Mr. McKeon.
>
> Potentially, fingerprint readers also could replace credit and debit 
> cards.
> Pay by Touch Co., a closely held San Francisco company that is working 
> with
> IBM, installs fingerprint readers in retail stores where customers can
> register their fingers by touching the pad five times. Then they can
> register supermarket loyalty cards and several credit card-numbers. They
> even can use the fingerprint reader to withdraw money from a checking
> account at the cash register.
>
> Another use: A consumer could register a driver's license and his or her
> age with the system, so clerks won't have to examine identification cards
> for purchases of beer or cigarettes. The next time the customer checks 
> out,
> he or she just touches the pad, enters his or her phone number and selects
> from the list of payment options. Pay by Touch, which charges retailers 5
> to 10 cents per transaction, claims the system reduces checkout time 
> by 30%.
>
> One early user of Pay by Touch are a handful of Piggly Wiggly 
> supermarkets.
> After installing the system in four stores in July, "a good, strong
> percentage of our transactions are done by touch" already, says David
> Schools, senior vice president of Piggly Wiggly Carolina Inc., based in
> Charleston. He declined to be more specific. The chain hopes that 
> customers
> will register checking accounts and make electronic withdrawals via
> fingerprint ID to pay for purchases, which would save the grocer steep
> credit-card or debit-card fees.
>
> IBM says that convenience stores are experimenting with fingerprints as an
> alternative to radio-frequency identification cards like Exxon Mobil
> Corp.'s Speedpass, to deal with the "sweaty jogger problem" -- cashless
> runners coming in for coffee or Gatorade. The problem with RFID cards is
> that anyone can use one that is lost or stolen. Not so with fingerprints.
>
> Jeff Baughan, vice president of information technology at Catholic Health
> Systems in Buffalo, N.Y., says he anticipates some day installing wireless
> readers on the carts used by nursers that would read patients' fingers, to
> double-check that the right patient gets the right medicine. 
> Currently, the
> health-care system is installing Ultra-Scan Corp. devices that read 
> fingers
> to register incoming patients and make sure that different people aren't
> using the same insurance card.
>
> Fingerprint-scanner authorization also is being used by business owners as
> a replacement for lock combinations on safes. "Traditionally, two people
> are given the same combination, and if there's a loss, how can you figure
> out who took it?" says Edward McGunn, president of Corporate Safe
> Specialists Inc., of Posen, Ill. He predicts that within two years, 80% of
> his sales will be fingerprint safes, partly because it's much simpler to
> train an unskilled manager to open one. "This is the most exciting time to
> be in the safe business in my lifetime," says Mr. McGunn, a
> third-generation safe maker.
>
>

-- 
Frank Siebenlist franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Oct 11 21:48:45 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Mon, 11 Oct 2004 21:48:45 -0400
Subject: Congress Close to Establishing Rules for Driver's Licenses
Message-ID: <p0611043abd90ce783887@[66.149.49.5]>

<http://nytimes.com/2004/10/11/politics/11identity.html?pagewanted=print&position=>

The New York Times

October 11, 2004

Congress Close to Establishing Rules for Driver's Licenses
By MATTHEW L. WALD

ASHINGTON, Oct. 10 - Following a recommendation of the Sept. 11 commission,
the House and Senate are moving toward setting rules for the states that
would standardize the documentation required to obtain a driver's license,
and the data the license would have to contain.

 Critics say the plan would create a national identification card. But
advocates say it would make it harder for terrorists to operate, as well as
reduce the highway death toll by helping states identify applicants whose
licenses had been revoked in other states.

The Senate version of the intelligence bill includes an amendment, passed
by unanimous consent on Oct. 1, that would let the secretary of homeland
security decide what documents a state would have to require before issuing
a driver's license, and would also specify the data that the license would
have to include for it to meet federal standards. The secretary could
require the license to include fingerprints or eye prints. The provision
would allow the Homeland Security Department to require use of the license,
or an equivalent card issued by motor vehicle bureaus to nondrivers for
identification purposes, for access to planes, trains and other modes of
transportation.

The bill does not give the department the authority to force the states to
meet the federal standards, but it would create enormous pressure on them
to do so. After a transition period, the department could decide to accept
only licenses issued under the rules as identification at airports.

 The House's version of the intelligence bill, passed Friday, would require
the states to keep all driver's license information in a linked database,
for quick access. It also calls for "an integrated network of screening
points that includes the nation's border security system, transportation
system and critical infrastructure facilities that the secretary determines
need to be protected against terrorist attack."

 The two versions will go to a House-Senate conference committee.

 Some civil liberties advocates say they are horrified by the proposal.

"I think it means we're going to end up with a police state, essentially,
by allowing the secretary of homeland security to designate the sensitive
areas and allowing this integrating screening system," said Marv Johnson,
the legislative counsel for the American Civil Liberties Union. If the
requirement to show the identification card can be applied to any mode of
transportation, he said, that could eventually include subways or highways,
and the result would be "to require you to have some national ID card,
essentially, in order to go from point A to point B."

James C. Plummer Jr., a policy analyst at Consumer Alert, a nonprofit
organization based here, said, "You're looking at a system of internal
passports, basically."

But a Senate aide who was involved in drafting the bipartisan language of
the amendment said that in choosing where to establish a checkpoint, the
provision "does not give the secretary of homeland security any new
authority."

The aide, who asked not to be identified because of his involvement in
drafting the measure, said it would not create a national identification
card but would standardize a form of identification routinely issued by
states.

 Representative Candice S. Miller, the Michigan Republican who drafted the
license section of the House measure, said, "I don't think this is anything
that should cause anyone concern."

Of the 50 states, 48 are members of interstate compacts that exchange
information on moving violations, so that a driver from, say, Maryland, who
picks up a speeding ticket in Florida will accumulate points in his home
state. But Michigan and Wisconsin are not members of a compact. Ms. Miller
said one purpose of the provision she wrote was to fix that problem.

 A spokesman for the American Association of Motor Vehicle Administrations,
which represents the state officials who issue driver's licenses, said
linking the databases and strengthening control over who could get a
license was long overdue. "The American public should be outraged to know
that departments of motor vehicles nationwide lack the capability to do the
jobs we've asked them to do," said the spokesman, Jason King.

In both houses, the legislation is geared to respond to numerous
recommendations made by the Sept. 11 commission. For years before the
terrorist attacks of Sept. 11, 2001, law enforcement officials, especially
those concerned with identity theft, argued that the states should have
more rigorous standards for issuing driver's licenses. But the commission
pointed out that "fraud in identification documents is no longer just a
problem of theft."


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Tue Oct 12 09:57:15 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Tue, 12 Oct 2004 09:57:15 -0400 (GMT-04:00)
Subject: AES Modes
Message-ID: <8230092.1097589436213.JavaMail.root@donald.psp.pas.earthlink.net>

>From: Ian Grigg <iang at systemics.com>
>Sent: Oct 10, 2004 11:11 AM
>To: Metzdowd Crypto <cryptography at metzdowd.com>
>Subject: AES Modes


>I'm looking for basic mode to encrypt blocks (using AES)
>of about 1k in length, +/- an order of magnitude.  Looking
>at the above table (2nd link) there are oodles of proposed
>ones.

>It would be nice to have a mode that didn't also require
>a separate MAC operation - I get the impression that
>this is behind some of the proposals?

I think CCM is just about perfect for this goal.  The MAC isn't free, but it's integrated into the chaining mode.  There are also some patented modes that provide a MAC for almost no extra computation(OCB, IACBC), and some proposed modes that combine an efficient, parallelizeable MAC with encryption in a secure way (CWC,GCM), though none of these are standards yet.

>iang

--John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From brg at gladman.plus.com  Tue Oct 12 13:17:41 2004
From: brg at gladman.plus.com (Brian Gladman)
Date: Tue, 12 Oct 2004 18:17:41 +0100
Subject: AES Modes
In-Reply-To: <416B0405.2010401@systemics.com>
References: <41695129.9000900@systemics.com> <416A4176.5070007@gladman.plus.com> <416B0405.2010401@systemics.com>
Message-ID: <416C11B5.4070907@gladman.plus.com>

Ian Grigg wrote:

> Jack Lloyd also passed along lots of good comments I'd
> like to forward (having gained permission) FTR.  I've
> edited them for brevity and pertinence.

[snip]
>  >>I'm obviously being naive here ... I had thought that the combined 
> mode would
>  >> be faster, as it would run through the data once only, and that AES 
> seems to
>  >> clip along faster than SHA1.
> 
> AFAIK all of the modes that use only one block cipher invocation per 
> block of
> input are patented. EAX+CCM both use two AES operations per block, and
> byte-for-byte SHA-1 is 2-5x faster than AES (at least in the 
> implementations
> I've seen/used/written), so using AES+HMAC is probably going to be 
> faster than
> AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES 
> chips
> and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of 
> course
> be much faster than SHA-1.

Maybe my C implementation of SHA1 is hopeless but I get SHA1 on an x86 
at about 17 cycles per byte (over 100,000 bytes) and AES in C at 21 
cycles per byte.

So I would put these two algorihms at about the same speed in C. In 
consequence I rather suspect that the 'two encryptions per block' cost 
might also apply to combined modes when AES is used with HMAC-SHA1.

Rich Schroeppel's CS mode has been added to the NIST modes list earlier 
this year and is not patented. It seems to have a cost that is close to 
'one encryption per block' but it has the 'interesting' property of 
using the internal 'mid-point' state of the cipher algorithm that is in use.

    Brian Gladman


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Oct 12 14:15:53 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Tue, 12 Oct 2004 14:15:53 -0400
Subject: Airline ID requirement faces legal challenge
Message-ID: <p061104aebd91cf5c6f2b@[66.149.49.5]>

<http://www.usatoday.com/tech/news/surveillance/2004-10-10-privacy_x.htm>

USA Today



Airline ID requirement faces legal challenge
By Richard Willing, USA TODAY
At a time when Americans have come to expect tight security for air travel,
it might seem to be an odd question: Does requiring airline passengers to
show identification before they board domestic flights amount to an
"unreasonable search" under the Constitution?

John Gilmore is challenging the federal domestic airline ID requirement,
saying it violates his right to travel in the USA anonymously.
File photo

Yes, says John Gilmore, a computer whiz who made a fortune as an early
employee of Sun Microsystems. His challenge of the federal ID requirement,
which soon could get a hearing before a U.S. appeals court in San
Francisco, is one of the latest court battles to test the balance between
security concerns and civil liberties.

 At issue is Gilmore's claim that checking the IDs of passengers on
domestic flights violates his right to travel throughout the USA
anonymously, without the government monitoring him.

 Lawyers involved in the case say it apparently is the first such challenge
to the federal rules that require airline passengers to provide
identification. In a similar case, two peace activists are suing the U.S.
government to determine how their names came to be placed on a federal
"no-fly list." Rebecca Gordon and Janet Adams were not allowed to board a
San Francisco to Boston flight in August 2002 after they were told that
their names were on a "secret FBI" list of potential security threats,
their court filing says.

"I believe I have a right to travel in my own country without presenting
what amounts to an internal passport," Gilmore, 49, said in an interview.
"I have a right to be anonymous, (to not) be tracked by my government for
no good reason."

Gilmore said he has no problem with security checks that focus on
passengers' luggage. He says he also does not object to having to present a
passport to board flights to other countries.

 Some privacy groups say Gilmore has a point. But others who support the ID
requirement have cast the San Francisco resident as being out of touch with
the realities of air travel since the Sept. 11 attacks.

Kent Scheidegger, counsel for the Criminal Justice Legal Foundation, a
conservative group in Sacramento, says the ID requirement is good policy
and "eminently constitutional."

"The Fourth Amendment forbids not searches that you don't like, it forbids
unreasonable searches," he says. "Nothing could be more reasonable at this
time than to know who you're flying with."

 The Justice Department is fighting Gilmore's claim. Acting on the
department's motion, a U.S. district court judge in San Francisco dismissed
the suit last March. Gilmore has appealed; a hearing before the 9th Circuit
Court of Appeals is likely to be scheduled after briefs are filed next
month.

In court papers, the Justice Department has not defended the ID policy, or
even acknowledged it exists. It has said national security law requires
that this aspect of the case be argued in a courtroom closed to the public,
including Gilmore. The appeals court denied the government's secrecy
request Sept. 20, and the government has asked the court to reconsider.

 Rules on the Transportation Security Administration's Web site say
passengers 18 and older need one form of government-issued photo
identification or two forms of non-photo identification to board domestic
flights.

 Airlines adopted such a policy on their own after terrorists bombed an
international flight over Lockerbie, Scotland, in December 1988. The bomb
that killed all 270 passengers on the jet was said to have been placed in a
passenger's luggage by a terrorist who got into a restricted area. The
airlines say checking IDs against luggage and passenger information is a
way to deny terrorists access to flights.

The TSA, formed two years ago in the wake of the Sept. 11 attacks, checks
IDs to verify passenger identities and to check them against "watch lists"
of known or suspected terrorists.

Gilmore's suit says the requirement amounts to an unreasonable search, a
"burden" on the right to travel and a form of self-incrimination because it
singles out "anonymous travelers" for searching.

Gilmore said the ID requirement does little to ensure security. "Ordinary
citizens may show correct identification, but do we really think that
someone who is willing to commit a terrorist act won't also be willing to
present false identification?"

Gilmore's suit was filed in 2002, after he was denied seats on two flights
at the airport in Oakland. It was his first domestic flight since the 9/11
attacks. Before then, Gilmore said, he was permitted to board flights after
presenting a Federal Aviation Administration document that said showing IDs
was optional.

In 1982, Gilmore, a computer programmer, was the first person hired by the
founders of what became Sun Microsystems. He retired eight years ago with
what his publicist, Bill Scannell, calls "multiples" of millions of dollars.

Since then, Gilmore said, he has worked to promote "individual rights," in
part by sponsoring a foundation that is critical of travel restrictions and
what he considers violations of speech and privacy rights.

Last year, before taking off on a British Airways flight from San Francisco
to London, Gilmore angered fellow travelers by refusing to remove a blue
button on his lapel that had the words "suspected terrorist" imposed over
the picture of an airliner. After a delay, the pilot went back to the gate
and ordered Gilmore off the jet.

While his case moves through court, Gilmore has remained grounded when it
comes to domestic travel.

He hired friends to drive him to San Diego and across the country to attend
board meetings of corporate and non-profit groups. He took a driving
vacation to Oregon. Invited to a family reunion in Massachusetts, he
thought of chartering a private plane but balked at the $33,000 price.

"Yes, it can be inconvenient at times," Gilmore said of his fight against
the ID requirement. "But I believe I'm right."


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From js at joergschneider.com  Wed Oct 13 14:59:40 2004
From: js at joergschneider.com (Joerg Schneider)
Date: Wed, 13 Oct 2004 20:59:40 +0200
Subject: Certificate serial number generation algorithms
In-Reply-To: <20041011.182859.64811274.levitte@stacken.kth.se>
References: <20041011013122.73C4B7185@sierra.rtfm.com> <20041011.182859.64811274.levitte@stacken.kth.se>
Message-ID: <416D7B1C.9020201@joergschneider.com>


Richard Levitte - VMS Whacker schrieb:
> Variants I've heard of are:
[...]
- Another option that I've seen is to use a counter and encrypt it with 
a block chipher using a fixed key. This guarantees uniqueness (because 
encryption is bijective) while concealing the counter and using less 
bytes than a hash.

J?rg


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dj at deadhat.com  Wed Oct 13 13:59:53 2004
From: dj at deadhat.com (dj at deadhat.com)
Date: Wed, 13 Oct 2004 10:59:53 -0700 (PDT)
Subject: AES Modes
In-Reply-To:      <8230092.1097589436213.JavaMail.root@donald.psp.pas.earthlink.net>
References:     <8230092.1097589436213.JavaMail.root@donald.psp.pas.earthlink.net>
Message-ID: <64887.134.134.136.1.1097690393.squirrel@www.deadhat.com>

On the IEEE 802 standards track, CCM and GCM have traction. CCM has been
in 802.11 for a while and the 802.16-2004 was published last week,
supplanting the broken DES-CBC mode with AES-CCM. For wireless systems, we
know and like CCM and it's going to take a lot to oust it.

I'm aware of a handful of other wireless protocols in development that
appear to be all headed the CCM way.

GCM proposed for 802.1ae linksec. This is the 'fast' mode for wired ethernet.

For packetised traffic below 1Gbps, CCM works just great. The CTR and CBC
parts of CCM run in parallel in hardware, making the basic latency = 1 AES
(which is 11 clocks in a simple implementation). With a bit of HW loop
unrolling and pipelining, I can do CCM upto several gigabits.

CCM nicely matches the structure of packets. Namely
1) Get header -> Process additional authenticated data
2) Get payload -> Process MAC and encryption in parallel.
So it is not a bear to implement in a typical communications datapath IC,
where things are presented to you in this order.

GCM allows block level parallelism up to a point. Hence enabling me to put
lots of parallel AES blocks on a chip and go at multi gigabits without
breaking a sweat. It does however have all that Galois arithmetic to do
per block, which increases the path depth a bit.

There is however a fundamental speed problem with packet oriented AES
based modes. The parallelism you can achieve on things like GCM requires
that you have multiple blocks to run in parallel. If I get a large number
of small packets, each < 128 bits long, then there's nothing to do in
parallel at the block level and so my speed limit is determined by how
fast I can run 11 rounds of AES.

This may come to bite us in the future and when we start having to protect
data pushing the terabits, we either need larger packets or something
different in the crypto. One way is to protect over large packet
aggregates, but no 802 level protocol is set up to support it. Stream
ciphers look attractive here, we can make them go *really* fast in
hardware.

Another frustrating aspect of the current crop of modes is frame
expansion. Throwing in an 8 byte nonce and an 8 byte ICV per packet is a
heavy overhead. Deriving nonces from the protocol state is generally not
wise since the frame counts are either non existant (802.3, 802.11) or not
secured (802.16).

In the coming years, I would like to see link protocols (I.E. 802.*) move
link security down to the PHY, to protect management and data traffic
equally, to secure the protocol state as well as data and so to reduce
packet overhead. I would also like to see the standardized crypto and
protocols be structured to work over larger aggregates of packets,
protecting the structure of transmission as well as the content and
allowing much greater levels of parallelism in the HW implementations.

Obviously, none of this is very relevant above layer 2.

Regards,
DJ

>>From: Ian Grigg <iang at systemics.com>
>>Sent: Oct 10, 2004 11:11 AM
>>To: Metzdowd Crypto <cryptography at metzdowd.com>
>>Subject: AES Modes
>
>
>>I'm looking for basic mode to encrypt blocks (using AES)
>>of about 1k in length, +/- an order of magnitude.  Looking
>>at the above table (2nd link) there are oodles of proposed
>>ones.
>
>>It would be nice to have a mode that didn't also require
>>a separate MAC operation - I get the impression that
>>this is behind some of the proposals?
>
> I think CCM is just about perfect for this goal.  The MAC isn't free, but
> it's integrated into the chaining mode.  There are also some patented
> modes that provide a MAC for almost no extra computation(OCB, IACBC), and
> some proposed modes that combine an efficient, parallelizeable MAC with
> encryption in a secure way (CWC,GCM), though none of these are standards
> yet.
>
>>iang
>
> --John
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at metzdowd.com
>


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From kelsey.j at ix.netcom.com  Wed Oct 13 15:51:22 2004
From: kelsey.j at ix.netcom.com (John Kelsey)
Date: Wed, 13 Oct 2004 15:51:22 -0400 (GMT-04:00)
Subject: Financial identity is *dangerous*? (was re: Fake companies,
 real money)
Message-ID: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net>

>From: Chris Kuethe <chris.kuethe at gmail.com>
>Sent: Oct 13, 2004 1:15 PM
>To: "James A. Donald" <jamesd at echeque.com>
>Cc: cryptography at metzdowd.com, 
>	"cypherpunks at al-qaeda.net" <cypherpunks at al-qaeda.net>
>Subject: Re: Financial identity is *dangerous*? (was re: Fake companies, real money)

On Wed, 13 Oct 2004 09:27:20 -0700, James A. Donald <jamesd at echeque.com> wrote:
> Two problems:
...

>> It is clear that the world needs a fully cashlike form of
>> internet money, that there is real demand for this, but the low
>> security of personal computers makes it insecure from thieves,
>> and the hostility of national governments make it insecure from
>> governments.

>Agreed. I would hope that users of "iCash" get fully educated on what
>that entails: that that blob of bits is just as much $20 as that green
>piece of paper or that big pile of quarters. And if someone gets it
>and spends it, you may as well have been mugged.

Okay, but there's a problem:  If you want to mug me personally, you have to show up where I am, catch me unaware, take some personal risk that I'll fight back or shoot you or something, or that a cop will happen by at an inopportune moment, or that there's some surveilance camera you don't know about catching the whole thing on tape.  At the end of that, you've done one mugging, and made maybe $100 or so.  This is why mugging, armed robbery, etc., is basically a crime for people who don't think too far ahead.   

If you want to steal anonymous bearer assets from networked computers, you're going to contrive to do a whole lot of it at once, and you're going to have enormous incentives to develop new attacks to do so.  I have to care about attackers everywhere on Earth, and about the most capable getting past my defenses.  It's not like trying to keep random bored teenagers from breaking into your house by putting a proper lock on a properly installed door, it's like trying to keep a team of ex-SEALs, safecrackers, locksmiths, and demolition experts from breaking into your house.  

Today, most of what I'm trying to defend myself from online is done as either a kind of hobby (most viruses), or as fairly low-end scams that probably net the criminals reasonable amounts of money, but probably don't make them rich.  Imagine a world where there are a few hundred million dollars in untraceable assets waiting to be stolen, but only on Windows XP boxes with the latest patches, firewalls and scanners installed, and reasonable security settings.  IMO, that's a world where every day is day zero.  All bugs are shallow, given enough qualified eyeballs, and with that kind of money on the table, there would be plenty of eyeballs looking.  

And once it's done, several thousand early adopters are out thousands of dollars each.  This isn't much of an advertisement for the payment system.  It's anonymous and based on bearer instruments, so there's no way to run the fraudulent transactions back.  The money's gone, and the attackers are richer, and the next, more demanding round of attacks has been capitalized.  

>People do eventually learn when it costs them something out of pocket.
>Now that they've learned that the white headphones mean "I'm a target
>with an iPod, mug me!" I see a lot of iPod users with boring old sony
>or koss headphones. Right now, insecurity doesn't cost the end-user
>enough. As soon as some virus comes along and wipes out some new york
>times columnist's savings, and he screams about it, then and only then
>will the slightest nonzero percentage of the sheeple pay attention for
>a bit.

They also have to be able to do something about it.  What would you tell a reasonably bright computer programmer with no particular expertise in security about how to keep a bearer asset as valuable as his car stored securely on a networked computer?  If you can't give him an answer that will really work in a world where these bearer assets are  common, you're just not going to get a widespread bearer payment system working, for the same reason that there's probably nobody jogging with an iPod through random the streets of Sadr City, no matter how careful they're being.

...

--John Kelsey


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From astiglic at okiok.com  Wed Oct 13 22:10:06 2004
From: astiglic at okiok.com (Anton Stiglic)
Date: Wed, 13 Oct 2004 22:10:06 -0400
Subject: New IBM Thinkpad includes biometrics
In-Reply-To: <416B268B.2010908@mcs.anl.gov>
Message-ID: <20041014020959.D5FCCB4082@mail.okiok.com>


http://www.theregister.co.uk/2004/10/05/biometric_thinkpad_t42/

I wonder how well it can counter the attacks discussed by researchers in the
last few years.  Like reactivating a fingerprint authentication by breathing
on the sensor's surface containing residue fat traces of the finger, or
placing a bag of water.  Or the jelly finger trick.
The biometric authentication might very well make the laptop less secure
than password-based authentication.

--Anton




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eay at pobox.com  Wed Oct 13 22:08:16 2004
From: eay at pobox.com (Eric Young)
Date: Thu, 14 Oct 2004 12:08:16 +1000
Subject: AES Modes
In-Reply-To: <416C11B5.4070907@gladman.plus.com>
References: <41695129.9000900@systemics.com> <416A4176.5070007@gladman.plus.com> <416B0405.2010401@systemics.com> <416C11B5.4070907@gladman.plus.com>
Message-ID: <1097719696.416ddf90315e8@mail.iinet.net.au>

Quoting Brian Gladman <brg at gladman.plus.com>:

> Ian Grigg wrote:
> 
> > Jack Lloyd also passed along lots of good comments I'd
> > like to forward (having gained permission) FTR.  I've
> > edited them for brevity and pertinence.
> 
> [snip]
> >  >>I'm obviously being naive here ... I had thought that the combined 
> > mode would
> >  >> be faster, as it would run through the data once only, and that AES 
> > seems to
> >  >> clip along faster than SHA1.
> > 
> > AFAIK all of the modes that use only one block cipher invocation per 
> > block of
> > input are patented. EAX+CCM both use two AES operations per block, and
> > byte-for-byte SHA-1 is 2-5x faster than AES (at least in the 
> > implementations
> > I've seen/used/written), so using AES+HMAC is probably going to be 
> > faster than
> > AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES 
> > chips
> > and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of 
> > course
> > be much faster than SHA-1.
> 
> Maybe my C implementation of SHA1 is hopeless but I get SHA1 on an x86 
> at about 17 cycles per byte (over 100,000 bytes) and AES in C at 21 
> cycles per byte.
> 
> So I would put these two algorihms at about the same speed in C. In 
> consequence I rather suspect that the 'two encryptions per block' cost 
> might also apply to combined modes when AES is used with HMAC-SHA1.

Are you running on a P4?  ASM for sha1 on a P4 takes about 11.9 cycles 
per byte.  The P4 is a very touchy x86 implementation.
On most other architectures I nearly always see a bit less than 2 times faster
sha1 vs AES.  On AMD64, asm, I have
AES-cbc at 12.2 cycles per byte and sha1 at 6.8.  This is about
as good a CPU as it gets (IPC near 3 for both implementations).

eric


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From brg at gladman.plus.com  Thu Oct 14 02:32:03 2004
From: brg at gladman.plus.com (Brian Gladman)
Date: Thu, 14 Oct 2004 07:32:03 +0100
Subject: AES Modes
In-Reply-To: <1097719695.416ddf8f0d796@mail.iinet.net.au>
References: <41695129.9000900@systemics.com> <416A4176.5070007@gladman.plus.com> <416B0405.2010401@systemics.com> <416C11B5.4070907@gladman.plus.com> <1097719695.416ddf8f0d796@mail.iinet.net.au>
Message-ID: <416E1D63.1010402@gladman.plus.com>

Eric Young wrote:
> Quoting Brian Gladman <brg at gladman.plus.com>:
> 
> 
>>Ian Grigg wrote:
>>
>>
>>>Jack Lloyd also passed along lots of good comments I'd
>>>like to forward (having gained permission) FTR.  I've
>>>edited them for brevity and pertinence.
>>
>>[snip]
>>
>>> >>I'm obviously being naive here ... I had thought that the combined 
>>>mode would
>>> >> be faster, as it would run through the data once only, and that AES 
>>>seems to
>>> >> clip along faster than SHA1.
>>>
>>>AFAIK all of the modes that use only one block cipher invocation per 
>>>block of
>>>input are patented. EAX+CCM both use two AES operations per block, and
>>>byte-for-byte SHA-1 is 2-5x faster than AES (at least in the 
>>>implementations
>>>I've seen/used/written), so using AES+HMAC is probably going to be 
>>>faster than
>>>AES/EAX or AES/CCM. The obvious exception being boxes with hardware AES 
>>>chips
>>>and slow CPUs (eg, an ARM7 with an AES coprocessor), where AES will of 
>>>course
>>>be much faster than SHA-1.
>>
>>Maybe my C implementation of SHA1 is hopeless but I get SHA1 on an x86 
>>at about 17 cycles per byte (over 100,000 bytes) and AES in C at 21 
>>cycles per byte.
>>
>>So I would put these two algorihms at about the same speed in C. In 
>>consequence I rather suspect that the 'two encryptions per block' cost 
>>might also apply to combined modes when AES is used with HMAC-SHA1.
> 
> Are you running on a P4?  ASM for sha1 on a P4 takes about 11.9 cycles 
> per byte.  The P4 is a very touchy x86 implementation.
> On most other architectures I nearly always see a bit less than 2 times faster
> sha1 vs AES.  On AMD64, asm, I have
> AES-cbc at 12.2 cycles per byte and sha1 at 6.8.  This is about
> as good a CPU as it gets (IPC near 3 for both implementations).

The SHA1 figure is for a P3 using VC++ set to generate code that will 
run on all Pentium family machines.  I have not optimised the C code for 
any particular machine. 17/12 for C/ASM is a bit worse than I would have 
hoped for but is not that bad.

I would not be surprised to see an average AES/SHA1 speed comparison in 
the 1.5:2.5 range but I was a bit surprised to see Jack's 2.0:5.0 range.

I will have to see if VC++ can be coaxed down from 17 cycles per byte 
for SHA1 without giving up on code that runs on all Pentium compatible 
machines :-)

    Brian Gladman


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Oct 14 15:38:40 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Thu, 14 Oct 2004 15:38:40 -0400
Subject: Tor 0.0.9pre3 is out (fwd from arma@mit.edu)
Message-ID: <p0611042abd94862c4b37@[66.149.49.5]>


--- begin forwarded text


Date: Thu, 14 Oct 2004 12:45:03 +0200
From: Eugen Leitl <eugen at leitl.org>
To: cypherpunks at al-qaeda.net
Subject: Tor 0.0.9pre3 is out (fwd from arma at mit.edu)
User-Agent: Mutt/1.4i
Sender: owner-cypherpunks at al-qaeda.net

From: Roger Dingledine <arma at mit.edu>
Subject: Tor 0.0.9pre3 is out
To: or-dev at freehaven.net
Date: Thu, 14 Oct 2004 06:36:18 -0400
Reply-To: or-dev at freehaven.net

Along with the bugfixes from 0.0.8.1, plus more bugfixes, this release
makes the dirservers file obsolete (finally) in favor of config option
lines to specify the location and fingerprint of each dirserver you
want to trust. We also now support the use of an http proxy for fetching
directories.

tarball:   http://freehaven.net/tor/dist/tor-0.0.9pre3.tar.gz
signature: http://freehaven.net/tor/dist/tor-0.0.9pre3.tar.gz.asc
(use -dPr tor-0_0_9pre3 if you want to check out from cvs)

  o Bugfixes on 0.0.8.1:
    - Better torrc example lines for dirbindaddress and orbindaddress.
    - Improved bounds checking on parsed ints (e.g. config options and
      the ones we find in directories.)
    - Better handling of size_t vs int, so we're more robust on 64
      bit platforms.
    - Fix the rest of the bug where a newly started OR would appear
      as unverified even after we've added his fingerprint and hupped
      the dirserver.
    - Fix a bug from 0.0.7: when read() failed on a stream, we would
      close it without sending back an end. So 'connection refused'
      would simply be ignored and the user would get no response.

  o Bugfixes on 0.0.9pre2:
    - Serving the cached-on-disk directory to people is bad. We now
      provide no directory until we've fetched a fresh one.
    - Workaround for bug on windows where cached-directories get crlf
      corruption.
    - Make get_default_conf_file() work on older windows too.
    - If we write a *:* exit policy line in the descriptor, don't write
      any more exit policy lines.

  o Features:
    - Use only 0.0.9pre1 and later servers for resolve cells.
    - Make the dirservers file obsolete.
      - Include a dir-signing-key token in directories to tell the
        parsing entity which key is being used to sign.
      - Remove the built-in bulky default dirservers string.
      - New config option "Dirserver %s:%d [fingerprint]", which can be
        repeated as many times as needed. If no dirservers specified,
        default to moria1,moria2,tor26.
    - Make moria2 advertise a dirport of 80, so people behind firewalls
      will be able to get a directory.
    - Http proxy support
      - Dirservers translate requests for http://%s:%d/x to /x
      - You can specify "HttpProxy %s[:%d]" and all dir fetches will
        be routed through this host.
      - Clients ask for /tor/x rather than /x for new enough dirservers.
        This way we can one day coexist peacefully with apache.
      - Clients specify a "Host: %s%d" http header, to be compatible
        with more proxies, and so running squid on an exit node can work.

----------

--
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net

[demime 1.01d removed an attachment of type application/pgp-signature]

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Oct 14 19:08:59 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Thu, 14 Oct 2004 19:08:59 -0400
Subject: Airport insanity
Message-ID: <p06110441bd9498c8a7e3@[66.149.49.5]>

<http://www.townhall.com/columnists/calthomas/printct20041013.shtml>

Townhall.com

Airport insanity
Cal Thomas (back to web version) | Send

October 13, 2004

Ted Kennedy and I have something in common. We are both on airline lists as
potential terror suspects.

Kennedy was recently denied access to a US Airways flight out of
Washington, one he has taken for 40 years.

I am on a US Airways list of some type that apparently requires airline
employees to take my driver's license behind closed doors, have a
conference and then stamp my ticket with a code that mandates my person and
my carry-on bag be searched. Every time I fly, which is sometimes several
times a week. I especially appreciate the crotch grab to make sure I'm not
hiding any weapons of mass destruction. How would you like to be the
trainer for this procedure?

The idiocy virus is now spreading to other airlines. It seems someone who
shares my name is wanted by authorities. I hope he is getting some of my
hate mail. Logic should dictate that once I prove I am not the guy they are
looking for, they would take me off the suspect list. But, no, our misnamed
Transportation Security Administration (TSA) is anything but logical.

US Airways gives me a TSA phone number to call. I am not surprised when a
machine answers. The machine promises a "prompt" response. I leave a
message. There is no response. A few days later, I call again. Same
recording, same message, same non-response. I send an e-mail to TSA. This
time I receive an "automated reply," assuring me of a prompt response. Two
days later, I receive another e-mail informing me I will have to fill out a
form to prove I am not a terrorist. This is an interesting twist on the
"innocent until proven guilty" standard in law.

The confusion plot thickens. Two weeks ago, TSA approved my application for
"registered traveler" status as part of an experimental program at some
airports for frequent travelers. I recorded my "eye print" and fingerprint,
and now a machine can identify me and allow me to go to the head of the
security line, but only at the airport where I applied.

Other participating airports require applications to be made at each of
those airports, even though the paperwork presumably goes to TSA
headquarters. Why can't TSA look at that one application that has been
approved and take me off their "watch list," or whatever they call it? Is
"logic" not in government dictionaries?

Things have become so ridiculous on the road that a TSA screener in Duluth,
Minn., last week required me to open my computer bag, whereupon she used
one of those devices that resemble a deodorant pad and wiped every
electrical cord. When I asked why, she responded, "The downed Russian
airliners." When I noted that Duluth was the only airport in the country
where my electrical cords had been wiped, she replied, "Everyone is
supposed to."

The arbitrariness of all of this makes me think the "security" system isn't
very secure and that it is all a sham created by politicians to fool the
public into believing they are protecting us. Meanwhile, millions cross our
borders illegally, including untold numbers from countries that hate us.

Why isn't the Bush administration doing something about illegal immigration
instead of pretending these people are coming here solely to do manual
labor we native Americans don't want to do? Wouldn't we be safer if we
prevented those who wish us harm from getting into the country?

Thanks to Transportation Secretary Norman Mineta's misguided policy of
refusing to profile travelers, we get equal opportunity inconvenience and
stupidity. Imagine if cops were prohibited from describing gender, race or
other physical characteristics when broadcasting an all-points bulletin for
a suspect.

My profile is radically different from all those who killed nearly 3,000 of
my countrymen on September 11, 2001. My "holy book" of choice is the Bible.
My race is Caucasian. I am a loyal, taxpaying, patriotic, evil-hating,
English-as-first-language, natural-born American. If profiling were
allowed, I wouldn't be the one filling out government forms to prove I'm
not a terrorist. The other guys would.

This is an outrage! The form will soon be in the mail. They'll probably
send me a note assuring me of a prompt reply, before misplacing the
application. Senator Kennedy, can you help?


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Mon Oct 18 15:49:27 2004
From: hal at finney.org (Hal Finney)
Date: Mon, 18 Oct 2004 12:49:27 -0700 (PDT)
Subject: Crypto blogs?
Message-ID: <20041018194927.058CC57E2A@finney.org>

Does anyone have pointers to crypto related weblogs?  Bruce Schneier
recently announced that Crypto-Gram would be coming out incrementally
in blog form at http://www.schneier.com/blog/.  I follow Ian Grigg's
Financial Cryptography blog, http://www.financialcryptography.com/.
Recently I learned about Adam Shostack's http://www.emergentchaos.com/,
although it seems to be more security than crypto.

Any other good ones?

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Oct 18 20:23:28 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Mon, 18 Oct 2004 20:23:28 -0400
Subject: Printers betray document secrets
Message-ID: <p061104d3bd9a08e62dca@[66.149.49.5]>

<http://news.bbc.co.uk/2/low/technology/3753886.stm>

The BBC

 |  Entertainment  |  Have Your Say  | In Pictures  |  Week at a Glance
Monday, 18 October, 2004, 16:58 GMT 17:58 UK

 Printers betray document secrets That staple of crime novels - solving a
case by identifying the typewriter used to write a ransom note - is being
updated for the modern day.

 US scientists have discovered that every desktop printer has a signature
style that it invisibly leaves on all the documents it produces.

 They have now found a way to use this to identify individual laser printers.

 The work will help track down printers used to make bogus bank notes, fake
passports and other important papers.

 Spot colour

 Before now it was thought that the differences between cheap,
mass-produced desktop printers were not significant enough to make
individual identification possible.

 But a team from Purdue University in Indiana led by Professor Edward Delp
has developed techniques that make it possible to trace which printer was
used to produce which document.

 In 11 out of 12 tests, the team's methods identified which model of
desktop laser printer was used to print particular documents.

 "We also believe that we will be able to identify not only which model of
printer was used but specifically which printer was used," Professor Delp
said.

 The image processing software developed by Professor Delp's team looks for
the "intrinsic signatures" that each printer produces.

 Professor Jan Allebach, who helped develop the ID techniques, said the
production methods demanded by competition in the desktop printer market
meant there was quite a lot of variation in the way different machines
printed pages.

 "For a company to make printers all behave exactly the same way would
require tightening the manufacturing tolerances to the point where each
printer would be too expensive for consumers," he said.

 The differences emerge in the way that a laser printer lays down ink on
the paper and which can be spotted with the Purdue system.

 Inkjet is next

 Typically, different printers lay down ink in distinct bands that can be
spotted by image processing software.

 "We extract mathematical features, or measurements, from printed letters,
then we use image analysis and pattern-recognition techniques to identify
the printer," said Professor Delp.

 Desktop printers coupled with scanners have become favourites with forgers
as they produce high-quality copies of banknotes and personal documents
that can fool a casual glance.

 The team is now working to extend its techiques to cover inkjet printers.

 The team is also working on ways to manipulate printers so they lay down
ink with more easily identifiable signatures.

 The researchers will present their detailed findings at the International
Conference on Digital Printing Technologies in early November.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Tue Oct 19 16:14:50 2004
From: iang at systemics.com (Ian Grigg)
Date: Tue, 19 Oct 2004 21:14:50 +0100
Subject: Printers betray document secrets
In-Reply-To: <p061104d3bd9a08e62dca@[66.149.49.5]>
References: <p061104d3bd9a08e62dca@[66.149.49.5]>
Message-ID: <417575BA.8090205@systemics.com>



R.A. Hettinga wrote:
> <http://news.bbc.co.uk/2/low/technology/3753886.stm>

>  US scientists have discovered that every desktop printer has a signature
> style that it invisibly leaves on all the documents it produces.

I don't think this is new - I'm pretty sure it was
published about 6 or 7 years back as a technique.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Tue Oct 19 16:30:40 2004
From: iang at systemics.com (Ian Grigg)
Date: Tue, 19 Oct 2004 21:30:40 +0100
Subject: Financial identity is *dangerous*? (was re: Fake companies, real
 money)
In-Reply-To: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net>
Message-ID: <41757970.2090403@systemics.com>

Hi John,

John Kelsey wrote:

> Today, most of what I'm trying to defend myself from online is done as either a kind of hobby (most viruses), or as fairly low-end scams that probably net the criminals reasonable amounts of money, but probably don't make them rich.  Imagine a world where there are a few hundred million dollars in untraceable assets waiting to be stolen, but only on Windows XP boxes with the latest patches, firewalls and scanners installed, and reasonable security settings.  IMO, that's a world where every day is day zero.  All bugs are shallow, given enough qualified eyeballs, and with that kind of money on the table, there would be plenty of eyeballs looking.  

We are way way past that point in security,
phishing is happening on an industrial scale, and
the virus, phish and spam people are united, or
at least working together.  Internet payment
systems are being DDOS/extorted on a regular
basis, and hack attempts are routine.

We literally already have that world.

> And once it's done, several thousand early adopters are out thousands of dollars each.  This isn't much of an advertisement for the payment system.  It's anonymous and based on bearer instruments, so there's no way to run the fraudulent transactions back.  The money's gone, and the attackers are richer, and the next, more demanding round of attacks has been capitalized.  

Again, we're well past that point.  There have been
hundreds and hundreds of payment systems out there,
and maybe order of a thousand have failed by now,
mostly due to business reasons.  Some simply due
to hacks and attacks, but it is rare, because:

What happens is that beyond a certain threshold, the
payment system delivers valuable payments.  At that
point, it starts getting attacked.  If those attacks
are survived, then it moves on to the next phase.
Which would be more attacks of a different nature...

(In fact, one seems to have failed in the last few
days - EvoCash -  and another is on the watch list
for failure - DMT/Alta.  Both of them suffered from
business style attacks it seemed, rather than what
we would call security hacks.)

The notion that suddenly it's all over isn't what
happens.  It's a trickle, then it builds up to a
flood.  Some small hacks come in, and people either
look at them or they don't.  Those that are diligent
and keep an eye on these things respond.  Those that
don't go out of business.  There are more dead
payment systems than people on this list, I'd guess,
we do have plenty of experience in this.

In practice, we've also seen what happens when
money that gets stolen can't be traced or stopped.
Even though not "bearer", systems like e-gold are
plenty anon enough, and they don't easily reverse.
I doubt bearer systems would necessarily face a
problem because of users losing their bearer tokens
(but there are plenty of other problems out there
like the rather hard insider theft problem).

> They also have to be able to do something about it.  What would you tell a reasonably bright computer programmer with no particular expertise in security about how to keep a bearer asset as valuable as his car stored securely on a networked computer?  If you can't give him an answer that will really work in a world where these bearer assets are  common, you're just not going to get a widespread bearer payment system working, for the same reason that there's probably nobody jogging with an iPod through random the streets of Sadr City, no matter how careful they're being.

When we get to that point, we will have an answer
for him.  I can assert that with a fair degree of
confidence, because a) we can't ever get to that
point until we have an answer, and b) 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.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Tue Oct 19 17:10:50 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Tue, 19 Oct 2004 15:10:50 -0600
Subject: New IBM Thinkpad includes biometrics
In-Reply-To: <20041014020959.D5FCCB4082@mail.okiok.com>
References: <20041014020959.D5FCCB4082@mail.okiok.com>
Message-ID: <1098220250.3501.87.camel@lhwlinux>

On Wed, 2004-10-13 at 20:10, Anton Stiglic wrote:
> http://www.theregister.co.uk/2004/10/05/biometric_thinkpad_t42/
> 
> I wonder how well it can counter the attacks discussed by researchers in the
> last few years.  Like reactivating a fingerprint authentication by breathing
> on the sensor's surface containing residue fat traces of the finger, or
> placing a bag of water.  Or the jelly finger trick.
> The biometric authentication might very well make the laptop less secure
> than password-based authentication.

one of the market targets of biometrics has been those that write their
password on their machine (or don't even bother with a password).

in the past, it seems that biometrics have tried to make a big thing of
how much more secure that it might be than passwords ... in part because
it was so much more expensive. 

however, "significantly more secure than passwords" ... doesn't
necessarily have to be the market target.

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Oct 19 16:52:45 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Tue, 19 Oct 2004 16:52:45 -0400
Subject: CFP 2005 PKI R&D Workshop - Deadline soon
Message-ID: <p06110439bd9b2f102223@[66.149.49.5]>


--- begin forwarded text


Date: Tue, 19 Oct 2004 03:18:16 -0700
To: SPKI Mailing List <spki at metzdowd.com>
From: Carl Ellison <cme at acm.org>
Subject: CFP 2005 PKI R&D Workshop - Deadline soon
Sender: owner-spki at metzdowd.com

4th Annual PKI R&D Workshop: Multiple Paths to Trust
April 19-21, 2005
NIST -- Gaithersburg, MD
Papers and Proposals Due: October 29, 2004

Website: http://middleware.internet2.edu/pki05/
Registration Fee: $125.00

This workshop considers the full range of public key technology used
for security decisions and supporting functionalities, including
authentication, authorization, identity (syndication, federation, and
aggregation), and trust.  This year, the workshop has a particular
interest in how PKI and emerging trust mechanisms will interact with
each other at technical, policy and user levels to support trust
models that lack a central authority.  This workshop has three goals:

1. Explore the current state of public key technology and
   emerging trust mechanisms in different domains including
   web services; grid technologies; authentication systems,
   et al., in academia, research, government, and industry.

2. Share & discuss lessons learned and scenarios from vendors
   and practitioners on current deployments.

3. Provide a forum for leading security researchers to explore
   the issues relevant to PKI space in areas of security
   management, identity, trust, policy, authentication, and
   authorization.

CALL FOR PAPERS

We solicit papers, case studies, panel proposals, and participation
from researchers, systems architects, vendor engineers, and users.
Submitted works should address one or more critical areas of inquiry.

Topics include (but are not limited to):

* Federated versus Non-Federated trust models
* Standards related to PKI and security decision systems such as
  x509, SDSI/SPKI, PGP, XKMS, XACML, XRML, XML signature, and SAML.
* Cryptographic and alternative methods for supporting security
  decisions, including the characterization and encoding of data
* Intersection of policy based systems and PKI
* Privacy protection and implications
* Scalability of security systems
* Security of the components of PKI systems
* Security Infrastructures for constrained environments
* Improved human factor designs for security-related interfaces
  including authorization and policy management, naming, use of
  multiple private keys, and selective disclosure
* New paradigms in PKI architectures
* Reports of real-world experience with the use and deployment of
  PKI, including future research directions

Deadlines for conference paper and panel submissions are:

* Papers and Proposals Due: October 29, 2004
* Authors Notified:         December 10, 2004
* Final Materials Due:      February 18, 2005

Submissions should be provided electronically, in PDF, for standard
US letter-size paper (8.5 x 11 inches). Paper submissions must not
exceed 15 pages (single space, two column format with 1" margins
using a 10 pt or larger font) and have no header or footer text
(e.g., no page numbers). Proposals for panels should be no longer
than five pages and include possible panelists and an indication of
which panelists have confirmed availability.

Please submit the following information to pkichairs at internet2.edu:

* Name, affiliation, email, phone, postal address for the primary
  contact author
* First name, last name, and affiliation of each co-author
* The finished paper in PDF format as an attachment

All submissions will be acknowledged.

Submissions of papers must not substantially duplicate work that any
of the authors have published elsewhere or have submitted in parallel
to any other conferences or journals.

Accepted papers will be published in a proceedings of the workshop.

REGISTRATION

The registration fee of $125 per person includes workshop materials,
coffee breaks, lunches, and a dinner.  There will be no on-site
registration. Please pre-register by April 12, 2005 at

 https://rproxy.nist.gov/CRS/conf_ext.cfm?conf_id=1065

Teresa Vicente
NIST
Phone: (301) 975-3883
Fax: (301) 948-2067
email: teresa.vicente at nist.gov

An agenda will be available in late December at
http://middleware.internet2.edu/pki05/

ACCOMMODATIONS

A block of rooms has been reserved at the Gaithersburg Holiday Inn,
(301) 948-8900, at a special rate of $99, single or double, plus 12%
tax. Reservations must be received by April 4, 2005, in order to
receive the special rate.  Please mention you are attending the
"NIST/PKI Workshop".




+------------------------------------------------------------------+
|Carl M. Ellison         cme at acm.org      http://theworld.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+
--------------------------------------------------------------------- The
SPKI Mailing List Unsubscribe by sending "unsubscribe spki" to
majordomo at metzdowd.com

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Tue Oct 19 20:24:02 2004
From: adam at homeport.org (Adam Shostack)
Date: Tue, 19 Oct 2004 20:24:02 -0400
Subject: Crypto blogs?
In-Reply-To: <20041018194927.058CC57E2A@finney.org>
References: <20041018194927.058CC57E2A@finney.org>
Message-ID: <20041020002401.GA69707@lightship.internal.homeport.org>

On Mon, Oct 18, 2004 at 12:49:27PM -0700, "Hal Finney" wrote:
| Does anyone have pointers to crypto related weblogs?  Bruce Schneier
| recently announced that Crypto-Gram would be coming out incrementally
| in blog form at http://www.schneier.com/blog/.  I follow Ian Grigg's
| Financial Cryptography blog, http://www.financialcryptography.com/.
| Recently I learned about Adam Shostack's http://www.emergentchaos.com/,
| although it seems to be more security than crypto.

Thanks Hal!

I try to focus on economics more than other things*, and as Eric
always pointed out, all crypto is economics.   QED, I'm right on. ;)


Adam

* "no one pays me, so you can't complain when I fail." ;)

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From measl at mfn.org  Wed Oct 20 03:58:21 2004
From: measl at mfn.org (J.A. Terranson)
Date: Wed, 20 Oct 2004 02:58:21 -0500 (CDT)
Subject: New IBM Thinkpad includes biometrics
In-Reply-To: <20041014020959.D5FCCB4082@mail.okiok.com>
References: <20041014020959.D5FCCB4082@mail.okiok.com>
Message-ID: <20041020025715.D12015@ubzr.zsa.bet>


On Wed, 13 Oct 2004, Anton Stiglic wrote:

> http://www.theregister.co.uk/2004/10/05/biometric_thinkpad_t42/
>
> I wonder how well it can counter the attacks discussed by researchers in the
> last few years.  Like reactivating a fingerprint authentication by breathing
> on the sensor's surface containing residue fat traces of the finger, or
> placing a bag of water.  Or the jelly finger trick.
> The biometric authentication might very well make the laptop less secure
> than password-based authentication.
>
> --Anton

The company I'm currently associated with (United Forensics) is currently
working on this very question - I'll let everyone know when we have an
answer.

-- 
Yours,

J.A. Terranson
sysadmin at mfn.org
0xBD4A95BF

	"An ill wind is stalking
	while evil stars whir
	and all the gold apples
	go bad to the core"

	S. Plath, Temper of Time

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct 20 07:59:37 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Wed, 20 Oct 2004 07:59:37 -0400
Subject: [ISN] 2-Fingerprint Border ID System Called Inadequate
Message-ID: <p0611040abd9c0399f303@[66.149.49.5]>


--- begin forwarded text


Date: Tue, 19 Oct 2004 21:40:22 -0500 (CDT)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] 2-Fingerprint Border ID System Called Inadequate
Reply-To: isn at c4i.org
List-Id: InfoSec News <isn.attrition.org>
List-Archive: <http://www.attrition.org/pipermail/isn>
List-Post: <mailto:isn at attrition.org>
List-Help: <mailto:isn-request at attrition.org?subject=help>
List-Subscribe: <http://www.attrition.org/mailman/listinfo/isn>,
	<mailto:isn-request at attrition.org?subject=subscribe>
Sender: isn-bounces at attrition.org

http://www.washingtonpost.com/wp-dyn/articles/A43276-2004Oct18.html

By Robert O'Harrow and Jr. Scott Higham
Washington Post Staff Writers
October 19, 2004

Terrorists who alter their fingerprints have about an even chance of
slipping past U.S. border watch-list checks because the government is
using a two-fingerprint system instead of one that relies on all 10
prints, a lawmaker said in a letter he made public yesterday to
Homeland Security Secretary Tom Ridge.

Rep. Jim Turner (D-Tex.) wrote that a study by researchers at Stanford
University concluded the two-finger system "is no more than 53 percent
effective in matching fingerprints with poor image quality against the
government's biometric terrorist watch-list." Turner said the system
falls far short of keeping the country secure.

"It's going to be a coin toss as to whether we can identify
terrorists," Turner, the ranking member of the House Select Committee
on Homeland Security, said in an interview yesterday. "It's a 50-50
chance, and that's not good enough."

Turner's Oct. 15 letter comes as government officials supervising the
burgeoning border security system, known as US-VISIT, have been
touting their use of fingerprints for identifying people crossing the
border and checking them against watch lists of suspected terrorists.

The US-VISIT program aims to create a "virtual border" using computer
networks, databases, fingerprints and other biometric identifiers. The
program requires foreign visitors to register their names before
traveling to the United States and have their fingerprints checked
when they arrive and depart. Officials estimate the system could cost
up to $10 billion and take a decade to build.

The border security program is relying on technology first developed
for a program at the former Immigration and Naturalization Service
called IDENT. Government officials have known for years that IDENT did
not work well with the identification system used by the Justice
Department, a 10-fingerprint system called the Integrated Automated
Fingerprint Identification System. That system is known for producing
good results, even with poor-quality fingerprint images, Turner's
letter said.

But homeland security officials have told Congress they decided to use
the IDENT system for the first phase of US-VISIT as a way to quickly
improve security at the borders, and move to a 10-fingerprint system
later. "It was a logistical issue we had to deal with," said Robert A.
Mocny, deputy director of US-VISIT. "It will get better. . . . It's a
matter of what we can do right now."

Turner's letter said the Department of Homeland Security ignored
numerous warnings from the "government's top biometric scientists"
that the "two-fingerprint system could not accurately perform watch
list searches and the ten-fingerprint system was far preferable."

The letter quotes Stanford researcher Lawrence M. Wein, who said his
study found that at best, with a software fix, the two-finger system
would properly identify only about three of four people. Two weeks
ago, Wein told the Homeland Security Committee that the "implications
of our findings are disturbing."

Turner accused homeland security officials of failing to be "more
forthcoming" about the limitations of their approach. Turner asked
Ridge to direct homeland security officials to "preserve all documents
and electronic communications" relating to their decision on
fingerprints.

"I understand your desire to deploy biometric screening at our borders
as quickly as possible," Turner said in his letter. "But more than
three years after the 9/11 attacks, we have invested more than $700
million in an entry-exit system that cannot reliably do what the
Department so often said it would: Use a biometric watch-list to keep
known terrorists out of the country."

A spokesman for the Republican-controlled Homeland Security Committee,
Ken Johnson, said the release of Turner's letter was driven by
election-year politics. Johnson acknowledged that there are "some
concerns" with the current system, but he said US-VISIT continues to
evolve. "In a perfect world, where money is not an issue, and people
wouldn't mind spending countless hours or days at the border, the
10-fingerprint system would be preferable. But that's not reality,"
Johnson said. "They're playing politics with some very sensitive
issues."




_________________________________________
Open Source Vulnerability Database (OSVDB) Everything is Vulnerable -
http://www.osvdb.org/

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct 20 08:00:23 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Wed, 20 Oct 2004 08:00:23 -0400
Subject: [ISN] Worldwide Phishing Attacks May Stem from Few Sources
Message-ID: <p0611040bbd9c03c3fcf4@[66.149.49.5]>


--- begin forwarded text


Date: Wed, 20 Oct 2004 01:41:32 -0500 (CDT)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] Worldwide Phishing Attacks May Stem from Few Sources
Reply-To: isn at c4i.org
List-Id: InfoSec News <isn.attrition.org>
List-Archive: <http://www.attrition.org/pipermail/isn>
List-Post: <mailto:isn at attrition.org>
List-Help: <mailto:isn-request at attrition.org?subject=help>
List-Subscribe: <http://www.attrition.org/mailman/listinfo/isn>,
	<mailto:isn-request at attrition.org?subject=subscribe>
Sender: isn-bounces at attrition.org

http://www.eweek.com/article2/0,1759,1679953,00.asp

By Dennis Fisher
October 19, 2004

Research from an e-mail security provider suggests that a handful of
people are responsible for the vast majority of the phishing attacks
on the Internet and the perpetrators are using a rotating series of
zombie networks to launch them.

Researchers at CipherTrust Inc. analyzed more than four million
e-mails collected from the company's customers during the first two
weeks of October and found that nearly a third of all of the zombie
machines sending the phishing messages are based in the United States.
That's twice as many as the 16 percent that are found in South Korea.

However, these findings do not mean that these attacks are originating
from inside these countries. The global nature of the Internet allows
attackers anywhere in the world to compromise machines in any
location. In fact, many experts believe that the majority of phishers
are in some way connected to organized crime groups in Russia or
Eastern Europe and that most such attacks begin there.

The most surprising conclusion of the research is that the attackers
sending out the phishing messages are using zombie networks of only
about 1,000 PCs.

"That's a pretty small bot network for the volume of stuff that these
guys are doing," said Dmitri Alperovitch, the research engineer at
Atlanta-based CipherTrust Inc. who conducted the study. "But the trick
is that they rotate to a different set of compromised machines each
day. They don't keep going to the same ones each time."

Crackers for years have been accumulating large networks of machines
compromised with small programs that give them the ability to control
the PCs remotely. They routinely sell or trade access to the networks
to others in the cracker underground and the PCs typically are used
either for launching DDoS (distributed denial of service attacks).

But as authorities began cracking down on spammers in recent years,
the spammers have begun relying on these networks to send out their
messages, too. Now, phishers have gotten into the game.

Alperovitch said that there are fewer than five operators in control
of the zombie networks that he identified in his research. And, even
though they're generating thousands of fraudulent e-mails every day,
their output was still a tiny fraction.less than one percent--of the
four million messages CipherTrust examined.

Phishers seem to be concentrating their efforts on a few high-profile
targets, as well. In the sample CipherTrust looked at, 54 percent of
the phishing messages used CitiGroup's Citibank name to entice
recipients. Another 13 percent use Citigroup Global Markets Inc.'s
Smith Barney's brand and eBay Inc. is the victim in about four percent
of the scams.



_________________________________________
Open Source Vulnerability Database (OSVDB) Everything is Vulnerable -
http://www.osvdb.org/

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From smb at research.att.com  Wed Oct 20 10:54:49 2004
From: smb at research.att.com (Steve Bellovin)
Date: Wed, 20 Oct 2004 10:54:49 -0400
Subject: lack of WW II cryptanalytic co-operation between the US and UK?
Message-ID: <20041020145449.5AA511AEB0@berkshire.research.att.com>

Some recently declassified British documents show that the British
and the Americans did not co-operate as closely on cryptanalytic
matters as is generally thought.  See 
http://news.bbc.co.uk/2/hi/uk_news/3758276.stm for details.

I'd really like to see the full text of Turing's report; does anyone
know if it's online?

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jamesd at echeque.com  Wed Oct 20 14:30:10 2004
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 20 Oct 2004 11:30:10 -0700
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <41757970.2090403@systemics.com>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net>
Message-ID: <41764C42.24691.43BECA@localhost>

    --
On 19 Oct 2004 at 21:30, Ian Grigg wrote:
> (In fact, one seems to have failed in the last few days - 
> EvoCash -  and another is on the watch list for failure - 
> DMT/Alta.  Both of them suffered from business style attacks 
> it seemed, rather than what we would call security hacks.)

To clarify, EvoCash was subjected to DDoS attacks, and 
persistent attack upon its reputation, both of these seemingly 
originating from the operator of a ponzi scheme, presumably for 
the purposes of extortion.

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

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     hrZ6lTrAZYICXnGqF8vLx7tZ1wcjKkoF7d/jKJbF
     4WFPME/Dy9Losvs1g9ZsxwxI0oIYThq0dwJCNpLX9



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Thu Oct 21 01:44:58 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Wed, 20 Oct 2004 22:44:58 -0700
Subject: Printers betray document secrets
In-Reply-To: <p061104d3bd9a08e62dca@[66.149.49.5]>
References: <p061104d3bd9a08e62dca@[66.149.49.5]>
Message-ID: <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com>

At 05:23 PM 10/18/2004, R.A. Hettinga wrote:
>  <http://news.bbc.co.uk/2/low/technology/3753886.stm>

It turns out that their techniques aren't all that useful.
Changing laser printer cartridges changes the results.
You might find that two documents were printed
by the same printer, but it doesn't give you the
options for tracking it down that manual typewriters did.
And the differences don't identify a specific printer
in a way that can be tracked, e.g. identifying a serial number
that could be looked up from warranty records.

It's not clear that they work at all with inkjet printers,
and changing ink cartridges is even more common than
changing laser printer cartridges.  If you're sloppy,
you've probably got a bunch of partly-used cartridges around,
so even if you want to print out a bunch of ransom notes
or whatever, you don't even have to go to Kinko's
to get them to be different.

If printer makers want to build in watermarking to
make everything they print traceable, the way many of them
check for documents that look like money and don't print them,
they could hide patterns that survive cartridge changes
(would you notice a few inverted pixels on a 600x600dpi printout?)
But even then, inkjet printers are dirt cheap;
when they're on sale, they're essentially a free enclosure
in a box of overpriced printer cartridges,
so even of the printer wants to rat out the user and
it's not easy to change the serial number PROM,
you can just replace the printer.

----
Bill Stewart  bill.stewart at pobox.com 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From marshall at idio.com  Thu Oct 21 12:16:07 2004
From: marshall at idio.com (Marshall Clow)
Date: Thu, 21 Oct 2004 09:16:07 -0700
Subject: Printers betray document secrets
In-Reply-To: <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com>
References: <p061104d3bd9a08e62dca@[66.149.49.5]>
 <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com>
Message-ID: <p0620053abd9d90eb0302@[129.46.153.119]>

At 10:44 PM -0700 10/20/04, Bill Stewart wrote:
>At 05:23 PM 10/18/2004, R.A. Hettinga wrote:
>>  <http://news.bbc.co.uk/2/low/technology/3753886.stm>
>
>It's not clear that they work at all with inkjet printers,
>and changing ink cartridges is even more common than
>changing laser printer cartridges.  If you're sloppy,
>you've probably got a bunch of partly-used cartridges around,
>so even if you want to print out a bunch of ransom notes
>or whatever, you don't even have to go to Kinko's
>to get them to be different.

If you're really concerned about this, buy a cheap inkjet,
use it for your purposes, then destroy it.
--
-- Marshall

Marshall Clow     Idio Software   <mailto:marshall at idio.com>

It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From perry at piermont.com  Thu Oct 21 12:03:37 2004
From: perry at piermont.com (Perry E. Metzger)
Date: Thu, 21 Oct 2004 12:03:37 -0400
Subject: Article on Echelon on Techworld...
Message-ID: <87y8i0njmu.fsf@snark.piermont.com>


I saw this on /.:

http://www.techworld.com/storage/news/index.cfm?NewsID=2430

-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Thu Oct 21 12:20:24 2004
From: iang at systemics.com (Ian Grigg)
Date: Thu, 21 Oct 2004 17:20:24 +0100
Subject: Financial identity is *dangerous*? (was re: Fake companies, real
 money)
In-Reply-To: <41764C42.24691.43BECA@localhost>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net> <41764C42.24691.43BECA@localhost>
Message-ID: <4177E1C8.8030807@systemics.com>

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rsalz at datapower.com  Thu Oct 21 12:27:50 2004
From: rsalz at datapower.com (Rich Salz)
Date: Thu, 21 Oct 2004 12:27:50 -0400 (EDT)
Subject: Printers betray document secrets
In-Reply-To: <417575BA.8090205@systemics.com>
Message-ID: <Pine.LNX.4.44L0.0410211225360.12138-100000@smtp.datapower.com>

> >  US scientists have discovered that every desktop printer has a signature
> > style that it invisibly leaves on all the documents it produces.
>
> I don't think this is new - I'm pretty sure it was
> published about 6 or 7 years back as a technique.

A couple of years ago, I was told that *every* Canon laser engine
generated a unique microprint signature that could be traced back to a
particular device.  OEMs could buy the engine with or without the
signature.  If so, this has been going on, surruptitiously, for years.
	/r$

--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jerrold.leichter at smarts.com  Thu Oct 21 14:09:19 2004
From: jerrold.leichter at smarts.com (Jerrold Leichter)
Date: Thu, 21 Oct 2004 14:09:19 -0400 (EDT)
Subject: Printers betray document secrets
In-Reply-To: <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com>
References: <p061104d3bd9a08e62dca@[66.149.49.5]> <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com>
Message-ID: <Pine.GSO.4.58.0410211350270.8938@frame>

| It turns out that their techniques aren't all that useful.
| Changing laser printer cartridges changes the results.
| You might find that two documents were printed
| by the same printer, but it doesn't give you the
| options for tracking it down that manual typewriters did.
Actually, they say they can identify the make and model - which is about all
you could do with a typewriter.  Going further, in either case, means tying a
particular piece of text to a particular writing instrument to which you have
gained access.

Changing printer cartridges will certainly work, but then again simply replac-
ing the typewriter will, too.  Any identification of physical objects can only
work as long as the physical object isn't replaced.  In practice, there's a
great deal of inertia in replacing physical objects, for cost, convenience, and
other reasons.  So such identifications may still be useful.

| And the differences don't identify a specific printer
| in a way that can be tracked, e.g. identifying a serial number
| that could be looked up from warranty records.
A bullet can't be tied to a gun's serial number, but that doesn't make it
useless to examine bullets.

| It's not clear that they work at all with inkjet printers,
| and changing ink cartridges is even more common than
| changing laser printer cartridges.
The technique is based on variations in dot pattern that ultimately come down
to small variations in mechanical parts, usually the gears that drive the
paper.  Laser printer cartridges are deliberately designed so that (just
about) all moving/wearing parts are part of the cartridge.  So most variations
in the results are necessarily tied to the cartridge.  That's not true for ink
jets. While the paper describing all this isn't yet available, from what is
published I don't think they are making any claims about inkjets, just laser
printers. However, they seem to believe the same general approach - look for
variations due to variations in manufacture that don't produce artifacts that
are visible to the naked eye, so don't need to be and hence are not controlled
- would work.  Whether the source of the variation would be in the ink
cartridge or in the fixed mechanicals, who can say at this point.

|				      If you're sloppy,
| you've probably got a bunch of partly-used cartridges around,
| so even if you want to print out a bunch of ransom notes
| or whatever, you don't even have to go to Kinko's
| to get them to be different.
|
| If printer makers want to build in watermarking to
| make everything they print traceable, the way many of them
| check for documents that look like money and don't print them,
| they could hide patterns that survive cartridge changes
| (would you notice a few inverted pixels on a 600x600dpi printout?)
Actually, this would probably be noticable in certain pictures.  But slight
variations in pixel spacing - which is what these guys look for - is not
visible.  (In fact, the origin of this work seems to have been work in the
opposite direction:  Early laser printers had a problem with banding, due to
periodic variations in paper movement causing variations in pixel spacing.
The trick was to find out how much variation you could allow without visible
artifacts and then get to that level cheaply.  But there is still plenty of
variation left for appropriate software to find.)  You could probably play
games with pixel sizes, too.

| But even then, inkjet printers are dirt cheap;
| when they're on sale, they're essentially a free enclosure
| in a box of overpriced printer cartridges,
| so even of the printer wants to rat out the user and
| it's not easy to change the serial number PROM,
| you can just replace the printer.
One could say the same about most physical objects that end up being used
for identification.  You would think that fibers would be useless for
identification, for example - you can always throw out the clothing you were
wearing and buy a new tee shirt.  Still ... the real world has a great deal
of inertia.
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From hal at finney.org  Thu Oct 21 15:21:49 2004
From: hal at finney.org (Hal Finney)
Date: Thu, 21 Oct 2004 12:21:49 -0700 (PDT)
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
Message-ID: <20041021192149.10FCE57E2C@finney.org>

James Donald writes:
> On 19 Oct 2004 at 21:30, Ian Grigg 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? 

I would suggest pursuing work along the lines of a Virtual Machine Monitor
(VMM) like VMWare.  This way you can run a legacy OS, even Windows,
alongside a high security simplified OS which handles your transactions.
You run your regular buggy OS as usual, then hit a function key to
switch into secure mode, which enables access to your financial data.
The VMM does introduces some performance overhead but for typical web
browsing and email tasks it will not be significant.

This seems more promising than waiting for Windows to become secure,
or for everyone to switch to Linux.  I believe there are a number of
academic projects along these lines, for example the Terra project,
http://www.stanford.edu/~talg/papers/SOSP03/abstract.html , which uses
a hardware security chip to try to protect one VM's data from another.
I don't know if the extra complexity buys you much in this application
though.

Hal Finney

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Oct 21 18:59:46 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Thu, 21 Oct 2004 18:59:46 -0400
Subject: Are new passports [an] identity-theft risk?
Message-ID: <p06110406bd9defa94996@[66.149.49.5]>

<http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030>

WorldNetDaily

Thursday, October 21, 2004

YOUR PAPERS, PLEASE ?
Are new passports
 identity-theft risk?
Privacy advocates warn data chips can be 'seen' by anyone with reader
Posted: October 21, 2004
5:00 p.m. Eastern


 While the U.S. State Department prepares to switch over to passports that
include embedded data chips, privacy experts worry the new technology will
open Americans to identity theft and fraud.

 New passports will be fitted with chips using RFID, or radio frequency
identification, technology. Reader devices at borders and customs
checkpoints will be able to read the information stored on the chip,
including the person's name, address and digital photo.

 Kelly Shannon is a spokesperson for the State Department.

 She told Wired News: "The reason we are doing this is that it simply makes
passports more secure. It's yet another layer beyond the security features
we currently use to ensure the bearer is the person who was issued the
passport originally."

 RFID technology has been used for tracking everything from store inventory
to family members visiting an amusement park. It is also used in the
Digital Angel human implant that recently was approved by the FDA for
storing medical information.

 Wired reports civil libertarians and some technologists say the passport
chips are actually a boon to identity thieves, stalkers and commercial data
collectors, since anyone with the proper reader can download a person's
biographical information and photo from several feet away.

 "Even if they wanted to store this info in a chip, why have a chip that
can be read remotely?" Barry Steinhardt, who directs the American Civil
Liberty Union's Technology and Liberty program, asked Wired. "Why not
require the passport be brought in contact with a reader so that the
passport holder would know it had been captured? Americans in the know will
be wrapping their passports in aluminum foil."

 Last week, the government contracted with four companies to develop the
chips and readers for the program. The report stated diplomats and State
Department employees will be issued the new passports as early as January,
while others applying for new passports will receive the new version
starting in the spring.

 Electronic Frontier Foundation attorney Lee Tien told Wired RFID chips in
passports are a "privacy horror" and would be even if the data were
encrypted, which it isn't.

 "If 180 countries have access to the technology for reading this thing,
whether or not it is encrypted, from a security standpoint, that is a very
leaky system," Tien said. "Strictly from a technology standpoint, any
reader system, even with security, that was so widely deployed and
accessible to so many people worldwide will be subject to some very
interesting compromises."

 An engineer and RFID expert with Intel claims there is little danger of
unauthorized people reading the new passports. Roy Want told the newssite:
"It is actually quite hard to read RFID at a distance," saying a person's
keys, bag and body interfere with the radio waves.


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Fri Oct 22 00:23:07 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Fri, 22 Oct 2004 17:23:07 +1300
Subject: New IBM Thinkpad includes biometrics
In-Reply-To: <1098220250.3501.87.camel@lhwlinux>
Message-ID: <E1CKqxH-0006jy-00@medusa01>

Anne & Lynn Wheeler <lynn at garlic.com> writes:

>one of the market targets of biometrics has been those that write their
>password on their machine (or don't even bother with a password).

Even that may not be a valid market target.  If your threat model is script
kiddies/hackers in eastern Europe (that is, generic un-targeted attacks, the
most common type) then writing your password on a post-it note is a perfectly
acceptable response, because the one thing a script kiddie can't do is get
physical access to your desk.  So the primary market for biometrics would
really be people for whom passwords are too much effort (as the former US
biometrics czar said, they're for convenience, not security).

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Fri Oct 22 06:45:59 2004
From: iang at systemics.com (Ian Grigg)
Date: Fri, 22 Oct 2004 11:45:59 +0100
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <p06110406bd9defa94996@[66.149.49.5]>
References: <p06110406bd9defa94996@[66.149.49.5]>
Message-ID: <4178E4E7.70007@systemics.com>



R.A. Hettinga wrote:
> <http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030>

>  An engineer and RFID expert with Intel claims there is little danger of
> unauthorized people reading the new passports. Roy Want told the newssite:
> "It is actually quite hard to read RFID at a distance," saying a person's
> keys, bag and body interfere with the radio waves.

Who was it that pointed out that radio waves don't
interfere, rather, receivers can't discriminate?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From perry at piermont.com  Fri Oct 22 08:40:27 2004
From: perry at piermont.com (Perry E. Metzger)
Date: Fri, 22 Oct 2004 08:40:27 -0400
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <4178E4E7.70007@systemics.com> (Ian Grigg's message of "Fri, 22
 Oct 2004 11:45:59 +0100")
References: <p06110406bd9defa94996@[66.149.49.5]>
	<4178E4E7.70007@systemics.com>
Message-ID: <87ekjr3ozo.fsf@snark.piermont.com>


Ian Grigg <iang at systemics.com> writes:
> R.A. Hettinga wrote:
>> <http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030>
>>  An engineer and RFID expert with Intel claims there is little danger of
>> unauthorized people reading the new passports. Roy Want told the newssite:
>> "It is actually quite hard to read RFID at a distance," saying a person's
>> keys, bag and body interfere with the radio waves.
>
> Who was it that pointed out that radio waves don't
> interfere, rather, receivers can't discriminate?

I don't know who *else* has said it, but I've said this repeatedly at
conferences. With phased arrays, you should be able to read RFID tags
at surprising distances, and in spite of attempts to jam such signals
(such as RSA's proposed RFID privacy mechanism).

This isn't terribly surprising but for the fact that most people don't
think in terms of the fact that you can spatially discriminate radio
sources.

Perry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jerrold.leichter at smarts.com  Fri Oct 22 10:24:04 2004
From: jerrold.leichter at smarts.com (Jerrold Leichter)
Date: Fri, 22 Oct 2004 10:24:04 -0400 (EDT)
Subject: Microsoft Passport fades away
Message-ID: <Pine.GSO.4.58.0410221016350.14773@frame>

>From Computerworld:

	Microsoft Scales Back Passport Ambitions

	Microsoft's decision to reposition its .Net Passport identification
	system comes as Monster.com is dropping support for the authentication
	service.

	http://www.computerworld.com/newsletter/0,4902,96838,00.html?nlid=PM


							-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From WWhyte at ntru.com  Fri Oct 22 11:01:16 2004
From: WWhyte at ntru.com (Whyte, William)
Date: Fri, 22 Oct 2004 11:01:16 -0400
Subject: Are new passports [an] identity-theft risk?
Message-ID: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com>


> R.A. Hettinga wrote:
> > 
> <http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030>
> 
> >  An engineer and RFID expert with Intel claims there is 
> little danger of
> > unauthorized people reading the new passports. Roy Want 
> told the newssite:
> > "It is actually quite hard to read RFID at a distance," 
> saying a person's
> > keys, bag and body interfere with the radio waves.
> 
> Who was it that pointed out that radio waves don't
> interfere, rather, receivers can't discriminate?

Absolutely. I'd add that while it's *currently* hard to
read at a distance, passports typically have a lifetime
of 10 years and I'd be very surprised if the technology
wasn't significantly better five years out.

William

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dan at geer.org  Fri Oct 22 12:27:51 2004
From: dan at geer.org (dan at geer.org)
Date: Fri, 22 Oct 2004 12:27:51 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money) 
In-Reply-To: Your message of "Thu, 21 Oct 2004 12:21:49 PDT."
             <20041021192149.10FCE57E2C@finney.org> 
Message-ID: <20041022162751.7084D1BF96B@absinthe.tinho.net>


|  > What machine, attached to a network, using a web browser, and 
|  > sending and receiving mail, would you trust? 
|  
|  I would suggest pursuing work along the lines of a Virtual Machine Monitor
|  (VMM) like VMWare.  This way you can run a legacy OS, even Windows,
|  alongside a high security simplified OS which handles your transactions.

Hal,

I'm pretty sure that you are answering the question
"Why did Microsoft buy Connectix?"[1]  -- the answer
was not, in other words, to screw Mac OS X users
but to break the conundrum Ballmer finds himself
in where the road forks towards (1) fix the security
problem but lose backward compatibility, or (2) keep
the backward compatibility but never fix the problem.
His Board would prefer (2), the annuity of locked-in
users, but it forces a bet that software liability
never happens.  Fixing the problem, for which the
calls grow more strident daily, puts the desktop
platform into play even more than it is now as
it asks the users (who, having lost compatibility,
thus have nothing to lose) to marry Redmond a
second time.  A VM-cures-all strategy is then
an attempt to avoid having to choose between (1)
and (2) by breaking backward compatibility for
new things but bridging the old things with a
magic box that both preserves the annuity revenue
stream from locked-in users while it keeps the
liability bar at bay.

Or so I think.

--dan


[1] http://www.microsoft.com/windows/virtualpc/previous/default.mspx


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Fri Oct 22 17:46:04 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Fri, 22 Oct 2004 17:46:04 -0400
Subject: Patriot Act redux?
Message-ID: <p0611046dbd9f2fe33ba0@[66.149.49.5]>

<http://news.com.com/2102-1071_3-5414087.html?tag=st.util.print>



 Patriot Act redux?
 By Declan McCullagh
 http://news.com.com/Patriot+Act+redux/2010-1071_3-5414087.html

 Story last modified October 18, 2004, 4:00 AM PDT



With Election Day fast approaching, it was only a matter of time before the
usual congressional shenanigans that typically punctuate the political
season.

 This time, politicians appear to have seized on what could be called the
Patriot Act strategy, drafting antiterrorism legislation in secret and then
ramming it through the Senate and House of Representatives with minimal
debate. Then it's back to the home districts to boast how they protected
voters from the bad guys.

 The vehicles chosen for this strategy are two bills described as being
inspired by the 9/11 Commission's report, a politically potent text that's
become a best-selling book. The Senate and House have approved their own
versions of the legislation, and negotiators are now meeting privately to
decide on the final draft.

 Early indications are not promising. While portions of the massive
legislation are no doubt praiseworthy, other important sections--especially
those envisioning stuffing more information into government
databases--deserve special scrutiny from privacy hawks.

 Both the House and Senate bills coerce state governments into creating
what critics are calling a national ID card.
 Because the House version is nearly three times as long, its authors had
more room to promote private agendas.

 One section anticipates storing the "lifetime travel history of each
foreign national or United States citizen" into a database for the
convenience of government officials. It mentions passports, but there's
nothing that would preclude recording the details of trips that Americans
take inside the United States.

 President Bush would be required to create a "secure information sharing"
network to exchange data among law enforcement, military and spy agencies.
Aside from a bland assurance that "civil liberties" will be protected,
there are zero details on what databases will be vacuumed in or what
oversight will take place.

 A second network would be created by the first person to get the new job
of national intelligence director. That network must "provide immediate
access to information in databases of federal law enforcement agencies and
the intelligence community that is necessary to identify terrorists."

 It hardly needs to be said that snaring terrorists is what our government
should be doing. But it's not clear that the House bill is a step in the
right direction.

 Jim Dempsey, executive director of the Center for Democracy and
Technology, hopes that the aides negotiating the final bill end up adopting
the Senate language instead. It also would create an information-sharing
network--while requiring that Congress receive semiannual reports on how
the network is being used.

  "There are dozens if not hundreds of government programs under way to do
just that (already)," Dempsey warns. "They are fragmented; they are
overlapping. They are occurring outside of any framework of oversight."

 Still, the Senate bill is no prize. A last-minute amendment added by Sen.
John McCain, R-Ariz., would require the Department of Homeland Security to
create an "integrated screening system" inside the United States.

 McCain envisions erecting physical checkpoints, dubbed "screening points,"
near subways, airports, bus stations, train stations, federal buildings,
telephone companies, Internet hubs and any other "critical infrastructure"
facility deemed vulnerable to terrorist attacks. Secretary Tom Ridge would
appear to be authorized to issue new federal IDs--with biometric
identifiers--that Americans could be required to show at checkpoints.

 Both the House and Senate bills coerce state governments into creating
what critics are calling a national ID card. Under the proposals, federal
agencies will accept only licenses and state ID cards that comply with
specific to-be-established standards--a requirement that would affect
anyone who wants to get a U.S. passport, obtain Social Security benefits,
or even wander into a federal courthouse.

 That's why Jim Harper, director of information policy studies at the Cato
Institute, is no fan of either bill. "They say that if we just put
appropriate rules and restrictions in place, everything will be fine,"
Harper said. "But of course those rules and restrictions will drop away
over the years or if there are new terrorist attacks. They say, 'Of course
lion-taming is safe. They're our friends.' But then one day the lion grabs
you by the neck and drags you off the stage."

 A few other courageous Washingtonians have raised similar concerns. Rep.
Ron Paul, R-Texas, warned last week that the House bill "will not make
America safer (but will definitely) make us less free." And 25 former
senior officials from the FBI, CIA and military have sent a letter to
Congress indicating that the 9/11 Commission's recommendations are flawed
because the report whitewashed what went wrong on Sept. 11, 2001.

 Unfortunately, with only 15 days left before the election, politicians
will be tempted to place expedience over sober analysis of what's permitted
by the U.S. Constitution. That's what happened in October 2001 with the mad
scramble to enact the Patriot Act, and history is about to repeat itself.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jon at callas.org  Fri Oct 22 17:34:58 2004
From: jon at callas.org (Jon Callas)
Date: Fri, 22 Oct 2004 14:34:58 -0700
Subject: Crypto blogs?
In-Reply-To: <20041018194927.058CC57E2A@finney.org>
References: <20041018194927.058CC57E2A@finney.org>
Message-ID: <3902A1B6-2472-11D9-B29A-000A9568596C@callas.org>


On 18 Oct 2004, at 12:49 PM, Hal Finney wrote:

> Does anyone have pointers to crypto related weblogs?  Bruce Schneier
> recently announced that Crypto-Gram would be coming out incrementally
> in blog form at http://www.schneier.com/blog/.  I follow Ian Grigg's
> Financial Cryptography blog, http://www.financialcryptography.com/.
> Recently I learned about Adam Shostack's http://www.emergentchaos.com/,
> although it seems to be more security than crypto.
>
> Any other good ones?
>

Matt Hamrick's Cryptonomicon.net is good.

There are also my PGP CTO corner articles at 
<http://www.pgp.com/resources/ctocorner/>.

	Jon


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lists at whitehouse.org.nz  Sat Oct 23 01:58:26 2004
From: lists at whitehouse.org.nz (Aaron Whitehouse)
Date: Sat, 23 Oct 2004 18:58:26 +1300
Subject: Financial identity is *dangerous*? (was re: Fake companies, real
 money)
In-Reply-To: <4177E1C8.8030807@systemics.com>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net> <41764C42.24691.43BECA@localhost> <4177E1C8.8030807@systemics.com>
Message-ID: <4179F302.6020006@whitehouse.org.nz>



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


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Sat Oct 23 07:07:39 2004
From: iang at systemics.com (Ian Grigg)
Date: Sat, 23 Oct 2004 12:07:39 +0100
Subject: How to store the car-valued bearer bond?  (was Financial identity...)
In-Reply-To: <4179F302.6020006@whitehouse.org.nz>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net> <41764C42.24691.43BECA@localhost> <4177E1C8.8030807@systemics.com> <4179F302.6020006@whitehouse.org.nz>
Message-ID: <417A3B7B.2030403@systemics.com>



Aaron Whitehouse wrote:

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

Theoretically, there may not be much difference, depending
on where the theory starts...

Practically there are a bunch of differences, which are
more or less issues, depending.

1.  The data store (a.k.a. the smart card) is separated
from the IO package.  Is this an advantage or a disadvantage?
For the most part it gives the user 2 tokens to worry about,
the expense of an additional interface, and more mass, as you
point out.  I can't quite see any offsetting advantage myself
in all that over one box that does the lot.  So that's a minus.

2.  The data store is in some sense secure.  If it's got
a car-valued bearer bond on it, that's probably not
secure enough.  It might give some security in the event
of loss, but so would a combined package with some other
password on it.  It is a marginal security improvement
over a single purpose non-smart package, and thus would
have a primary benefit in marketing (see Blue).  It's a
plus, but a small plus, as a single-purpose package could
just build in a smart card if it so desired.

3.  The smart card interface is not good.  It has to be
taken out of your trusted reader and put in someone else's
trusted reader.  Bad news.  So someone else's trusted
reader tells you it is paying you dividends on your bond,
when in fact it is replacing the bond with a mickey mouse
loyalty coupon.  Getting around that disadvantage costs
systems operators a bundle of money and restrictions.
This makes for a huge minus.

4.  The smart card interface, part 2.  In practice, smart
card readers are an example of historical detritus.  We
all said "next year is the year of the smartcard" in 1995,
and it still is.  In practice, the interfaces we want on our
bearer bond hardware token are these:  802.11x, ethernet,
bluetooth, IR, ... in that approximate order, all with IP
layered over and our real hot bearer transfer protocol, and
not some hokey old telco thing.  The smart card interface is
another huge minus, because it means that the infrastructure
is all specialised, the protocols are all closed, and the
system is all controlled at some level or other, which means
some big fella has to dig deep in the pockets to finance it.

Score card so far:  2 big minuses, one small minus, and
a small plus.

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

Next year is the year of the smart card!  In practice,
that advantage is just a rationalisation.  We can't use
any of those tokens to store your bearer bond.  If we
are going to ask someone to store a bearer bond, we
have to give that person the token.  Which means we can
start with a blank sheet of paper, we don't need to use
any smart card patriotism to justify your choices.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Sat Oct 23 15:23:21 2004
From: adam at homeport.org (Adam Shostack)
Date: Sat, 23 Oct 2004 15:23:21 -0400
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com>
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com>
Message-ID: <20041023192321.GB64625@lightship.internal.homeport.org>

On Fri, Oct 22, 2004 at 11:01:16AM -0400, Whyte, William wrote:
| 
| > R.A. Hettinga wrote:
| > > 
| > <http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030>
| > 
| > >  An engineer and RFID expert with Intel claims there is 
| > little danger of
| > > unauthorized people reading the new passports. Roy Want 
| > told the newssite:
| > > "It is actually quite hard to read RFID at a distance," 
| > saying a person's
| > > keys, bag and body interfere with the radio waves.
| > 
| > Who was it that pointed out that radio waves don't
| > interfere, rather, receivers can't discriminate?
| 
| Absolutely. I'd add that while it's *currently* hard to
| read at a distance, passports typically have a lifetime
| of 10 years and I'd be very surprised if the technology
| wasn't significantly better five years out.

5 years?  I don't think we have that long.

The technology will mature *very* rapidly if Virginia makes their
driver's licenses RFID-enabled, or if the US goes ahead with the
passports.  Why?  Because there will be a stunning amount of money to
be stolen by not identity thieves, but real thieves.  Imagine sitting
with a laptop, a good antenna, and some software outside a metro
station in Virginia.  Or an upscale restaurant in Adams-Morgan,
reading off the addresses of those who will be away from home for the
next 3 hours.

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From apb at cequrux.com  Sat Oct 23 16:21:23 2004
From: apb at cequrux.com (Alan Barrett)
Date: Sat, 23 Oct 2004 22:21:23 +0200
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <4179F302.6020006@whitehouse.org.nz>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net> <41764C42.24691.43BECA@localhost> <4177E1C8.8030807@systemics.com> <4179F302.6020006@whitehouse.org.nz>
Message-ID: <20041023202123.GA1594@apb-laptoy.apb.alt.za>

On Sat, 23 Oct 2004, Aaron Whitehouse wrote:
> >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.
> 
> 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...

The risks of using *somebody else's keypad* to type passwords or
instructions to your smartcard, or using *somebody else's display* to
view output that is intended to be private, should be obvious.

--apb (Alan Barrett)

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Sat Oct 23 16:41:55 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Sat, 23 Oct 2004 22:41:55 +0200
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <4179F302.6020006@whitehouse.org.nz>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net> <41764C42.24691.43BECA@localhost> <4177E1C8.8030807@systemics.com> <4179F302.6020006@whitehouse.org.nz>
Message-ID: <20041023204155.GR1457@leitl.org>

On Sat, Oct 23, 2004 at 06:58:26PM +1300, Aaron Whitehouse wrote:

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

No, that's going to be the mobile phone. These already come with smartcards;
unfortunately their security is really lousy, so a secure pathway into the
secure crypto compartment for PIN entry is required.

In practice, no one is going to give a damn, until PIN-harvesting Bluetooth &
Co worms will result in palpable loss for the institutions.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041023/8596d16d/attachment.pgp>

From cato at df.lth.se  Sat Oct 23 18:52:33 2004
From: cato at df.lth.se (Krister Walfridsson)
Date: Sun, 24 Oct 2004 00:52:33 +0200 (CEST)
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <87ekjr3ozo.fsf@snark.piermont.com>
References: <p06110406bd9defa94996@[66.149.49.5]> <4178E4E7.70007@systemics.com>
 <87ekjr3ozo.fsf@snark.piermont.com>
Message-ID: <Pine.GSO.4.60.0410240050330.427@igloo.df.lth.se>


On Fri, 22 Oct 2004, Perry E. Metzger wrote:

> I don't know who *else* has said it, but I've said this repeatedly at
> conferences. With phased arrays, you should be able to read RFID tags
> at surprising distances, and in spite of attempts to jam such signals
> (such as RSA's proposed RFID privacy mechanism).

One thing that I have seen confuse people writing about the
new passports is that RFID may mean different technologies.  So
I'd like to mention that the passports will not use the simple
bar-code kind of RFID tags -- they will use chip cards
communicating over ISO/IEC 14443.

The current technology has big problems with working at a distance
(in fact, the tests done with COTS 14443 readers shows that most
have problems with reading passport-like cards even when placed at
the optimal distance...), but I don't know enough about antenna
technology to be able to guess what can be done by a dedicated
attacker...

    /Krister


PS.  Most of the MRTD (Machine Readable Travel Documents) specifications
are available at http://www.icao.int/mrtd/Home/index.cfm.

PPS. Most people on this list seems to be interested in the US
passport, so you may be interested in that the US department of
state, and department of homeland security, seems to be doing a
pilot of the new passport.  The RFP is available from:
   http://www.statewatch.org/news/2004/jul/us-biometric-passport-original.pdf
with some consolidated Q and A at
   http://www.statewatch.org/news/2004/jul/us-biometric-passport-QandA.pdf


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Sat Oct 23 22:13:38 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Sun, 24 Oct 2004 15:13:38 +1300
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <20041022162751.7084D1BF96B@absinthe.tinho.net>
Message-ID: <E1CLXt4-0000eI-00@medusa01>

dan at geer.org writes:

>I'm pretty sure that you are answering the question "Why did Microsoft buy
>Connectix?"

The answer to that one is actually "To provide a development environment for
Windows CE (and later XP Embedded)" (the emulator that's used for development
in those environments is VirtualPC).  Thank you for playing.

Peter.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From die at dieconsulting.com  Sun Oct 24 00:58:56 2004
From: die at dieconsulting.com (Dave Emery)
Date: Sun, 24 Oct 2004 00:58:56 -0400
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <20041023192321.GB64625@lightship.internal.homeport.org>
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com> <20041023192321.GB64625@lightship.internal.homeport.org>
Message-ID: <20041024045856.GB15539@pig.dieconsulting.com>

On Sat, Oct 23, 2004 at 03:23:21PM -0400, Adam Shostack wrote:
> 
> The technology will mature *very* rapidly if Virginia makes their
> driver's licenses RFID-enabled, or if the US goes ahead with the
> passports.  Why?  Because there will be a stunning amount of money to
> be stolen by not identity thieves, but real thieves.  Imagine sitting
> with a laptop, a good antenna, and some software outside a metro
> station in Virginia.  Or an upscale restaurant in Adams-Morgan,
> reading off the addresses of those who will be away from home for the
> next 3 hours.

	Correct me if I am wrong, but don't most of the passive, cheap
RF or magnetic field powered RFIDs transmit maybe 128 bits of payload,
not thousands and thousands of bits which would be enough to include
addresses, names, useful biometric data and so forth ?

	For many if not most applications (inventory control and
tracking) a 128 bit unique serial number is enough - are the passport
and drivers license (soon apparently to be the same thing here in the
USA at least in respect to an internal passport required for travel on
public transportation) applications of RFID actually intended to allow
reading tens of kilobytes of data or just a unique serial that can be
used as a key in an on line database system ?

	The signaling reliability problem of successfully transmitting
say 10 or 100 kb of data error free (enough for reasonable info about
someone and some biometric measurements) is quite different from
repeating  128 bits over and over and over until the reader succeeds in
making the FEC and checksums work for a couple of reads out of thousands
of repetitions of the 128 bits.   Detecting a weak repeated short
pattern in noise is much easier than reading thousands of bits with few
or no errors (few enough to be corrected by a reasonable rate FEC).

	Whilst unique serial numbers read at a distance could be used in
a variety of rather sinister ways, they aren't equivalent to dumping the
names, addresses, weight, height, birth date, social security number and
biometric signatures of someone in the clear.   And obviously are
much less useful to an unsophisticated thief without access to the
database mapping the serial number to useful information.

	And further it seems reasonable to suppose that if larger blocks
of useful data get dumped, it would be encrypted under carefully
controlled keys at least for passport and similar applications.  
Granted that very sophisticated attackers might obtain some of these
keys, but the average thief presumably would not have access to them.

	It does occur to me that RFID equipped passports or internal
passports/driver licenses ("your papers please") COULD be equipped with
some kind of press to read switch the would require active finger 
pressure on the card to activate the RFID transmitter - this would
leave them disabled and incapable of transmitting the ID when sitting in
someone's wallet or purse.  Aside from very sinister covert reading
applications I cannot think of any reason why a RFID equipped identity
card would need to be readable without the active cooperation and
awareness of the person carrying the card, thus such a safeing mechanism
would not be a real burden except to those with sinister covert agendas.

	And needless to say, copper screen or foil lined wallets would
become very popular...


-- 
   Dave Emery N1PRE,  die at dieconsulting.com  DIE Consulting, Weston, Mass 02493


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Sun Oct 24 01:24:12 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Sun, 24 Oct 2004 07:24:12 +0200
Subject: VIA PadLock reloaded (fwd from michal@logix.cz)
Message-ID: <20041024052412.GX1457@leitl.org>

From: Michal Ludvig <michal at logix.cz>
Subject: Re: VIA PadLock reloaded
To: James Morris <jmorris at redhat.com>
Cc: CryptoAPI List <cryptoapi at lists.logix.cz>
Date: Sun, 24 Oct 2004 01:55:03 +0200

From: Michal Ludvig <michal at logix.cz>
Date: Sun, 24 Oct 2004 01:55:03 +0200
To: James Morris <jmorris at redhat.com>
Cc: CryptoAPI List <cryptoapi at lists.logix.cz>
Subject: Re: VIA PadLock reloaded
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Michal Ludvig wrote:
> James Morris wrote:
>
>> On Sat, 23 Oct 2004, Michal Ludvig wrote:
>>
>>> I'm currently updating the driver for VIA PadLock cryptoengine and once
>>> I'm on it I'd like to prepare it for kernel inclusion.
>>
>> Have you done any performance measurements with this?  It would be
>> interesting to see its effect on IPSec and disk encryption.
>
> Yes, some numbers are at http://www.logix.cz/michal/devel/padlock/bench.xp

Just in case you have already looked there - few minutes ago I have
added a new section with IPsec benchmark. Rough results:

Plaintext throughput: 11.21 MB/s

IPsec (ESP/transport) without HMAC:
- PadLock AES:   11.00 MB/s (keylen independent)
- AES-i586:      8.01 to 9.84 MB/s depending on the keylen
- Generic C AES: 6.37 to 8.24 MB/s

IPsec with HMAC-SHA256:
- PadLock AES:   8.06 MB/s
- Software AES slower by some 45% than without HMAC.

As soon as I get VIA Esther that can do SHA1/SHA256 in hardware I'll
update the padlock driver as well. Than I expect almost no slowdown even
in HMAC mode (which is almost always used in ESP).

Michal Ludvig
_______________________________________________

Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
List archive: http://lists.logix.cz/pipermail/cryptoapi

----------

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041024/27b92784/attachment.pgp>

From iang at systemics.com  Sun Oct 24 09:11:41 2004
From: iang at systemics.com (Ian Grigg)
Date: Sun, 24 Oct 2004 14:11:41 +0100
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <20041024045856.GB15539@pig.dieconsulting.com>
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com> <20041023192321.GB64625@lightship.internal.homeport.org> <20041024045856.GB15539@pig.dieconsulting.com>
Message-ID: <417BAA0D.3080508@systemics.com>

Dave Emery wrote:
> On Sat, Oct 23, 2004 at 03:23:21PM -0400, Adam Shostack wrote:

> 	Correct me if I am wrong, but don't most of the passive, cheap
> RF or magnetic field powered RFIDs transmit maybe 128 bits of payload,
> not thousands and thousands of bits which would be enough to include
> addresses, names, useful biometric data and so forth ?

I have another question:  aren't RFIDs of this
nature all passive, and need to be excited in
some fashion?  It would seem that detecting the
powering signal may well be a way to defend
against unexpected reads.

> 	Whilst unique serial numbers read at a distance could be used in
> a variety of rather sinister ways, they aren't equivalent to dumping the
> names, addresses, weight, height, birth date, social security number and
> biometric signatures of someone in the clear.   And obviously are
> much less useful to an unsophisticated thief without access to the
> database mapping the serial number to useful information.

OK, so your view would be that SSNs are just
indexes into databases and therefore are not
a threat to anyone.  Very silly of the US congress
to have put restrictions on their use, then...
Mind you, in Australia, they are even less
humours.  I hear, you go to jail if you are
caught using TSNs for anything but the tax
records for your employees.

> 	And further it seems reasonable to suppose that if larger blocks
> of useful data get dumped, it would be encrypted under carefully
> controlled keys at least for passport and similar applications.  
> Granted that very sophisticated attackers might obtain some of these
> keys, but the average thief presumably would not have access to them.

Do you have anything to back up that "reasonable
surmise" ?  I'd say the DeCSS program, and any
analysis of the application, and any amount of
experience with similar apps like smart card money
would say the reverse is true.  Distributing data
that is private to a large quantity of readers
with pre-issued hardware and data is a hard problem,
especially if you can't use public key crypto (but
don't imagine public key crypto solves all the
problems).

Oodles of experience dictate that the information
on the RFIDs will be available to a huge number
of bureaucrats, for free, and anyone who wants
to purchase it, for a market price.  Going on
prior figures seen, I'd say the price would be
order of $10 - $100 (the price of doing business,
as the data cost would be marginal==0), and the
end result is that it would all be bundled up in
the standard package of identity for some given
victim.

> 	It does occur to me that RFID equipped passports or internal
> passports/driver licenses ("your papers please") COULD be equipped with
> some kind of press to read switch the would require active finger 
> pressure on the card to activate the RFID transmitter - this would
> leave them disabled and incapable of transmitting the ID when sitting in
> someone's wallet or purse.  Aside from very sinister covert reading
> applications I cannot think of any reason why a RFID equipped identity
> card would need to be readable without the active cooperation and
> awareness of the person carrying the card, thus such a safeing mechanism
> would not be a real burden except to those with sinister covert agendas.

Actually, I think the people you are dealing with
there are ingenious in a hive like fashion.  They
will come up with a good reason to have them
available for read without the user's knowledge.

> 	And needless to say, copper screen or foil lined wallets would
> become very popular...

The questions would then be, what frequency do these
things operate on, what power is required to power
them up, and what power is required to ... power them
down.  Any radio guys around?

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dan at geer.org  Sun Oct 24 09:35:30 2004
From: dan at geer.org (dan at geer.org)
Date: Sun, 24 Oct 2004 09:35:30 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money) 
In-Reply-To: Your message of "Sun, 24 Oct 2004 15:13:38 +1300."
             <E1CLXt4-0000eI-00@medusa01> 
Message-ID: <20041024133530.2912F1BF97F@absinthe.tinho.net>


|   dan at geer.org writes:
|
|   >I'm pretty sure that you are answering the question
|   >"Why did Microsoft buy Connectix?"
|
|   The answer to that one is actually "To provide a
|   development environment for Windows CE (and later XP
|   Embedded)" (the emulator that's used for development
|   in those environments is VirtualPC).  Thank you for
|   playing.

TILT

No need to buy a company just to use its
product in your development shop.

Please insert additional coins.

--dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From adam at homeport.org  Sun Oct 24 10:40:27 2004
From: adam at homeport.org (Adam Shostack)
Date: Sun, 24 Oct 2004 10:40:27 -0400
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <20041024045856.GB15539@pig.dieconsulting.com>
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com> <20041023192321.GB64625@lightship.internal.homeport.org> <20041024045856.GB15539@pig.dieconsulting.com>
Message-ID: <20041024144027.GA81865@lightship.internal.homeport.org>

On Sun, Oct 24, 2004 at 12:58:56AM -0400, Dave Emery wrote:
| On Sat, Oct 23, 2004 at 03:23:21PM -0400, Adam Shostack wrote:
| > 
| > The technology will mature *very* rapidly if Virginia makes their
| > driver's licenses RFID-enabled, or if the US goes ahead with the
| > passports.  Why?  Because there will be a stunning amount of money to
| > be stolen by not identity thieves, but real thieves.  Imagine sitting
| > with a laptop, a good antenna, and some software outside a metro
| > station in Virginia.  Or an upscale restaurant in Adams-Morgan,
| > reading off the addresses of those who will be away from home for the
| > next 3 hours.
| 
| 	Correct me if I am wrong, but don't most of the passive, cheap
| RF or magnetic field powered RFIDs transmit maybe 128 bits of payload,
| not thousands and thousands of bits which would be enough to include
| addresses, names, useful biometric data and so forth ?

Unclear.  Presuming you're right, that 128 bit number will become
your ID, just like your SSN is now.  If you broadcast it at the
right time, you'll be Alice.

| 	And further it seems reasonable to suppose that if larger blocks
| of useful data get dumped, it would be encrypted under carefully
| controlled keys at least for passport and similar applications.  
| Granted that very sophisticated attackers might obtain some of these
| keys, but the average thief presumably would not have access to them.

You're reasonable, they're the United States Government, and they have
responsed to questions about how to protect the keys that would be used
to read it. (which, after all, would need to be in at least thousands
of readers, just in the US, never mind in the other 190 odd countries
which will want to verify passports..)

>>> ACLU's Technology and Liberty Program describes what they were
>>> told in a briefing by Frank Moss, USA Deputy Assistant Secretary
>>> of State for Passport Services and director of the State
>>> Department's Bureau of Consular Affairs:

>>>> passport issued in San Diego from January 2005 to August
>>>> 2005. But you can't use the public key to then create a signature
>>>> on a fraudulent document. And the public key is not used to
>>>> access the data on the document -- that is wide open -- it is
>>>> used only to verify the authenticity of the passport.

(From http://hasbrouck.org/blog/archives/000434.html)

| 	It does occur to me that RFID equipped passports or internal
| passports/driver licenses ("your papers please") COULD be equipped with
| some kind of press to read switch the would require active finger 
| pressure on the card to activate the RFID transmitter - this would
| leave them disabled and incapable of transmitting the ID when sitting in
| someone's wallet or purse.  Aside from very sinister covert reading
| applications I cannot think of any reason why a RFID equipped identity
| card would need to be readable without the active cooperation and
| awareness of the person carrying the card, thus such a safeing mechanism
| would not be a real burden except to those with sinister covert agendas.

And who is going to pay for this press to read addition?  Maybe,
rather than designing with RFID, they could use a smart-card chip
which requires contact?  seems easier, no?

Adam

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Mon Oct 25 06:23:25 2004
From: iang at systemics.com (Ian Grigg)
Date: Mon, 25 Oct 2004 11:23:25 +0100
Subject: Financial identity is *dangerous*? (was re: Fake companies, real
 money)
In-Reply-To: <20041022162751.7084D1BF96B@absinthe.tinho.net>
References: <20041022162751.7084D1BF96B@absinthe.tinho.net>
Message-ID: <417CD41D.6010405@systemics.com>

http://www.financialcryptography.com/mt/archives/000219.html

dan at geer.org wrote:

> ... to break the conundrum Ballmer finds himself
> in where the road forks towards (1) fix the security
> problem but lose backward compatibility, or (2) keep
> the backward compatibility but never fix the problem.

I think the recent decision by Microsoft to not upgrade
browsers indicates that they are plumbing for your choice
(1).  Backwards compatibility takes a back seat.  I wrote
more about it here:

http://www.financialcryptography.com/mt/archives/000219.html

> His Board would prefer (2), the annuity of locked-in
> users, but it forces a bet that software liability
> never happens.  Fixing the problem, for which the
> calls grow more strident daily, puts the desktop
> platform into play even more than it is now as
> it asks the users (who, having lost compatibility,
> thus have nothing to lose) to marry Redmond a
> second time.  A VM-cures-all strategy is then
> an attempt to avoid having to choose between (1)
> and (2) by breaking backward compatibility for
> new things but bridging the old things with a
> magic box that both preserves the annuity revenue
> stream from locked-in users while it keeps the
> liability bar at bay.

I have two questions:  Does he have a board?  I
never heard of anyone but Bill Gates telling Ballmer
what to do.  Just curious!

Secondly, is a VM strategy likely to work?  Assuming
that Microsoft can make it work nicely, it also opens
the door for other OSs to be added into the mix, something
that Microsoft wouldn't be that keen to promote.

(I don't disagree with your comments, though!)

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From Victor.Duchovni at MorganStanley.com  Mon Oct 25 09:45:31 2004
From: Victor.Duchovni at MorganStanley.com (Victor Duchovni)
Date: Mon, 25 Oct 2004 09:45:31 -0400
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <20041023192321.GB64625@lightship.internal.homeport.org>
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com> <20041023192321.GB64625@lightship.internal.homeport.org>
Message-ID: <20041025134531.GH4922@piias899.ms.com>

On Sat, Oct 23, 2004 at 03:23:21PM -0400, Adam Shostack wrote:

> 5 years?  I don't think we have that long.
> 
> The technology will mature *very* rapidly if Virginia makes their
> driver's licenses RFID-enabled, or if the US goes ahead with the
> passports.  Why?  Because there will be a stunning amount of money to
> be stolen by not identity thieves, but real thieves.  Imagine sitting
> with a laptop, a good antenna, and some software outside a metro
> station in Virginia.  Or an upscale restaurant in Adams-Morgan,
> reading off the addresses of those who will be away from home for the
> next 3 hours.
> 

Is the problem discriminating the RFID response, or supplying power so
it can respond at all?

How much power does the reader need to emit to activate the RFID? What
sort of equipment is needed to deliver the power directionally?

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Mon Oct 25 11:01:22 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Mon, 25 Oct 2004 17:01:22 +0200
Subject: OpenSSL 0.9.7e released (fwd from mark@openssl.org)
Message-ID: <20041025150122.GD1457@leitl.org>

From: Mark J Cox <mark at openssl.org>
Subject: OpenSSL 0.9.7e released
To: openssl-announce at openssl.org, openssl-users at openssl.org,
	openssl-dev at openssl.org
Date: Mon, 25 Oct 2004 14:49:49 +0100 (BST)
Reply-To: openssl-dev at openssl.org


From: Mark J Cox <mark at openssl.org>
Date: Mon, 25 Oct 2004 14:49:49 +0100 (BST)
To: openssl-announce at openssl.org, openssl-users at openssl.org,
	openssl-dev at openssl.org
Subject: OpenSSL 0.9.7e released
Reply-To: openssl-dev at openssl.org


  OpenSSL version 0.9.7e released
  ==========================================

  OpenSSL - The Open Source toolkit for SSL/TLS
  http://www.openssl.org/

  The OpenSSL project team is pleased to announce the release of
  version 0.9.7e of our open source toolkit for SSL/TLS.  This new
  OpenSSL version is a bugfix release and incorporates changes and
  bugfixes to the toolkit (for a complete list see 
  http://www.openssl.org/source/exp/CHANGES ).

  The most significant changes are:

    o Fix race condition in CRL checking code.
    o Fixes to PKCS#7 (S/MIME) code.

  We consider OpenSSL 0.9.7e to be the best version of OpenSSL available
  and we strongly recommend that users of older versions upgrade as
  soon as possible.  OpenSSL 0.9.7e is available for download via HTTP
  and FTP from the following master locations (you can find the various
  FTP mirrors under http://www.openssl.org/source/mirror.html):

    o http://www.openssl.org/source/
    o ftp://ftp.openssl.org/source/

  The distribution file name is:

    o openssl-0.9.7e.tar.gz
      MD5 checksum: a8777164bca38d84e5eb2b1535223474

  The checksums were calculated using the following command:

    openssl md5 < openssl-0.9.7e.tar.gz


  Yours,
  The OpenSSL Project Team...  

    Mark J. Cox             Ben Laurie          Andy Polyakov
    Ralf S. Engelschall     Richard Levitte     Geoff Thorpe
    Dr. Stephen Henson      Bodo M?ller
    Lutz J?nicke            Ulf M?ller
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev at openssl.org
Automated List Manager                           majordomo at openssl.org

----------

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041025/78a3141a/attachment.pgp>

From ben at algroup.co.uk  Mon Oct 25 11:23:14 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Mon, 25 Oct 2004 16:23:14 +0100
Subject: Printers betray document secrets
In-Reply-To: <p0620053abd9d90eb0302@[129.46.153.119]>
References: <p061104d3bd9a08e62dca@[66.149.49.5]> <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com> <p0620053abd9d90eb0302@[129.46.153.119]>
Message-ID: <417D1A62.2050708@algroup.co.uk>

Marshall Clow wrote:
> At 10:44 PM -0700 10/20/04, Bill Stewart wrote:
> 
>> At 05:23 PM 10/18/2004, R.A. Hettinga wrote:
>>
>>>  <http://news.bbc.co.uk/2/low/technology/3753886.stm>
>>
>>
>> It's not clear that they work at all with inkjet printers,
>> and changing ink cartridges is even more common than
>> changing laser printer cartridges.  If you're sloppy,
>> you've probably got a bunch of partly-used cartridges around,
>> so even if you want to print out a bunch of ransom notes
>> or whatever, you don't even have to go to Kinko's
>> to get them to be different.
> 
> 
> If you're really concerned about this, buy a cheap inkjet,
> use it for your purposes, then destroy it.

This only works if the marks are not such that the identity of the 
printer is linked to the marks (as opposed to being able to test whether 
a particular document was produced by a particular printer).

To be really safe, I'd suggest going somewhere without surveillance 
cameras, buying a printer for cash, using it and then destroying it.

Don't forget not to use your car and leave your mobile phone behind. Oh, 
and take the RFID tags out of your clothes.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ptrei at rsasecurity.com  Mon Oct 25 09:30:50 2004
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Mon, 25 Oct 2004 09:30:50 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE297161818@rsana-ex-hq1.NA.RSA.NET>



> -----Original Message-----
> From: owner-cryptography at metzdowd.com
> [mailto:owner-cryptography at metzdowd.com]On Behalf Of Aaron Whitehouse
> Sent: Saturday, October 23, 2004 1:58 AM
> To: Ian Grigg
> Cc: cryptography at metzdowd.com
> 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 majordomo at metzdowd.com


From rah at shipwright.com  Mon Oct 25 16:42:25 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Mon, 25 Oct 2004 16:42:25 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies,
 real money)
In-Reply-To: <20041023204155.GR1457@leitl.org>
References:  <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net>
 <41764C42.24691.43BECA@localhost> <4177E1C8.8030807@systemics.com>
 <4179F302.6020006@whitehouse.org.nz> <20041023204155.GR1457@leitl.org>
Message-ID: <p061104fbbda313067d6e@[66.149.49.5]>

At 10:41 PM +0200 10/23/04, Eugen Leitl wrote:
>No, that's going to be the mobile phone.

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.

Cheers,
RAH

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From fw at deneb.enyo.de  Mon Oct 25 16:44:03 2004
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 25 Oct 2004 22:44:03 +0200
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <20041024045856.GB15539@pig.dieconsulting.com> (Dave Emery's
	message of "Sun, 24 Oct 2004 00:58:56 -0400")
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com>
	<20041023192321.GB64625@lightship.internal.homeport.org>
	<20041024045856.GB15539@pig.dieconsulting.com>
Message-ID: <87is8yil4c.fsf@deneb.enyo.de>

* Dave Emery:

> 	Correct me if I am wrong, but don't most of the passive, cheap
> RF or magnetic field powered RFIDs transmit maybe 128 bits of payload,
> not thousands and thousands of bits which would be enough to include
> addresses, names, useful biometric data and so forth ?

Those that perform actual cryptographic operations can store tens of
thousands of bits.  Even older tags (without proper crypto) easily
reach 2**15 bits.  These tags (for example, MIFARE) are usually not
considered RFID tags by privacy activists, even though they can be
read at some distance (but not with COTS equipment).  Contactless
readers are only used for user comfort (you can leave the card in your
purse) and to counter vandalism, not for tracking purposes.

The tags you are referring to are RFID tags used in logistics which
usually provide only very, very few bits (which sometimes can't even
be changed).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Mon Oct 25 17:03:15 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Mon, 25 Oct 2004 17:03:15 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies,
 real money)
In-Reply-To:  <017630AA6DF2DF4EBC1DD4454F8EE297161818@rsana-ex-hq1.NA.RSA.NET>
References:  <017630AA6DF2DF4EBC1DD4454F8EE297161818@rsana-ex-hq1.NA.RSA.NET>
Message-ID: <p061104febda31a362ca8@[66.149.49.5]>

At 9:30 AM -0400 10/25/04, Trei, Peter wrote:
>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?

I don't think that face to face will be necessary. It just means keeping
control of your keys, etc. You can stash bearer-bonds on the net in m-of-n
storage, where nobody knows what's what, paid by the bit, etc.

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

Certainly bits are smaller. See above, though.

Cheers,
RAH


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Mon Oct 25 17:31:48 2004
From: iang at systemics.com (Ian Grigg)
Date: Mon, 25 Oct 2004 22:31:48 +0100
Subject: Financial identity is *dangerous*? (was re: Fake companies, real
 money)
In-Reply-To: <20041023202123.GA1594@apb-laptoy.apb.alt.za>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net> <41764C42.24691.43BECA@localhost> <4177E1C8.8030807@systemics.com> <4179F302.6020006@whitehouse.org.nz> <20041023202123.GA1594@apb-laptoy.apb.alt.za>
Message-ID: <417D70C4.30803@systemics.com>



Alan Barrett wrote:
> On Sat, 23 Oct 2004, Aaron Whitehouse wrote:
> 
>>>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.
>>
>>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...
> 
> 
> The risks of using *somebody else's keypad* to type passwords or
> instructions to your smartcard, or using *somebody else's display* to
> view output that is intended to be private, should be obvious.

:-)

It should be obvious.  But it's not.  A few billions
of investment in smart cards says that it is anything
but obvious.

To be fair, the smart card investments I've been
familiar with have been at least very well aware of
the problem.  It didn't stop them proceeding with
papering over the symptoms, when they should have
gone for the underlying causes.

iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Mon Oct 25 18:19:05 2004
From: iang at systemics.com (Ian Grigg)
Date: Mon, 25 Oct 2004 23:19:05 +0100
Subject: Printers betray document secrets
In-Reply-To: <417D1A62.2050708@algroup.co.uk>
References: <p061104d3bd9a08e62dca@[66.149.49.5]> <6.0.3.0.0.20041020222838.0439a390@pop.idiom.com> <p0620053abd9d90eb0302@[129.46.153.119]> <417D1A62.2050708@algroup.co.uk>
Message-ID: <417D7BD9.2030803@systemics.com>



Ben Laurie wrote:

> This only works if the marks are not such that the identity of the 
> printer is linked to the marks (as opposed to being able to test whether 
> a particular document was produced by a particular printer).
> 
> To be really safe, I'd suggest going somewhere without surveillance 
> cameras, buying a printer for cash, using it and then destroying it.
> 
> Don't forget not to use your car and leave your mobile phone behind. Oh, 
> and take the RFID tags out of your clothes.

It's actually quite an amusing problem.  When put
in those terms, it might be cheaper and more secure
to go find some druggie down back of central station,
and pay them a tenner to write out the ransom demand.
Or buy a newspaper and start cutting and pasting the
letters...

In more scientific terms, is there a way to efficiently
print an anonymous paper document?  (By anonymous,
I mean a document that leaves no easy clues back to
the author.)  When creating ones anonymous political
pamphlets revealing the latest government scandal,
one might need the help of RFC 666, "how to print
anonymous pamphlets with modern printers."

E.g., something like:  acquire a HP inkjet and a
Brother laser.  Disengage the ink drying fan in the
Brother.  Print the page through the Brother then
print the same page (wet!) through the HP within 5
seconds.  For paper, use fish&chip wrap, cleaned
with sarsons and dried for 30 mins under a tanning
lamp with the UV filter removed...

iang


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From roy at rant-central.com  Mon Oct 25 18:41:01 2004
From: roy at rant-central.com (Roy M. Silvernail)
Date: Mon, 25 Oct 2004 18:41:01 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies,
	real money)
In-Reply-To: <20041024133530.2912F1BF97F@absinthe.tinho.net>
References: <20041024133530.2912F1BF97F@absinthe.tinho.net>
Message-ID: <1098744061.21969.3.camel@mesmer.rant-central.com>

On Sun, 2004-10-24 at 09:35 -0400, dan at geer.org wrote:
> |   dan at geer.org writes:
> |
> |   >I'm pretty sure that you are answering the question
> |   >"Why did Microsoft buy Connectix?"
> |
> |   The answer to that one is actually "To provide a
> |   development environment for Windows CE (and later XP
> |   Embedded)" (the emulator that's used for development
> |   in those environments is VirtualPC).  Thank you for
> |   playing.
> 
> TILT
> 
> No need to buy a company just to use its
> product in your development shop.
> 
> Please insert additional coins.

I'd thought it was so Microsoft could offer an emulation-based migration
path to all the apps that would be broken by Longhorn.  MS has since
backed off on the new filesystem proposal that would have been the
biggest source of breakage (if rumors of a single-rooted, more *nix-like
filesystem turned out to be true).
-- 
Roy M. Silvernail is roy at rant-central.com, and you're not
"It's just this little chromium switch, here." - TFS
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From pgut001 at cs.auckland.ac.nz  Tue Oct 26 00:27:03 2004
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 26 Oct 2004 17:27:03 +1300
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <20041024133530.2912F1BF97F@absinthe.tinho.net>
Message-ID: <E1CMIvH-0006Bk-00@medusa01>

dan at geer.org writes:

>No need to buy a company just to use its product in your development shop.

They're not "using it in their development shop", that's their standard
development environment that they ship to all Windows CE, Pocket PC,
SmartPhone, and XP Embedded developers (and include free with every copy of
MSDN).  If an entire branch of my OS development was centered around a
particular technology, I'd want to make sure I owned both the technology and
the developers who created it and will be maintaining/updating it in the
future.  This isn't an optional add-on that MS uses internally, it's a core
component of their embedded OS effort that they push out to anyone who'll take
it in an attempt to dissuade them from going with QNX, embedded Linux,
VxWorks, etc etc.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From bill.stewart at pobox.com  Tue Oct 26 21:51:10 2004
From: bill.stewart at pobox.com (Bill Stewart)
Date: Tue, 26 Oct 2004 18:51:10 -0700
Subject: Are new passports [an] identity-theft risk?
In-Reply-To: <417BAA0D.3080508@systemics.com>
References: <30F37C4533D8564FB1D58BFDAF6687C101670A3E@ohthree.jjj-i.com>
 <20041023192321.GB64625@lightship.internal.homeport.org>
 <20041024045856.GB15539@pig.dieconsulting.com>
 <417BAA0D.3080508@systemics.com>
Message-ID: <6.0.3.0.0.20041026184619.03c0a168@pop.idiom.com>

At 06:11 AM 10/24/2004, Ian Grigg wrote:
The questions would then be, what frequency do these
>things operate on, what power is required to power
>them up, and what power is required to ... power them
>down.  Any radio guys around?

There's an excellent RFID reference article at
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=216

RFIDs run at a variety of frequencies,
including 128 kHz, 13.56MHz, 915 MHz, 2.45GHz,
which are the common ISM bands that lots of other things run in,
such as cordless phones, WiFi, Microwave ovens, etc.,
which means that detecting readers may be tough.

It doesn't take a lot of power to power them;
not sure what it takes to fry them.


----
Bill Stewart  bill.stewart at pobox.com 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Tue Oct 26 22:51:43 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Tue, 26 Oct 2004 22:51:43 -0400
Subject: E-Vote Vendors Hand Over Software
Message-ID: <p06110402bda4bda7c45c@[66.149.49.5]>

<http://www.wired.com/news/print/0,1294,65490,00.html>

Wired News

E-Vote Vendors Hand Over Software 
By Kim Zetter?

Story location: http://www.wired.com/news/evote/0,2645,65490,00.html

03:00 PM Oct. 26, 2004 PT

In an effort to increase the integrity of next week's presidential
election, five voting machine makers agreed for the first time to submit
their software to the National Software Reference Library for safekeeping,
federal officials said on Tuesday.

 The stored software will serve as a comparison tool for election officials
should they need to determine whether anyone tampered with programs
installed on voting equipment.


 The National Software Reference Library is part of an election security
initiative launched by the U.S. Election Assistance Commission, a new
federal entity that Congress created after the Florida 2000 election
problems. The EAC is the first federal entity established to improve the
integrity and efficiency of elections.

 DeForest Soaries, chairman of the EAC, in June requested software from the
largest voting companies, which provide 90 percent of the software to be
used in computerized voting machines on Tuesday. The EAC will eventually
ask all voting companies, even those that produce counting software for
punch card machines, to submit their software.

 Soaries called the library a major step and praised the vendors for their
willingness to increase the transparency of elections.

 "Their acceptance of our request to submit their software begins the
process that assures the country that we will have (a) higher level of
security and therefore confidence in e-voting than we have ever had
before," Soaries said in a press conference.

 The National Institute of Standards and Technology -- the agency that sets
official measurements and defines standards for all kinds of commercial
products -- will maintain the voting software library. NIST already manages
a library of other types of software, like the Windows 2000 operating
system, to help law enforcement investigate crimes involving computers.
Doug White, the library's project leader, said NIST stores applications on
CDs in a room that is similar to a criminal investigator's evidence locker,
which means the software can be used as evidence in a court.

 Counties and states will eventually be able to use the library to verify
that they are using a certified version of software. This is good news to
Scott Konopasek, the registrar of voters for San Bernardino County in
California. In September, after California certified a new version of
software for his county's voting system, the vendor, Sequoia Voting
Systems, sent Konopasek the software to load on his machines. But when
Konopasek asked the state to verify that the software the vendor gave him
was unchanged from the version the state certified, state officials told
him they had no means to verify it and that Konopasek would have to trust
the vendor.

 Vendor trust was precisely the measure of verification the state was using
last November when it discovered that Diebold Election Systems had
installed uncertified software on machines in 17 California counties
without telling the state.

 NIST's voting software library was established too late this year to
examine software that has already been loaded onto locked voting machines,
so election officials won't be able to verify that they have unchanged,
certified software before Tuesday's election.

 But if questions about the veracity of a voting system arise after the
election, computer forensic experts will be able to compare the software
used on machines with the software in the NIST library to see if the
software was altered. They can do this by comparing hash files, which are
digital fingerprints that identify the integrity of software. The hash is a
mathematical sum derived from the software code. If someone changes the
software, the mathematical sum changes as well.

 "This gives us one more mechanism for assuring voters that their votes
have been recorded and reported correctly and haven't been tampered with,"
Konopasek said. "There's no one single thing that election officials will
ever be able to do to convince everyone. But the more we can add to our
inventory of audits and controls, the more we can establish confidence of
voters -- not just the technically savvy voters, but all voters."

 Soaries acknowledged that the library alone can't secure elections and
voting systems but can only work in concert with other procedures. And the
EAC still has to work out several issues related to the library, such as
who will be responsible for checking hashes before an election if county
election officials don't have someone knowledgeable on staff to do so. EAC
has to determine how best to handle patches, or last-minute fixes and
upgrades to machines. Currently, it will be up to the county and vendor to
decide whether to resubmit that software to the library before an election.
And the EAC has to establish a policy for dealing with false positives --
that is, when a hash check indicates that software has changed when it
actually hasn't.

 In addition to the library, the Commission has instigated several measures
to increase the integrity of elections. These include developing new voting
machine standards that would require voting machine companies to make
machines that are more secure.

 The commission is also looking at developing national standards for
election procedures to establish uniform methods for physically securing
voting machines and providing checks and balances to prevent and catch
voter fraud. Additionally, the commission has been speaking about creating
a clearinghouse to gather reports from states and counties about problems
they encounter with voting equipment.


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dan at geer.org  Tue Oct 26 23:07:25 2004
From: dan at geer.org (dan at geer.org)
Date: Tue, 26 Oct 2004 23:07:25 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money) 
In-Reply-To: Your message of "Tue, 26 Oct 2004 17:27:03 +1300."
             <E1CMIvH-0006Bk-00@medusa01> 
Message-ID: <20041027030725.F357E1BF969@absinthe.tinho.net>


This is what I love about the Internet -- ask a question
and get silence but make a false claim and you get all the
advice you can possibly eat.

OK, I (quite happily) stand corrected about why Microsoft
bought Connectix --  it was cheaper given their extensive
dependence on the Virtual PC product, including redistribution
to outside parties.  That's fascinating, actually.

Now the reason I brought this up was it seemed like a Heaven-
sent bit of circumstantial evidence[1] to inference about a
larger business strategy question.  That question still stands,
but I'll have to look harder for corroborating evidence.

--dan, on the road


[1] "Some circumstantial evidence is very strong, like 
finding a trout in the milk." -- Henry David Thoreau


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct 27 09:59:47 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Wed, 27 Oct 2004 09:59:47 -0400
Subject: Deadline extended to November 5th - Fourth Annual PKI R&D
 Workshop
Message-ID: <p0611040dbda55a4a7b88@[66.149.49.5]>


--- begin forwarded text


From: "Carl Ellison" <cme at acm.org>
To: <spki at metzdowd.com>
Subject: Deadline extended to November 5th - Fourth Annual PKI R&D Workshop
Date: Tue, 26 Oct 2004 21:00:01 -0700
Thread-Index: AcS72W7c3/cyBY4hSTyGnbNT4eKDuQ==
Sender: owner-spki at metzdowd.com

The deadline for paper submissions to the "Fourth Annual PKI R&D Workshop:
Multiple Paths to Trust" and has been extended until 5:00 PM Pacific time
on Friday November 5th.

<http://middleware.internet2.edu/pki05/>http://middleware.internet2.edu/pki05/

This year, the workshop has a particular interest in how emergent trust
mechanisms will interact with each other mechanisms at the technical,
policy and user levels.

Clifford Neuman

Program Committee Chair



--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct 27 09:56:44 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Wed, 27 Oct 2004 09:56:44 -0400
Subject: US Bancorp teams up with VeriSign on banking security
Message-ID: <p0611040cbda558f72c03@[66.149.49.5]>


>The bank will use VeriSign's Unified Authentication service to validate
>and secure interactions with commercial banking customers, providing them
>with a secure USB token that they must use when accessing services online.


>Those tokens will hold a digital certificate that identifies the bearer
>and will need to be inserted into machines before accessing web-based
>commercial banking applications, Lin said.



<http://www.computerweekly.com/print/ArticlePrinterPage.asp?liArtID=134593&liFlavourID=1>


Printed from ComputerWeekly.com

Technology: Security Products
Wednesday 27 October 2004
US Bancorp teams up with VeriSign on banking security
US Bancorp will use a hardware-token based authentication service from
VeriSign to secure access to commercial banking services for its customers.

The bank will use VeriSign's Unified Authentication service to validate and
secure interactions with commercial banking customers, providing them with
a secure USB token that they must use when accessing services online.

The deal is just the latest evidence of renewed interest in so-called
"multifactor" authentication within the banking industry, which is
struggling with an epidemic of sophisticated online identity theft scams,
according to Judy Lin, executive vice-president for VeriSign's security
services.

As part of the programme, US Bancorp will make VeriSign security tokens
available to more than 10,000 commercial banking customers. Those tokens
will hold a digital certificate that identifies the bearer and will need to
be inserted into machines before accessing web-based commercial banking
applications, Lin said.

The Unified Authentication service combines VeriSign-branded eToken USB
authentication devices from Aladdin Knowledge Systems with a managed
validation service that runs on VeriSign's infrastructure.

It also includes software modules that plug into a bank's existing back-end
infrastructure. Banks can also choose to operate their own validation
server as part of the service, Lin said.

At US Bancorp, the authentication service will be integrated with existing
user directory and identity management technology, validating interactions
between the bank and its customers. A server operated by VeriSign will
handle token validation, but no customer information will leave US
Bancorp's network in the process, she said.

VeriSign launched the Unified Authentication service in September as an
extension of its Intelligence and ControlSM Services, which offer
businesses network security information and tools.

User login and permission information resides in the customer's user
directory, but is linked to a unique serial number for a secure token or
other authentication device stored on a VeriSign server. Login requests by
users will be passed to the VeriSign server, where a stored algorithm will
validate that the serial number of the secure token or the one-time
password is valid for the user requesting access, VeriSign said.

US Bancorp  is the eighth largest bank in the US.

The bank is looking into a similar programme for its consumer banking
customers, although such a service would likely forgo use of USB hardware
tokens, which can cost $20 or more each. Instead, inexpensive solutions
such as plastic cards with lists of single-use passwords could be employed,
she said. 

Paul Roberts writes for IDG News Service


? 2004 ComputerWeekly.com Ltd. All rights reserved



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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct 27 09:53:06 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Wed, 27 Oct 2004 09:53:06 -0400
Subject: New 32-bit SIM Chip from STMicroelectronics
Message-ID: <p0611040bbda557e8ec76@[66.149.49.5]>


>The core includes dedicated DES (Data Encryption Standard) instructions
>for Secret Key cryptography, and a fast Multiply and Accumulate
>instruction for Public Key (RSA) and Elliptic Curve cryptography, plus a
>CRC (Cyclic Redundency Check) instruction. A firmware cryptographic
>subroutine library is located in a secure ROM area to save designers the
>need to code first-layer functions.


<http://www.tmcnet.com/usubmit/2004/Oct/1087666.htm>

Technology Marketing Corporation
TMCNet



[October 27, 2004]

New 32-bit SIM Chip from STMicroelectronics Will Benefit Mobile Phone
Multimedia Services
 GENEVA, Oct. 27 /PRNewswire-FirstCall/ -- STMicroelectronics has announced
a new smartcard MCU in its ST22 range -- based on the SmartJ(TM)
Java-accelerated RISC architecture -- which integrates 256-kbytes of EEPROM
memory with a high performance CPU to support the demands of multimedia
applications on the latest mobile phones.


 With sales of multimedia-equipped handsets booming, mobile communications
operators supporting 3G (Third Generation) and 2.5G mobile phones need
(U)SIM cards (Universal Subscriber Identity Modules) that have sufficient
memory capacity to store Multimedia Messaging System (MMS) data, video, and
photographic images, coupled with the capability to transfer and use this
data efficiently to provide advanced phonebooks and audio-visual services.
2.5G is an intermediate level of service that uses an enhanced
second-generation technology to provide some of the 3G features over GPRS
(General Packet Radio Service).
 "The ST22N256 is perfectly in line with the growing demand for secure
high-performance chips with high-speed interfaces and a large memory
capacity, for use in 2.5 and 3G SIMs," said Reza Kazerounian, General
Manager of ST's Smart Card ICs Division. "ST already offers the largest
range of secure 32-bit processors for smartcard systems, and will remain at
the forefront of smartcard silicon suppliers as 3G takes off."
 The SmartJ CPU core at the heart of ST22 Family -- which the new ST22N256
now combines with 256-kbytes of EEPROM -- is a 32-bit RISC-architecture
core developed specifically to provide very fast execution of Java, the
programming language commonly used for small applications, or applets,
downloaded to mobile phones. The ST22 augments its own highly efficient
native RISC instruction set with a hardware decoder that directly converts
Java bytecodes into native microcode instructions, thereby eliminating the
overhead and lower performance of processors based on Java emulation. The
result is not only very fast Java execution but also reduced power
consumption.
 An essential component of all GSM (Global System for Mobile
Communications) mobile phones, the SIM card stores critical subscriber
authentication information; private data such as personal phone
directories, messages, audio, and images; and the operating system and
operator's multimedia environment. With the quantity and size of users' MMS
messages increasing, operators will now be able to provide increased
storage for subscriber data without impacting user friendliness, due to the
exceptional performance of the ST22N256's SmartJ processor, and its
communication through a fast Asynchronous Serial Interface (ASI) which
enables 440-kbit/s communication speeds with mobile equipment, in line with
the fastest deployments of ISO 7816 in the GSM world. Two additional serial
I/O ports are also provided.
 The Java-accelerated CPU ensures that the ST22N256 not only provides the
memory needed for today's multimedia services (M-services), but also the
processing power to exploit it. The core, with 24-bit linear memory
addressing, is complemented by 368-kbytes of on-chip ROM, 16-kbytes of RAM,
and a set of standard peripherals and custom plug-in circuits. Logical and
physical security mechanisms are fully integrated into the silicon,
including a hardware Memory Protection Unit for application firewalling and
peripheral access control, and a protected Context Stack. The core includes
dedicated DES (Data Encryption Standard) instructions for Secret Key
cryptography, and a fast Multiply and Accumulate instruction for Public Key
(RSA) and Elliptic Curve cryptography, plus a CRC (Cyclic Redundency Check)
instruction. A firmware cryptographic subroutine library is located in a
secure ROM area to save designers the need to code first-layer functions.
 The ST22 product platform is supported by a comprehensive Integrated
Development Environment, which allows coding, compilation, and debugging
using a common interface. It provides a code-generation chain that includes
a C/C++ compiler, a native and JavaCard assembler and a linker, plus a
SmartJ instruction set simulator, C/C++ source level debugger, and hardware
emulation tools. Operating System developers currently working with the
128-kbyte ST22L128 will be able to benefit from the design continuity
offered by the ST22N256, as well as its immediate availability and
compliance with the fastest communication standard adopted by handset
manufacturers.
 The SmartJ development methodology allows customers to significantly
reduce the time and cost of developing secure applications. It supports
concurrent hardware and software development, multiple development teams
and IP reuse, as well as security evaluation to the Common Criteria and the
use of formal methods for security assurance through executable high-level
specifications and model checking techniques.
 Development of the ST22N256 follows more than 20 years' experience in the
design of silicon products to the highest levels of security. ST is a major
manufacturer for the smartcard market, and is the number one supplier of
secure ICs to the financial sector for card applications. Over the years it
has evolved a "security culture" across design and manufacturing functions,
in addition to meeting the stringent requirements of formal security
certification.
 The ST22N256 is manufactured using 0.15-micron technology, and is
currently the only secure IC to combine 32-bit processing power with 256-
kbytes of EEPROM and 368-kbytes of ROM. It is available in sample form now,
with volume production starting 2005. US pricing for the product is between
$4 and $5, depending on quantity and final packaging.
 About STMicroelectronics
 STMicroelectronics is a global leader in developing and delivering
semiconductor solutions across the spectrum of microelectronics
applications. An unrivalled combination of silicon and system expertise,
manufacturing strength, Intellectual Property (IP) portfolio and strategic
partners positions the Company at the forefront of System-on-Chip (SoC)
technology and its products play a key role in enabling today's convergence
markets. The Company's shares are traded on the New York Stock Exchange, on
Euronext Paris and on the Milan Stock Exchange. In 2003, the Company's net
revenues were $7.24 billion and net earnings were $253 million. Further
information on ST can be found at http://www.st.com/.
 For further information, please contact

 INVESTOR RELATIONS:

 Stanley March Fabrizio Rossini Benoit de Leusse
 Vice President Senior Manager Director
 Investor Relations Investor Relations Investor Relations
 Tel: +1.212.821.89.39 Tel : +41.22.929.69.73 Tel : +41.22.929.58.12
 Fax : +1.212.821.89.23 Fax : +41.22.929.69.61 Fax : +41.22.929.69.61
 Email: Email: Email:
 stan.march at st.com fabrizio.rossini at st.com benoit.de-leusse at st.com

 MEDIA RELATIONS:

 Maria Grazia Prestini Michael Markowitz
 Director, Corporate Media Relations Director, U.S. Media Relations
 Tel: +41.2.29.29.69.45 Tel: +1.212.821.8959
 Fax: +41.2.29.29.69.50 Fax: +1.212.821.8922
 Email: mariagrazia.prestini at st.com Email: michael.markowitz at st.com

 STMicroelectronics


 CONTACT: INVESTORS: Stanley March, Vice President, Investor
Relations,+1-212-821-89-39, or fax, +1-212-821-89-23, stan.march at st.com, or
FabrizioRossini, Senior Manager, Investor Relations, +41-22-929-69-73, or
fax,+41-22-929-69-61, fabrizio.rossini at st.com, or Benoit de Leusse,
Director,Investor Relations, +41-22-929-58-12, or fax,
+41-22-929-69-61,benoit.de-leusse at st.com; or MEDIA: Maria Grazia Prestini,
Director, CorporateMedia Relations, +41-2-29-29-69-45, or fax,
+41-2-29-29-69-50,mariagrazia.prestini at st.com, or Michael Markowitz,
Director, U.S. MediaRelations, +1-212-821-8959, or fax, +1-212-821-8922,
michael.markowitz at st.com,all of STMicroelectronics


 Web site: http://www.st.com/

[ Back To TMCnet.com's Homepage ]





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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From iang at systemics.com  Wed Oct 27 11:01:08 2004
From: iang at systemics.com (Ian Grigg)
Date: Wed, 27 Oct 2004 16:01:08 +0100
Subject: MCI set to offer secure two-way messaging with strong encryption
Message-ID: <417FB834.1060706@systemics.com>

http://www.gcn.com/vol1_no1/daily-updates/27748-1.html

MCI set to offer secure two-way messaging with strong encryption
10/27/04
By William Jackson,
GCN Staff

MCI Inc. will offer secure two-way messaging through its SkyTel
Communications subsidiary next month, encrypting wireless text
with the Advanced Encryption Algorithm.

?It was initially designed to meet the security needs of our
government customers,? SkyTel marketing director Michael Barnes
said.

The company plans to get the device for its Secure 2Way service
certified for Federal Information Processing Standard 140-2,
which applies to cryptological devices used by the government.

The company also is promoting the service as compliant with the
Health Insurance Portability and Accountability Act and expects
the health care and financial service industries to be early users.

Text messaging and paging has emerged as a reliable?sometimes
the only?means of communication during emergencies that disrupt
other media, such as wired and cellular telephone systems and
the Internet.

The Secure 2Way service uses the handheld ST900 2Way messaging
device from Sun Telecom Inc. of Norcross, Ga. Messages are
encrypted between the device and an encryption server at SkyTel?s
secure network operations center.

Two levels of service are offered. Device-level security provides
device-to-device encryption when both users have the ST900. When
messages are received from nonsecure devices, traffic is encrypted
only between the operations center server and the ST900. With
end-to-end security, all traffic is blocked except that from
other secure ST900 devices so there is no unencrypted link on
any message.

The service uses 128-bit encryption keys with AES and the ANSI
X9.63 key management standard for symmetrical keys. The National
Security Agency has approved AES with 128-bit keys for use up to
secret classification. The key on each device is automatically
changed every 30 days or after 5,000 messages. The initial key
generation and exchange takes about eight minutes. Subsequent
key changes take two or three minutes.

Each device also is password protected with an eight-character
alphanumeric password.

?It was tough to build the AES encryption into the device,?
Barnes said. ?It is not done through add-on hardware.?

After buying the ST900, there?s no extra charge for the device-
level service. End-to-end service incurs an additional fee.

? 1996-2004 Post-Newsweek Media, Inc. All Rights Reserved.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lindac at dimacs.rutgers.edu  Wed Oct 27 12:36:17 2004
From: lindac at dimacs.rutgers.edu (Linda Casals)
Date: Wed, 27 Oct 2004 12:36:17 -0400 (EDT)
Subject: [Publicity-list] DIMACS Workshop on Mobile and Wireless Security
Message-ID: <200410271636.MAA08871@dimacs.rutgers.edu>


*************************************************
     
DIMACS Workshop on Mobile and Wireless Security 
          
     November 3 - 4, 2004
     DIMACS Center, Rutgers University, Piscataway, NJ

Organizers: 
      Bill Arbaugh, University of Maryland, waa at cs.umd.edu 
     
Presented under the auspices of the Special Focus on Communication
Security and Information Privacy.


    ************************************************

The rapid growth of both voice and data wireless communications has
resulted in several serious security problems in both the voice and 
data spaces. Unfortunately, many of the early security mistakes made 
with wireless voice communications were repeated with data
communications, i.e. the use of flawed authentication and
confidentiality algorithms. For example, the standards committee for 
802.11 left many of the difficult security issues such as key
management and a robust authentication mechanism as open problems. 
This has led many organizations to use either a permanent fixed
cryptographic variable or no encryption with their wireless networks. 
Since wireless networks provide an adversary a network access point
that is beyond the physical security controls of the organization, 
security can be a problem. Similarly, attacks against WEP, the
link-layer security protocol for 802.11 networks can exploit design 
failures to successfully attack such networks. This workshop will 
focus on addressing the many outstanding issues that remain in
wireless cellular and WLAN networking such as (but not limited to):
Management and monitoring; ad-hoc trust establishment; secure roaming
between overlay networks; availability and denial of service
mitigation; and network and link layer security protocols. We will 
seek to extend work on ad hoc networking from a non-adversarial
setting, assuming a trusted environment, to a more realistic setting
in which an adversary may attempt to disrupt communication. We will
investigate a variety of approaches to securing ad hoc networks, in 
particular ways to take advantage of their inherent redundancy 
(multiple routes between nodes), replication, and new cryptographic 
schemes such as threshold cryptography.

**************************************************************

Workshop Program:

Wednesday, November 3, 2004

 9:00 - 10:00  Breakfast and Registration

10:00 - 10:15  Welcome and Overview of Program	
               Fred Roberts, DIMACS Director

10:15 - 11:00  Wireless Authentication Overview	
               William Arbaugh

11:00 - 11:45  Role of Authorization in Wireless Network Security	
               Pasi Eronen, Nokia

11:45 - 12:30  Network Access Control Schemes Vulnerable to 
               Covert Channels	
               Florent Bersani

12:30 -  2:00  Lunch	

 2:00 -  2:45  802.11 Authentication and Keying Requirements
               Jesse Walker, Intel 
 
 2:45 -  3:30  Secure and Efficient Network Access
               Jari Arkko, Ericsson
 
 3:30 -  4:00  Break	

 4:00 -  5:00  Extending the GSM/3G Key Infrastructure
               Scott Guthery, CTO Mobile-Mind, Inc.

 5:00	       Social Event

Thursday, November 4, 2004

 8:30 -  9:00  Breakfast and Registration	
 
 9:00 -  9:45  Wireless Security and Roaming Overview	
               Nidal Aboudagga, UCL

 9:45 - 10:30  A Proposal for Next Generation Cellular Network 
               Authentication and Authorization Architecture
               James Kempf, DoCoMo USA Labs

10:30 - 11:00  Break	

11:00 - 11:45  Threshold Cryptography and Wireless Roaming
               Dan Geer and Moti Yung

11:45 - 12:30  Securing Wireless Localization	
               Zang Li, Rutgers

12:30 -  2:00  Lunch	

 2:00 -  3:30  Discussion Period- how to move forward, hard problems?	
               William Arbaugh

 3:30	       Closing

**************************************************************
Registration:

Pre-registration deadline: October 27, 2004

Please see website for registration information.

*********************************************************************
Information on participation, registration, accomodations, and travel 
can be found at:

http://dimacs.rutgers.edu/Workshops/MobileWireless/

   **PLEASE BE SURE TO PRE-REGISTER EARLY**

********************************************************************

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Wed Oct 27 22:50:28 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Wed, 27 Oct 2004 22:50:28 -0400
Subject: Europe opts for biometric passports
Message-ID: <p0611040cbda60ecc8c72@[66.149.49.5]>

<http://news.com.com/2102-1012_3-5429679.html?tag=st.util.print>

CNET News

 Europe opts for biometric pasports
 By Lars Pasveer
 http://news.com.com/Europe+opts+for+biometric+pasports/2100-1012_3-5429679.html


 Story last modified October 27, 2004, 5:56 PM PDT


Ministers for European Union member states agreed on Tuesday to adopt
biometric passports.

The first biometric passports are set to arrive in 18 months and initially
will record the facial characteristics of the bearer.

 In three years, European travelers will also have to provide a fingerprint
for the passport. The facial and fingerprint data will be stored on an
embedded chip, along with a digital copy of the bearer's photo.

 The decision, made at a meeting of interior ministers in Luxembourg, is
not yet final. Austria, Finland and the Netherlands have voiced minor
concerns about the proposal, but they will probably not turn out to be
insurmountable obstacles.

 The European push for biometrics is heavily influenced by a United States
policy change for passports for people from "visa waiver" countries after
the Sept. 11 attacks. U.S. plans to introduce a biometric passport
requirement by this fall for these countries were widely seen as
unrealistic. However, by Oct. 26 next year, all visitors from these
countries will have to provide a machine-readable passport with biometric
data.

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From jamesd at echeque.com  Thu Oct 28 12:29:21 2004
From: jamesd at echeque.com (James A. Donald)
Date: Thu, 28 Oct 2004 09:29:21 -0700
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <p061104fbbda313067d6e@[66.149.49.5]>
References: <20041023204155.GR1457@leitl.org>
Message-ID: <4180BBF1.16561.56720DC@localhost>

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

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

    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     Fkc1LRTOk91ROlSR8FZ74DmqbH7hISIn+MSojROa
     4nrRtvxhCmqe2NdvICprDQBO78fHoQXljK45ROM2W



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From gnu at toad.com  Thu Oct 28 13:16:39 2004
From: gnu at toad.com (John Gilmore)
Date: Thu, 28 Oct 2004 10:16:39 -0700
Subject: MCI set to offer secure two-way messaging with strong encryption 
In-Reply-To: <417FB834.1060706@systemics.com> 
References: <417FB834.1060706@systemics.com>
Message-ID: <200410281716.i9SHGdLq029083@new.toad.com>

> MCI Inc. will offer secure two-way messaging through its SkyTel
> Communications subsidiary next month, encrypting wireless text
> with the Advanced Encryption Algorithm.

Note that they don't say it's "end to end" encryption:

> Messages are encrypted between the device and an encryption server
> at SkyTel?s secure network operations center.

And presumably wiretappable there.

	John

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From lynn at garlic.com  Thu Oct 28 14:21:32 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Thu, 28 Oct 2004 12:21:32 -0600
Subject: Financial identity is *dangerous*? (was re: Fake
  companies, real money)
In-Reply-To: <417D70C4.30803@systemics.com>
References: <27053945.1097697083303.JavaMail.root@louie.psp.pas.earthlink.net>
 <41764C42.24691.43BECA@localhost>
 <4177E1C8.8030807@systemics.com>
 <4179F302.6020006@whitehouse.org.nz>
 <20041023202123.GA1594@apb-laptoy.apb.alt.za>
 <417D70C4.30803@systemics.com>
Message-ID: <6.1.2.0.2.20041028114839.03345f90@mail.comcast.net>

At 03:31 PM 10/25/2004, Ian Grigg wrote:

>:-)
>
>It should be obvious.  But it's not.  A few billions
>of investment in smart cards says that it is anything
>but obvious.
>
>To be fair, the smart card investments I've been
>familiar with have been at least very well aware of
>the problem.  It didn't stop them proceeding with
>papering over the symptoms, when they should have
>gone for the underlying c
>iang

my claim about the paradigm is that during the 80s, there was start of lot 
of investment by all sorts of parties into smartcards ... targeted for the 
portable computing market niche ... where the state of the art would allow 
relatively powerful computing and memory in such chips ... but the 
technology didn't exist for portable input/output technology .... as a 
result there also had to be ISO international standards for the 
input/output stations that would interoperate with the smartcards. that 
market niche started to disappear in the early 90s with the appearance of 
portable input/output technology associated with cellphones and PDAs. by 
this time, at least several billion dollars had been invested in the 
technology.

somewhat to recoup (at least some portion of) the investment, there has 
been some searching for alternative market niches for the
technology. In the early 90s, my wife and I consulted to some agencies on 
aspects of this. one such target was emergency medical information .... a 
person could carry their complete medical records in such a form factor 
.... and in a life&death emergency .... the emergency crews could pull out 
the victims card and insert it into their locak, offline, portable display 
technology and have access to the victims complete medical records. The 
problem in this scenario was that an emergency first responder isn't likely 
to be able to make use of the victims medical records in offline manner. 
First off, if it is a real emergency ... how does a first responder do 
other than triage. Typically for anything that involves anything more 
complicated ... the first responder has to go online to "real" doctors at 
some remote location. If you have a real online environment ... to real 
(remote) doctors ... then a much better solution is to have something that 
authenticates the victim ... and the consulting doctor then has some 
mechanism for locating and retrieving the online medical records (as 
opposed to first responder being able to make sense out of a victim's 
complete medical records).

Another niche for the technology was offline financial transactions ... for 
parts of the world where online connectivity was difficult, non-existent 
and/or extremely expensive. the smartcard would contain the business rules 
and logic for performing (offline) financial transaction interacting with 
random merchant terminals. Two issues arise here .... there is a 
significant mutual suspicion (lack of trust) problem between random 
merchant terminals anywhere in the world and random consumer smartcards 
anywhere in the world; and the technology started to be deployed at a time 
when online connectivity was starting to become ubiquitous and easily 
available in most places in the world. An example is the european deployed 
stored-value (offline) smartcards in the 90s compared to the rapid market 
penetration of stored-value (online) magstripe (gift, affinity, merchant, 
etc) cards in the US .... making use of the ubiquitous nature of online 
connectivity available in the US. Again, which the availability of online 
.... the problem changes from requiring a very expensive and trusted 
distributed offline infrastructure and offline distributed business 
rules  .... to the much more simple problem of requiring (increasingly 
strong) authentication.

So the financial oriented infrastructure has seen some amount of "skimming" 
threats and exploits with the terminals and/or networks. Even if the 
smartcard paradigm is just reduced to a (dumb) chipcard that only provides 
strong authentication .... the issue is does the consumer completely 
provide their own environment ... or do they have to depend on (and trust) 
randomly located terminals at random locations around the world.

Part of the authentication issue ... is the 3-factor authentication model

* something you have
* something you know
* something you are

the "card" (or chip) provides the "something you have" piece.

in order to add "something you know" ... requires the consumer entering a 
pin or password; the issue then becomes does the consumer trust some 
randomly located pin-pad. there is a similar issue with whether the 
consumer trust their own biometric sensor or would they trust somebody 
else's biometric sensor.

a consumer owned cell phone .... could presumably provide both a consumer 
trusted pin-pad ... and w/o a whole lot of magic ... a consumer camera cell 
phone could be used for sensor for various kinds of biometric info.

some part of the issue is that the original target market niche for 
smartcards (portable computing with fixed interoperable input/output 
stations) started to evaporate after a lot of the investment had been done 
but before there was a lot of deployment and investment recovery.


--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041028/a5bd505d/attachment.html>

From rah at shipwright.com  Thu Oct 28 16:57:42 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Thu, 28 Oct 2004 16:57:42 -0400
Subject: Palladiated Handheld Security Spec
Message-ID: <p0611049fbda70d7b3eb4@[66.149.49.5]>

<http://www.eweek.com/print_article/0,1761,a=138221,00.asp>

EWeek




'Palladium' Echoes in New Handheld Security Spec


October 27, 2004
 By   Mark Hachman


 Intel, IBM and NTT DoCoMo have released a specification to create a
"trusted mobile platform," which appears to take the foundation of
Microsoft's own trust initiative, "Palladium," into the mobile space.

 The three companies placed the Trusted Mobile Platform specification on
the Internet for public review. An executive at Santa Clara, Calif.-based
Intel said the company hopes to have TMP products on the market by 2005,
although the timing will be heavily dependent on OEM participation.

 ADVERTISEMENT

The problem is that, as of now, the TMP group does not include a
participating handset OEM, an operating-system manufacturer, a
radio-component manufacturer, an application provider or a manufacturer of
the trusted platform module (TPM) components that will be used to secure
the platform.

 The lack of these elements led one analyst to state that the triumvirate
will need many more players to achieve the critical mass it will need to
move forward. But things move quickly in the mobile space, other analysts
said, and even an aggressive 2005 launch date might not be out of reach.

 The goal is to provide a means of "trust" inside a mobile platform,
similar to the "Palladium" initiative Microsoft Corp. began floating in
2002 and later referred to as the Next Generation Secure Computing Base.


NGSCB is supposed to be a feature of Longhorn, Microsoft's next-generation
OS. In May, Microsoft said it would tweak the Palladium architecture to
make it simpler for developers to produce compatible applications.

 Like Palladium, the TMP initiative is designed to secure mobile commerce
and protect the system from viruses and/or worms designed to modify the
internal code.

 Intel's contributions are as a chip provider, while DoCoMo contributed the
"key usage scenarios" that guided the research into creating the
specification, said Jeff Krisa, director of marketing for Intel's cellular
handheld group.

 Next Page: A lack of support from key vendors.
 Intel has already placed some elements of the TMP within its "Bulverde"
wireless applications processor, known as the PXA27X family, Krisa said.

 "The level of digital rights management will be implemented on the
software level within the middleware, and will procedurally determine what
you can pass forward and save on the handset as well," Krisa said, adding
that it will be managed by IBM's WebSphere team.

 IBM contributed software "expertise," June Namioka, a spokeswoman for
IBM's Asia-Pacific headquarters in Tokyo, said in an interview. Intel's
Krisa said work focused on some of the higher-end software protocols used
by the technology.

 One analyst called IBM's involvement significant. "Enterprise wireless
apps are more of a concern for the average IT manager than for the average
consumer," said Julie Ask, a wireless analyst with Jupitermedia Corp.'s
JupiterResearch division. "The risk isn't so much in bringing down my
phone, it's hacking into my system or making sure the workers on the
factory floor can't talk to one another, which could be disastrous."

 However, the initiative currently lacks the support of a number of other
key vendors. For his part, Krisa said the 2005 launch date is "highly
dependent on other members, middleware ecosystem and OS vendors." A
representative from Symbian, a U.K.-based provider of embedded OSes, did
not return a call for comment.

 Although both the hardware and software specifications were released
Wednesday, the software document indicates that it was authored June 23.

 Analyst reaction was mixed. "Without having details, I see this '05 thing
as questionable," said Neil Strother, senior analyst with In-Stat/MDR in
Phoenix. "Even if they move quickly, I'm skeptical."

 If you want to build trust in the trust model, "you have to get the
banking guys on board," he said.

 Cliff Raskind, director of wireless enterprise strategies at Boston-based
Strategy Analytics, said his first impression was that the triumvirate
didn't have the clout that a trio of Microsoft, Intel and Cisco Systems
Inc. might have in trying to establish standards for the Wi-Fi space.
Wireless, by contrast, encompasses too many players. "You need buy-in
across the board," he said.

Click here to learn what vendors were plugging at this week's CTIA Wireless
show.

On the other hand, the life cycle for phones has shrunk to between six and
eight months, forcing handset makers and carriers alike to implement new
technology quickly or risk losing market share, analysts said. In a recent
executive study, JupiterResearch found that 30 percent of the respondents
cited poor device security as their chief barriers to adopting new wireless
devices. Thirty-one percent cited poor network security.

 "Things do move quickly in the mobile space, and Intel is very serious in
growing its communications business and putting in the marketing dollars to
do so," JupiterResearch's Ask said.


"When you announce with a carrier, that's good," Ask added. "I'm not sure
if it's going to turn into a North American thing, though, versus a
Japanese one." Asian carriers are usually on the leading edge of OS and
technology advances, she said. Other analysts pointed out that NTT DoCoMo
is a major player only in the GSM space, and a European and American
carrier would need to sign on.

 None of the analysts reached for comment said they had been briefed on the
TMP technology, which they found unusual.

 The TMP initiative creates a "boundary of trust" around some of the
central components within the handheld system. The system initially boots
from a trusted OS stored on a secure ROM, and through the applications
processor that's checked against the Trusted Platform Module, or TPM. Data
stored on removable devices such as flash cards must be securely encrypted,
and the specification also lists the SIM card, used to identify the phone
to the carrier, as a trusted device that can authenticate the user.

 Intel's Krisa said the Trusted Computing Group, which oversees the TPM
specifications, will have to come up with a derivative designed for mobile
handsets to minimize the platform's power consumption.


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From rah at shipwright.com  Thu Oct 28 18:29:03 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Thu, 28 Oct 2004 18:29:03 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies,
 real money)
In-Reply-To: <4180BBF1.16561.56720DC@localhost>
References: <20041023204155.GR1457@leitl.org>
 <4180BBF1.16561.56720DC@localhost>
Message-ID: <p061104b6bda7230b4c85@[66.149.49.5]>

At 9:29 AM -0700 10/28/04, James A. Donald wrote:
>Is there a phone that is programmable enough to store secrets
>on and sign and decrypt stuff?

I think we're getting there. We're going to need a, heh, killer ap, for it,
of course.

:-)

Cheers,
RAH

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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dan at etoan.com  Thu Oct 28 19:04:08 2004
From: dan at etoan.com (Dan Veeneman)
Date: Thu, 28 Oct 2004 19:04:08 -0400
Subject: MCI set to offer secure two-way messaging with strong
  encryption 
In-Reply-To: <200410281716.i9SHGdLq029083@new.toad.com>
References: <417FB834.1060706@systemics.com>
 <200410281716.i9SHGdLq029083@new.toad.com>
Message-ID: <6.1.2.0.2.20041028185849.07916320@mail.marcal.com>

At 01:16 PM 10/28/04, you wrote:
> > MCI Inc. will offer secure two-way messaging through its SkyTel
> > Communications subsidiary next month, encrypting wireless text
> > with the Advanced Encryption Algorithm.

This service has been available to U.S. Government customers
for at least seven years, albeit not always with AES.  SkyTel
was keenly aware that capturing and decoding their paging
traffic was well within the means of even casual hobbyists.

>Note that they don't say it's "end to end" encryption:
>
> > Messages are encrypted between the device and an encryption server
> > at SkyTel's secure network operations center.
>
>And presumably wiretappable there.

Yep.


--Dan


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From dahonig at cox.net  Fri Oct 29 02:21:33 2004
From: dahonig at cox.net (David Honig)
Date: Thu, 28 Oct 2004 23:21:33 -0700
Subject: "Scan design called portal for hackers"
Message-ID: <3.0.5.32.20041028232133.00867a30@pop.west.cox.net>


EETimes 25 Oct 04 has an article about how 
the testing structures on ICs makes them 
vulnerable to attacks.  The basic idea is
that to test a chip, you need to see inside
it; this can also reveal crypto details 
(e.g., keys) which compromise the chip.  

This has been known to us with an interest
in both crypto and IC design for some time,
but its nice to see it exposed in the public
lit.  There are methods that avoid this,
such as BIST, but they are less popular.





=================================================
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted.  Really.

------

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From eugen at leitl.org  Fri Oct 29 02:55:35 2004
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 29 Oct 2004 08:55:35 +0200
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
In-Reply-To: <4180BBF1.16561.56720DC@localhost>
References: <20041023204155.GR1457@leitl.org> <4180BBF1.16561.56720DC@localhost>
Message-ID: <20041029065535.GQ1457@leitl.org>

On Thu, Oct 28, 2004 at 09:29:21AM -0700, James A. Donald wrote:

> Is there a phone that is programmable enough to store secrets 
> on and sign and decrypt stuff?

Er, it has been a while since you bought a new mobile, right?
About all of them have several MBytes memory, and run Java. Some Motorolas
run Linux. The better smart phones are pretty beefy PDAs.
 
> The ideal crypto device would be programmed by burning new 
> proms, thus enabling easy reprogramming, while making it 
> resistant to trojans and viruses. 

The problem with modern mobiles that their security is of the cargo
cult/snake oil variety. Only a question of time before the first MMS worm
wipes out all Nokias, or something.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07078, 11.61144            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org         http://nanomachines.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041029/572a3ddb/attachment.pgp>

From rah at shipwright.com  Fri Oct 29 09:26:39 2004
From: rah at shipwright.com (R.A. Hettinga)
Date: Fri, 29 Oct 2004 09:26:39 -0400
Subject: [ISN] Secret Service busts online organized crime ring
Message-ID: <p0611043abda7f55a9831@[66.149.49.5]>


--- begin forwarded text


Date: Fri, 29 Oct 2004 03:31:38 -0500 (CDT)
From: InfoSec News <isn at c4i.org>
To: isn at attrition.org
Subject: [ISN] Secret Service busts online organized crime ring
Reply-To: isn at c4i.org
List-Id: InfoSec News <isn.attrition.org>
List-Archive: <http://www.attrition.org/pipermail/isn>
List-Post: <mailto:isn at attrition.org>
List-Help: <mailto:isn-request at attrition.org?subject=help>
List-Subscribe: <http://www.attrition.org/mailman/listinfo/isn>,
	<mailto:isn-request at attrition.org?subject=subscribe>
Sender: isn-bounces at attrition.org

http://www.computerworld.com/securitytopics/security/story/0,10801,97017,00.html

By Dan Verton
OCTOBER 28, 2004
COMPUTERWORLD

In what it called an "Information Age undercover investigation," the
U.S. Secret Service today announced that it has arrested 28 people
from eight U.S. states and six countries allegedly involved in a
global organized cybercrime ring.

Charges filed against the suspects include identity theft, computer
fraud, credit card fraud and conspiracy.

The investigation, code-named Operation Firewall, resulted in what the
Secret Service described as a significant disruption of organized
criminal activity online that was targeting the financial
infrastructure of the U.S. The suspects are alleged to have
collectively trafficked in at least 1.7 million stolen credit card
numbers.

Financial institutions have estimated their losses associated with the
suspects targeted by the investigation to be more than $4.3 million.

"Led by the Secret Service Newark Field Office, investigators from
nearly 30 domestic and foreign Secret Service offices and their global
law enforcement counterparts have prevented potentially hundreds of
millions of dollars in loss to the financial and hi-tech communities,"
Secret Service Director W. Ralph Basham said in a statement. "These
suspects targeted the personal and financial information of ordinary
citizens, as well as the confidential and proprietary information of
companies engaged in e-commerce."

Operation Firewall began in July 2003 and quickly evolved into a
transnational investigation of global credit card fraud and online
identity theft. The underground criminal groups have been identified
as Shadowcrew, Carderplanet and Darkprofits. The organizations
operated Web sites used to traffic counterfeit credit cards and false
identification information and documents. The groups allegedly used
the sites to share information on how to commit fraud and sold the
stolen information and the tools needed to commit such crimes.

International law enforcement organizations that took part in the
investigation and arrests included the U.K.'s National Hi-Tech Crimes
Unit, the Vancouver Police Department's Financial Crimes Section, the
Royal Canadian Mounted Police and Europol.

Officials in Bulgaria, Belarus, Poland, Sweden, the Netherlands and
Ukraine also were involved.



_________________________________________
Open Source Vulnerability Database (OSVDB) Everything is Vulnerable -
http://www.osvdb.org/

--- end forwarded text


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

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ptrei at rsasecurity.com  Fri Oct 29 09:53:51 2004
From: ptrei at rsasecurity.com (Trei, Peter)
Date: Fri, 29 Oct 2004 09:53:51 -0400
Subject: Financial identity is *dangerous*? (was re: Fake companies, real money)
Message-ID: <017630AA6DF2DF4EBC1DD4454F8EE297161829@rsana-ex-hq1.NA.RSA.NET>

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 majordomo at metzdowd.com


From lynn at garlic.com  Fri Oct 29 09:55:07 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Fri, 29 Oct 2004 07:55:07 -0600
Subject: Financial identity is *dangerous*? (was re: Fake
  companies, real money)
In-Reply-To: <4180BBF1.16561.56720DC@localhost>
References: <20041023204155.GR1457@leitl.org>
 <4180BBF1.16561.56720DC@localhost>
Message-ID: <6.1.2.0.2.20041029073353.03323f70@mail.comcast.net>

At 10:29 AM 10/28/2004, James A. Donald wrote:
>Is there a phone that is programmable enough to store secrets
>on and sign and decrypt stuff?
>
>The ideal crypto device would be programmed by burning new
>proms, thus enabling easy reprogramming, while making it
>resistant to trojans and viruses.


there are a couple different trust relationships ... the issue of the user 
trusting the keyboard/terminal ... and the issue of the relying party 
trusting the keyboard/terminal.

The FINREAD terminal ... misc. (EU) finread references:
http://www.garlic.com/~lynn/subpubkey.html#finread

supposedly is certified as an stand-alone external keypad and display that 
can't (very difficult) in being hacked. the financial scenario is that the 
display can be trusted to display the amount being approved .... the user 
puts in his card and enters their pin/password. The pin-pad is certified as 
not being subject to virus keyloggers (that you might find if a PC keyboard 
was being used).

For the relying party (say an online financial institution) ... the user 
putting their card into the reader ... and the card generating some unique 
value ... would indicate to the relying party "something you have" 
authentication. The user entering a PIN can both indicate "something you 
know" authentication as well as implying that the user aggrees/approves 
with the value in the display.

Note that the implied agreement/approval ... in not just dependent on the 
user entering the PIN ... but also on the certification of the terminal ... 
that the terminal doesn't accept the PIN until after the certified terminal 
displays the correct value (i.e. there is a certified business process 
sequence).

The entering of the PIN can also involving transmitting some form of the 
PIN to the relying party ... and/or the PIN is passed to the smartcard/chip 
... and the chip is known to only operate in the appropriate manner when 
the correct PIN is entered. In this later case, the relying party doesn't 
actually have knowledge of the "something you know" authentication .... but 
the relying party can infer it based on knowing the certified business 
process operation of all of the components.

Lets say the unique value provided by the smartcard is some form of digital 
signature ... and the relying party infers from the correct digitial 
signature "something you have" authentication. There is still the trust 
issue between the relying party and the terminal used by the user .... 
which may also require that the (certified eu finread) terminal also 
performs a digital signature .... in order for the relying party to be able 
to trust that it really was a terminal of specific characteristics ... as 
opposed to some counterfeit or lower-trusted terminal.

There is still the issue of the user trusting such a terminal. If the 
terminal belongs to the user .... in the user physical home space .... then 
there isn't as much of a trust issue regarding the user trusting the terminal.

The problem arises for the user if they are faced with using a terminal in 
some random, unsecured location some place in the world. Even in the 
situation where a relying party receives a valid transaction with a valid 
digital signature from a certified, known finread terminal ... there are 
still a number of MITM attacks on finread terminals that might be located 
in unsecured locations (various kinds of overlays and/or intermediate boxes 
capable of performing keylogging and/or modified display presentation).

The personal cellphone and/or PDA ... with user "owned" display and key 
entry .... is a countermeasure to various kinds of MITM attacks on 
terminals in public &/or unsecured locations
(user has no way of easily proofing that they aren't faced with some form 
of compromised terminal environment).



--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20041029/9172661a/attachment.html>

From lynn at garlic.com  Sat Oct 30 12:36:49 2004
From: lynn at garlic.com (Anne & Lynn Wheeler)
Date: Sat, 30 Oct 2004 10:36:49 -0600
Subject: Adding reliability and trust to smartcards
Message-ID: <6.1.2.0.2.20041030102747.033b0100@mail.comcast.net>

IST Results -   Adding reliability and trust to smartcards
http://istresults.cordis.lu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/70511

of course ... reliability and trust is more than just the smartcards ... it 
assurance and trust related to the smartcard infrastructre ... not just the 
cards themselves.

recent posting on eal5 evaluation, somewhat related
http://www.garlic.com/~lynn/2004m.html#41 EAL5

other parts of the thread
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004m.html#50 EAL5

semi-related posts about infrastructure
http://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is 
*dangerous*? (was re: Fake companies, real money)
http://www.garlic.com/~lynn/aadsm18.htm#40 Financial identity is 
*dangerous*? (was re: Fake companies, real money)






--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
   
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ben at algroup.co.uk  Sat Oct 30 12:40:00 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Sat, 30 Oct 2004 17:40:00 +0100
Subject: [off-topic, but not by ukcrypto standards] ukcrypto-moderated pre-moderators
 needed
Message-ID: <4183C3E0.2030905@algroup.co.uk>

OK, since my previous attempt to create a lower volume 
ukcrypto-like-thing failed, I have concluded that the only way to handle 
the problem is to produce a moderated version of ukcrypto. I know for 
sure there's demand for this, but I also know that the volume is too 
high for traditional moderation methods (at least too high for _me_ to 
use traditional moderation).

So, I'm going to try doing this a different way. What I want is 
volunteers who will undertake to, when it is convenient, sift through 
the currently unsifted-through postings to ukcrypto and choose 
candidates for moderation (and rejection). This will be done via an IMAP 
server, so volunteers need to have an email client that is capable of 
handling shared IMAP folders without frying its brains. If potential 
volunteers are in doubt as to whether they qualify, get in touch and 
we'll figure it out.

To explain a little more clearly what is entailed... there will be a 
folder with a copy of all ukcrypto mail in it. Volunteers will examine 
this and, for each message, do one of three things:

a) Leave it where it is (when in doubt)

b) Move it to a "rejected" folder

c) Move it to a "premoderation" folder

I will then do final moderation on the contents of the premoderation 
folder (to be clear: I'll also do premoderation, just like everyone else).

The idea behind this is that the load will be spread over the 
volunteers, so each one will only have to deal with a fraction of the 
total volume, _and_ moderation will be done in a convenient and familiar 
fashion, with threading and all that good stuff.

I'm copying this to Perry's list because I'm sure there are people who 
might like to read the output of this process (and might, therefore, 
volunteer as premoderators), but are not on ukcrypto because of the 
volume. Please feel free to forward this to other lists/individuals that 
might be interested.

Pre-moderators, please apply directly to me.

Discussion/questions can go wherever you prefer.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com


From ben at algroup.co.uk  Sat Oct 30 17:22:45 2004
From: ben at algroup.co.uk (Ben Laurie)
Date: Sat, 30 Oct 2004 22:22:45 +0100
Subject: [off-topic, but not by ukcrypto standards] ukcrypto-moderated
 pre-moderators needed
In-Reply-To: <BDA9B9C1.70B9A%zenadsl6186@zen.co.uk>
References: <BDA9B9C1.70B9A%zenadsl6186@zen.co.uk>
Message-ID: <41840625.1010004@algroup.co.uk>

Peter Fairbrother wrote:
> Ben Laurie wrote:
> 
> 
>>OK, since my previous attempt to create a lower volume
>>ukcrypto-like-thing failed, I have concluded that the only way to handle
>>the problem is to produce a moderated version of ukcrypto. I know for
>>sure there's demand for this, but I also know that the volume is too
>>high for traditional moderation methods (at least too high for _me_ to
>>use traditional moderation).
> 
> 
> I have a question. What do you think is on topic?
> 
> 
> The original charter, as I understand it, was to discuss UK legislation
> relating to cryptography - which is fine, but very little is happening in
> that area right now, and there would be virtually no posts.

I would include privacy and anonymity as well as cryptography. I'm open 
to persuasion for other topics.

Killing time isn't one of them.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com