SHA-1 collisions now 2^52

2009-04-30 Thread Dustin D. Trammell
Until now, the best complete differential path (to our knowledge)
has complexity 2^63

The new path presented has complexity 2^52 - a significant reduction.

Practical collisions are within resources of a well funded organisation.

We are continuing our search for differential paths where the
boomerang attack can be used with maximum effect.

Paper will appear on eprint soon.

http://ping.fm/uCVUM

-- 
Dustin D. Trammell
Security Researcher
BreakingPoint Systems, Inc.


signature.asc
Description: This is a digitally signed message part


[tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)

2009-04-30 Thread Eugen Leitl
From: Zooko O'Whielacronx zo...@zooko.com
Subject: [tahoe-dev] SHA-1 broken! (was: Request for hash-dependency in
Tahoe security.)
To: nejuc...@gmail.com, tahoe-...@allmydata.org
Date: Wed, 29 Apr 2009 15:59:05 -0600
Reply-To: tahoe-...@allmydata.org

On Apr 29, 2009, at 11:51 AM, Nathan wrote:

 http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

Wow!  These slides say that they discovered a way to find collisions  
in SHA-1 at a cost of only 2^52 computations.  If this turns out to  
be right (and the authors are respected cryptographers -- the kind of  
people who really hate to be wrong about something like this) then it  
is very exciting!  SHA-1 was already known to be vulnerable to attack  
by a moderately well-funded organization such as a national security  
agency, national military, corporation, or organized criminal group.   
Now it turns out that finding SHA-1 collisions is in the reach of a  
dedicated hobbyist or an eccentric genius [1].  Let's put a rough  
number on it.  I might be a little bit off, but you can build a  
COPACOBANA machine for about $10,000 [2], and it can brute-force a 56- 
bit DES key in about six and a half days.  2^52 SHA-1 operations  
should take roughly the same amount of time and money.  As another  
example I guess that distributed computation engines [3] and botnets  
[4] might be able to generate a SHA-1 collision in seconds.

Plus of course the amplifying effects of birthday attacks and rainbow  
tables and so on mean that the longer you keep your COPACOBANA or  
your botnet generating SHA-1 collisions, the more SHA-1 users around  
the world become vulnerable to you. So basically, if these slides are  
right then relying on SHA-1 collision-resistance has been revealed as  
a major vulnerability!

Almost all hash functions in civilian, open use are either MD5 or  
SHA-1.  For example, decentralized revision control tools such as  
monotone, git, and hg rely on SHA-1.  Interesting times!

As Shawn already correctly pointed out (and as Nathan probably  
already knew), Tahoe doesn't use SHA-1, so we're not affected by this  
new discovery.  Tahoe-LAFS uses SHA-256 (in the double-hashing mode  
suggested by Ferguson and Schneier and named SHA-256d).  We also  
add our own tagging and salting prefix to avoid certain problems.  We  
aren't currently vulnerable to hash collision attacks, and we plan  
never to get into that position (about which more below).


Nonetheless, it would be a very good exercise to spell out what sorts  
of problems could result if attackers could violate what sorts of  
properties of the hash function(s) used in Tahoe.  The basic uses of  
secure hashes in Tahoe are for integrity-checking of immutable files  
and for digital signatures on mutable files and directories.

If an attacker could generate two different inputs which yielded the  
same hash output (that is, to find a hash collision), then they  
could give you a single immutable file cap that produced two (or  
more) different files when you used it to download the file.  We  
believe that nobody is currently able to do that, so currently if  
someone gives you an immutable file cap, you can rely on there being  
at most one file which can be downloaded using that cap.

For mutable files it is even safer.  If an attacker could find an  
input which yielded the same output as someone *else*'s input (that  
is, to find a second pre-image), then that attacker could write  
changes to a mutable file or directory that they were not authorized  
to write to.  Finding a second pre-image is probably much harder than  
finding a collision -- for example nobody has yet figured out how to  
find a second pre-image in SHA-1.  That's why I say it is even  
safer.  You already assume that the person who can write to a mutable  
file can make it so that two or more different file contents would be  
downloaded from using the same mutable-file read cap, but for  
immutable files we hold them to a higher standard and prevent even  
the original uploader of the immutable file from being able to make  
more than one file that matches the immutable-file read cap.

There are a lot more details of how Tahoe uses hash functions that I  
would be happy to work out when I have time, but those are the most  
important ones, and the immutable file caps are the most likely to  
turn out to be vulnerable.  (Although, as I've said, even the  
immutable file caps are extremely unlikely to be vulnerable.)


(Hm, this puts an interesting twist on Vincent and Nathan's idea of  
layering Mercurial-or-Bazaar on top of Tahoe.  Tahoe uses stronger  
cryptography (and also more flexible cryptography, by the way), so if  
you have uploaded your Mercurial repository to Tahoe then even when  
SHA-1 turns out to be weak (as it has), you can still rely on the  
integrity of your repository.)


 ps: For the case of Merkel Trees, are any security guarantees
 preserved in the face of hash collision 

SHA-1 collisions now at 2^{52}?

2009-04-30 Thread Eric Rescorla
McDonald, Hawkes and Pieprzyk claim that they have reduced the collision
strength of SHA-1 to 2^{52}.

Slides here:
http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

Thanks to Paul Hoffman for pointing me to this.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


[ADMIN] backlog

2009-04-30 Thread Perry E. Metzger

I'm back up for air again. The message backlog will be moved out over
the next few days, not necessarily in chronological order.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Focus on Quantum Crypto in IOP New Journal of Physics issue of 04/09

2009-04-30 Thread Charles McElwain


IOP New Journal of Physics, Volume 11, April, 2009

Editorial page describing focus, with table of contents:
http://www.iop.org/EJ/abstract/1367-2630/11/4/045005/

TOC has links to freely downloadable copies of the papers.
--

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Is PGP X.509's secret weapon?

2009-04-30 Thread Peter Gutmann
I was just reading through the WiMAX PKI documentation [0]... this uses PGP to 
issue device and server X.509 certificates for use in WiMAX networks:

  Name is an identifying name for the recipient that will be used as an
  authenticated identity by the CA signing system.  This is the identifier by
  which the CA system identifies which PGP key is used to encrypt the
  deliverable certificates and keys.

  The WIMAX Forum will notify Authorized Users of the completion of their
  order via email. Certificates will be delivered as an encrypted PGP archive.
  The private key of the Authorized User's PGP key is required to decrypt it.

There's nothing technically wrong with this, it just kinda says it all for 
X.509 that you need to use PGP to get it going.  I can just see PGP Corp's new 
marketing slogan: PGP: Making X.509 possible.

(Jon, if you guys print shirts with something like this on it, I want one :-).

Peter.

[0] WiMAX Certificate Authority Users Overview, WiMAX Forum, 2008(?).

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


ANNOUNCING Tahoe-LAFS v1.4

2009-04-30 Thread zooko

ANNOUNCING Tahoe, the Least-Authority Filesystem, v1.4

The allmydata.org team is pleased to announce the release of version
1.4.1 of Tahoe, the Lightweight-Authorization Filesystem. This is the
first release of Tahoe-LAFS which was created solely as a labor of love
by volunteers -- it is no longer funded by allmydata.com (see [1] for
details).

Tahoe-LAFS is a secure, decentralized, fault-tolerant cloud storage
system.  All of the source code is publicly available under Free
Software, Open Source licences.

This filesystem is distributed over multiple servers in such a way the
filesystem continues to operate correctly even when some of the servers
are unavailable, malfunctioning, or malicious. Here is the one-page
explanation of Tahoe's unique security and fault-tolerance properties:

http://allmydata.org/source/tahoe/trunk/docs/about.html

This is the successor to Tahoe-LAFS v1.3, which was released February
13, 2009 [2].  This is a major new release, adding garbage collection,
improved diagnostics and error-reporting, and fixing a critical
performance problem when downloading large (many GB) files.

See the NEWS file [3] and the known_issues.txt file [4] for more
information.

Besides the Tahoe core, a crop of related projects have sprung up,
including frontends for Windows and Macintosh, two front-ends written in
JavaScript, a Ruby interface, a plugin for duplicity, a plugin for
TiddlyWiki, a new backup tool named GridBackup, CIFS/SMB integration,
an iPhone app, and three incomplete frontends for FUSE. See the Related
Projects page on the wiki: [5].


COMPATIBILITY

Tahoe v1.4 is fully compatible with the version 1 series of Tahoe. Files
written by v1.4 clients can be read by clients of all versions back to
v1.0. v1.4 clients can read files produced by clients of all versions  
since
v1.0.  v1.4 servers can serve clients of all versions back to v1.0  
and v1.4

clients can use servers of all versions back to v1.0.

This is the fifth release in the version 1 series. The version 1 series
of Tahoe will be actively supported and maintained for the forseeable
future, and future versions of Tahoe will retain the ability to read
files and directories produced by Tahoe v1 for the forseeable future.

The version 1 branch of Tahoe is the basis of the consumer backup
product from Allmydata, Inc. -- http://allmydata.com .


WHAT IS IT GOOD FOR?

With Tahoe, you can distribute your filesystem across a set of servers,
such that if some of them fail or even turn out to be malicious, the
entire filesystem continues to be available. You can share your files
with other users, using a simple and flexible access control scheme.

Because this software is new, we do not categorically recommend it as
the sole repository of data which is extremely confidential or
precious.  However, we believe that erasure coding, strong encryption,
Free/Open Source Software and careful engineering make Tahoe safer than
common alternatives, such as RAID, removable drive, tape, on-line
storage or Cloud storage systems.

This software comes with extensive tests, and there are no known
security flaws which would compromise confidentiality or data integrity.
(For all currently known issues please see the known_issues.txt file
[3].)

This release of Tahoe is suitable for the friendnet use case [6] --
it is easy to create a filesystem spread over the computers of you and
your friends so that you can share disk space and files.


LICENCE

You may use this package under the GNU General Public License, version
2 or, at your option, any later version.  See the file COPYING.GPL
[7] for the terms of the GNU General Public License, version 2.

You may use this package under the Transitive Grace Period Public
Licence, version 1 or, at your option, any later version.  (The
Transitive Grace Period Public Licence has requirements similar to the
GPL except that it allows you to wait for up to twelve months after you
redistribute a derived work before releasing the source code of your
derived work.) See the file COPYING.TGPPL.html [8] for the terms of
the Transitive Grace Period Public Licence, version 1.

(You may choose to use this package under the terms of either licence,
at your option.)


INSTALLATION

Tahoe works on Linux, Mac OS X, Windows, Cygwin, and Solaris, and
probably most other systems.  Start with docs/install.html [9].


HACKING AND COMMUNITY

Please join us on the mailing list [10].  Patches are gratefully
accepted -- the RoadMap page [11] shows the next improvements that we
plan to make and CREDITS [12] lists the names of people who've
contributed to the project.  The wiki Dev page [13] contains resources
for hackers.


SPONSORSHIP

Tahoe was originally developed thanks to the sponsorship of Allmydata,
Inc. [14], a provider of commercial backup services.  Allmydata,
Inc. created the Tahoe project, and contributed hardware, software,
ideas, bug reports, suggestions, demands, and money (employing several
Tahoe hackers and instructing them to 

Brazilians hijack US military satellites

2009-04-30 Thread Peter Gutmann
The whole story's at:

http://www.wired.com/politics/security/news/2009/04/fleetcom

it appears that Brazilians wanting to communicate on the cheap are using US
FLTSATCOM links to talk to each other.  This works because the communication
channel was open, not encrypted, lots of people used it to talk to each other
(later they talk about hearing encrypted military voice comms, so I assume
they mean that there's no access control, not necessarily encryption).
Truckers use it because you get better quality voice than with CB. Drug
dealers use it to coordinate operations, rogue loggers use it to warn of raids
by the authorities.  As the story says Until [they get upgraded to use
crypto], the military is still using aging FLTSAT and UFO satellites - and so
are a lot of Brazilians.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Mission Impossible: The Code Even the CIA Can't Crack

2009-04-30 Thread Eugen Leitl

http://www.wired.com/print/science/discoveries/magazine/17-05/ff_kryptos 

Mission Impossible: The Code Even the CIA Can't Crack

By Steven Levy Email 04.20.09

The sculpture named Kryptos at CIA headquarters contains a secret message ?
but not even the agency's brightest can crack its code.

Photo: Adrian Gaut

The most celebrated inscription at the Central Intelligence Agency's
headquarters in Langley, Virginia, used to be the biblical phrase chiseled
into marble in the main lobby: And ye shall know the truth, and the truth
shall make you free. But in recent years, another text has been the subject
of intense scrutiny inside the Company and out: 865 characters of seeming
gibberish, punched out of half-inch-thick copper in a courtyard.

It's part of a sculpture called Kryptos, created by DC artist James Sanborn.
He got the commission in 1988, when the CIA was constructing a new building
behind its original headquarters. The agency wanted an outdoor installation
for the area between the two buildings, so a solicitation went out for a
piece of public art that the general public would never see. Sanborn named
his proposal after the Greek word for hidden. The work is a meditation on the
nature of secrecy and the elusiveness of truth, its message written entirely
in code.

Almost 20 years after its dedication, the text has yet to be fully
deciphered. A bleary-eyed global community of self-styled cryptanalysts?along
with some of the agency's own staffers?has seen three of its four sections
solved, revealing evocative prose that only makes the puzzle more confusing.
Still uncracked are the 97 characters of the fourth part (known as K4 in
Kryptos-speak). And the longer the deadlock continues, the crazier people
get.

Whether or not our top spooks intended it, the persistent opaqueness of
Kryptos subversively embodies the nature of the CIA itself?and serves as a
reminder of why secrecy and subterfuge so fascinate us. The whole thing is
about the power of secrecy, Sanborn tells me when I visit his studio, a
barnlike structure on Jimmy Island in Chesapeake Bay (population: 2). He is
6'7, bearded, and looks a bit younger than his 63 years. Looming behind him
is his latest work in progress, a 28-foot-high re-creation of the world's
first particle accelerator, surrounded by some of the original hardware from
the Manhattan Project. The atomic gear fits nicely with the thrust of
Sanborn's oeuvre, which centers on what he calls invisible forces.

With Kryptos, Sanborn has made his strongest statement about what we don't
see and can't know. He designed a piece that would resonate with this
workforce in particular, says Toni Hiley, who curates the employees-only CIA
museum. Sanborn's ambitious work includes the 9-foot 11-inch-high main
sculpture?an S-shaped wave of copper with cut-out letters, anchored by an
11-foot column of petrified wood?and huge pieces of granite abutting a low
fountain. And although most of the installation resides in a space near the
CIA cafeteria, where analysts and spies can enjoy it when they eat outside,
Kryptos extends beyond the courtyard to the other side of the new building.
There, copper plates near the entrance bear snippets of Morse code, and a
naturally magnetized lodestone sits by a compass rose etched in granite.

People call me an agent of Satan, says artist Sanborn, because I won't
tell my secret.

Photo: Adrian Gaut

The heart of the piece, though, is the encrypted text, scrambled, Sanborn
says, by a coding system that would unravel itself slowly over a period of
time.

When he began the work, Sanborn knew very little about cryptography, so he
reluctantly accepted the CIA's offer to work with Ed Scheidt, who had just
retired as head of Langley's Cryptographic Center. Scheidt himself was
serving two masters. I was reminded of my need to preserve the agency's
secrets, Scheidt says. You know, don't tell him the current way of doing
business. And don't create something that you cannot break?but at the same
time, make it something that will last a while.

Scheidt schooled Sanborn in cryptographic techniques employed from the late
19th century until World War II, when field agents had to use pencil and
paper to encode and decode their messages. (These days, of course,
cryptography is all about rugged computer algorithms using long mathematical
keys.) After experimenting with a range of techniques, including
poly-alphabetic substitution, shifting matrices, and transposition, the two
arrived at a form of old-school, artisanal cryptography that they felt would
hold off code breakers long enough to generate some suspense. The solutions,
however, were Sanborn's alone, and he did not share them with Scheidt. I
assumed the first three sections would be deciphered in a matter of weeks,
perhaps months, Sanborn says. Scheidt figured the whole puzzle would be
solved in less than seven years.

During the two years of construction, there were moments of intrigue and
paranoia, in keeping with the 

Fwd: [tahoe-dev] NEWSFLASH -- Coder Goes Crazy! Laptop Versus Axe! Film At 11!

2009-04-30 Thread R.A. Hettinga



Begin forwarded message:

From: Eugen Leitl eu...@leitl.org
Date: April 22, 2009 1:05:51 PM GMT-04:00
To: i...@postbiota.org, cypherpu...@al-qaeda.net
Subject: [tahoe-dev] NEWSFLASH -- Coder Goes Crazy! Laptop Versus Axe!  
Film At 11!


- Forwarded message from Zooko O'Whielacronx zoo...@gmail.com  
-


From: Zooko O'Whielacronx zoo...@gmail.com
Date: Wed, 22 Apr 2009 10:56:24 -0600
To: p2p-hack...@lists.zooko.com, tahoe-...@allmydata.org
Subject: [tahoe-dev] NEWSFLASH -- Coder Goes Crazy! Laptop Versus Axe!  
Film

At 11!
Reply-To: tahoe-...@allmydata.org

Dear people of p2p-hackers and tahoe-dev:

I presented Tahoe-LAFS at CodeCon last weekend.  CodeCon's prime
directive is that every presentation has to have a live demo of
working code, and that the presenter has to be an author of that code.

For my demo, I leaned an axe against the speaker's podium, strapped
safety goggles around my neck, and then I showed three laptops on
stage, each running a Tahoe node, and then uploaded a movie file to
the Tahoe grid made up of those three nodes.  (This means the file
gets automatically encrypted, digitally signed, and erasure-coded.)
Then I explained that after uploading your movie to the Tahoe grid,
you might turn off your Tahoe node and go away.  And while you are
gone, something BAD might happen...

http://www.youtube.com/watch?v=ztbIwH7gz7o

I've also embedded this video into my blog:

http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html

(My blog is also hosted on Tahoe, the Axe-Tolerant Storage System.)

Thanks to Jake Appelbaum for the video.

Regards,

Zooko
---
Tahoe, the Least-Authority Filesystem -- http://allmydata.org
store your data: $10/month -- http://allmydata.com/?tracking=zsig
I am available for work -- http://zooko.com/risumi.html
___
tahoe-dev mailing list
tahoe-...@allmydata.org
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev

- End forwarded message -
--
Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Microsoft Windows Cryptographic Next Generation SDK 2.0 Released

2009-04-30 Thread Dustin D. Trammell
The CNG SDK contains documentation, code, and tools designed to help
you develop cryptographic applications and libraries targeting the
Windows Vista SP1, Windows Server 2008 R2, and Windows 7 Operating
Systems.

http://www.microsoft.com/downloads/details.aspx?FamilyId=1EF399E9-B018-49DB-A98B-0CED7CB8FF6F

-- 
Dustin D. Trammell
Security Researcher
BreakingPoint Systems, Inc.


signature.asc
Description: This is a digitally signed message part


Some old works

2009-04-30 Thread Steven M. Bellovin
While poking around Google Books, I stumbled on the following two
references that might be of interest to this list.  The first is cited
by Kahn.

\emph{The Military Telegraph During the Civil War in the United States:
With an Exposition of Ancient and Modern Means of Communication,
and of the Federal and Confederate Cipher Systems ; Also a Running
Account of the War Between the States}
By William Rattle Plum
Published by Jansen, McClurg  Company, 1882
http://books.google.com/books?id=trpBIAAJ

Secret Writing
The Century
Published by The Century Co., 1913
http://books.google.com/books?id=LbIul9mwYtsCprintsec=titlepage#PPA83,M1



--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Fully Homomorphic Encryption Using Ideal Lattices

2009-04-30 Thread R.A. Hettinga

Liberated from LiveJournal :-):


Title: Fully Homomorphic Encryption Using Ideal Lattices
Speaker: Craig Gentry, Stanford University
Time/Place: 11 am, 18 March, Wozniak Lounge
[Ed. note: 4th floor, Soda Hall, UC Berkeley]

Abstract:
We propose a fully homomorphic encryption scheme -- i.e., a scheme  
that

allows one to evaluate circuits over encrypted data without access to
the decryption function. First, we provide a general preliminary
result -- that, to construct an encryption scheme that permits
evaluation of arbitrary circuits, it suffices to construct an
encryption scheme that can evaluate (slightly augmented versions of)
its own decryption circuit; we call such a scheme bootstrappable.
Next, we provide a bootstrappable public key
encryption scheme using ideal lattices.


Cheers,
RAH

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


A reunion at Bletchley Park

2009-04-30 Thread Steven M. Bellovin
http://www.google.com/hostednews/ap/article/ALeqM5jFmxwZmt8V4URihSIugJroZE4yKgD974J72O0


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk subversion standards released

2009-04-30 Thread Thor Lancelot Simon
On Sat, Mar 07, 2009 at 05:40:31AM +1300, Peter Gutmann wrote:

 Given that, when I looked a couple of years ago, TPM support for
 public/private-key stuff was rather hit-and-miss and in some cases seemed to
 be entirely absent (so you could use the TPM to wrap and unwrap stored private
 keys

But this, itself, is valuable.  Given trivial support in the operating system
kernel, it eliminates one of the most common key-theft attack vectors
against webservers.

I must admit I'm curious whether the TPM vendors are licensing the relevant
IBM patent on what amounts to any wrapping of cryptographic keys using
encryption - I can only assume they are.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk subversion standards released

2009-04-30 Thread Peter Gutmann
Thor Lancelot Simon t...@rek.tjls.com writes:
On Sat, Mar 07, 2009 at 05:40:31AM +1300, Peter Gutmann wrote:
 Given that, when I looked a couple of years ago, TPM support for
 public/private-key stuff was rather hit-and-miss and in some cases seemed to
 be entirely absent (so you could use the TPM to wrap and unwrap stored 
 private
 keys

But this, itself, is valuable.  Given trivial support in the operating system
kernel, it eliminates one of the most common key-theft attack vectors against
webservers.

Kent would be the one to answer this definitively, but the docs on the web
page talk about using OpenSSL to change the password on the stored keys,
without (apparently) needing the TPM, which seems a bit odd.

In any case though, how big a deal is private-key theft from web servers?
What examples of real-world attacks are there where an attacker stole a
private key file from a web server, brute-forced the password for it, and then
did... well, what with it?  I don't mean what you could in theory do with it,
I mean which currently-being-exploited attack vector is this helping with?

This does seem like rather a halfway point to be in though, if you're not
worried about private-key theft from the server then do it in software, and if
you are then do the whole thing in hardware (there's quite a bit of this
around for SSL offload) rather than just one small corner of it.  If your
target market is people who are worried about theft of private key files (but
not in-memory keys) from web servers and who don't want to use hardware to
protect them and who are running a server that actually has a TPM installed
then I suspect you've limited your applicability somewhat...

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


NCSC official quits over NSA interference

2009-04-30 Thread Perry E. Metzger

Quoting:

   A top federal cybersecurity official resigned this week in a letter
   sharply critical of what he described as a power grab by the
   National Security Agency.

   Rod Beckström, director of Homeland Security's National
   Cybersecurity Center, said in his letter that NSA effectively
   controls DHS cyber efforts through detailees, technology
   insertions, and has proposed moving some functions to the agency's
   Fort Meade, Md., headquarters.

http://news.cnet.com/8301-13578_3-10191170-38.html

-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk subversion standards released

2009-04-30 Thread Thor Lancelot Simon
On Sat, Mar 07, 2009 at 07:36:25AM +1300, Peter Gutmann wrote:
 
 In any case though, how big a deal is private-key theft from web servers?
 What examples of real-world attacks are there where an attacker stole a
 private key file from a web server, brute-forced the password for it, and then
 did... well, what with it?  I don't mean what you could in theory do with it,
 I mean which currently-being-exploited attack vector is this helping with?

Almost no web servers run with passwords on their private key files.
Believe me.  I build server load balancers for a living and I see a _lot_
of customer web servers -- this is how it is.

 This does seem like rather a halfway point to be in though, if you're not
 worried about private-key theft from the server then do it in software, and if
 you are then do the whole thing in hardware (there's quite a bit of this
 around for SSL offload)

No, no there's not.  In fact, I solicited information here about crypto
accellerators with onboard persistent key memory (secure key storage)
about two years ago and got basically no responses except pointers to
the same old, discontinued or obsolete products I was trying to replace.

-- 
Thor Lancelot Simont...@rek.tjls.com
Even experienced UNIX users occasionally enter rm *.* at the UNIX
 prompt only to realize too late that they have removed the wrong
 segment of the directory structure. - Microsoft WSS whitepaper

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Destroying confidential information from database

2009-04-30 Thread Mads


I know of procedures and programs to erase files securely from disks, 
Guttman did a paper on that


What I don't know is how to securely erase information from a database.

I cannot assume that the vendor solves this matter, anyone have a clue?

Regards,

Mads Rasmussen

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Chinese hackers break iTunes gift certificate algorithm

2009-04-30 Thread John Gilmore
http://www.ilounge.com/index.php/news/comments/chinese-hackers-crack-itunes-store-gift-codes-sell-certificates/
 

Chinese hackers crack iTunes Store gift codes, sell certificates
By Charles Starrett
Senior Editor, iLounge
Published: Tuesday, March 10, 2009

A group of Chinese hackers has succeeded in cracking Apple’s algorithm  
for encoding iTunes Store Gift Certificates, and are creating  
discounted certificates using a key generator. Outdustry reports that  
a number of the codes are available on the site Taobao, with $200  
cards selling for as little as $2.60. The owner of the Taobao shop  
offering the cards admitted that the codes are created using key  
generators, and that he paid to use the hackers’ service. He also said  
that while the price of the codes has dropped steadily, store owners  
make more money as the number of customers grows.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Legalities: NSA outsourcing spying on Americans?

2009-04-30 Thread Steven M. Bellovin
The assertion occasionally comes up that since the NSA cannot legally
eavesdrop on Americans, it outsources to the UK or one of the other
Echelon countries.  It turns out that that's forbidden, too -- see
Section 2.12 of Executive Order 12333
(http://www.archives.gov/federal-register/codification/executive-order/12333.html)

Now, I'm not saying that the government or the NSA always follows the
rules; I'm simply saying that that loophole is pretty obvious and is
(officially, at least) closed.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


CSPRNG algorithms

2009-04-30 Thread Travis
I have never seen a good catalog of computationally-strong
pseudo-random number generators.  It seems that everyone tries to roll
their own in whatever application they are using, and I bet there's a
lot of waste and inefficiency and re-inventing the wheel involved.

If this true, or is there a survey somewhere?  If not, would people
like to help me create one by emailing me references to extant PRNG
definitions?

-- 
Obama Nation | It's not like I'm encrypting... it's more like I've
developed a massive entropy deficiency | 
http://www.subsubpacefield.org/~travis/ 
If you are a spammer, please email j...@subspacefield.org to get blacklisted.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk subversion standards released

2009-04-30 Thread Peter Gutmann
Thor Lancelot Simon t...@rek.tjls.com writes:

Almost no web servers run with passwords on their private key files. Believe
me.  I build server load balancers for a living and I see a _lot_ of customer
web servers -- this is how it is.

Ah, that kinda makes sense, it would parallel the experience with client-side
keys (SSH in this case since client-side PKI is virtually nonexistent) were
nearly 2/3 of all private keys were found to be stored in plaintext form on
shared machines.  This is why a security developer some years ago started
referring to the private key as the lesser-known public key :-).

(Does anyone know of any studies that have been done to find out how prevalent
this is for servers?  I can see why you'd need to do it for software-only
implementations in order to survive restarts, but what about hardware-assisted
TLS?  Is there anything like a study showing that for a random sampling of x
web servers, y stored the keys unprotected?  Are you counting things like
Windows' DPAPI, which any IIS setup should use, as protected or
unprotected?)

I solicited information here about crypto accellerators with onboard
persistent key memory (secure key storage) about two years ago and got
basically no responses except pointers to the same old, discontinued or
obsolete products I was trying to replace.

I was hoping someone else would leap in about now and question this, but I
guess I'll have to do it... maybe we have a different definition of what's
required here, but AFAIK there's an awful lot of this kind of hardware
floating around out there, admittedly it's all built around older crypto
devices like Broadcom 582x's and Cavium's Nitrox (because there hasn't been
any real need to come up with replacements) but I didn't think there'd be much
problem with finding the necessary hardware, unless you've got some particular
requirement that rules a lot of it out.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: full-disk subversion standards released

2009-04-30 Thread Thor Lancelot Simon
On Sun, Mar 15, 2009 at 12:26:39AM +1300, Peter Gutmann wrote:
 
 I was hoping someone else would leap in about now and question this, but I
 guess I'll have to do it... maybe we have a different definition of what's
 required here, but AFAIK there's an awful lot of this kind of hardware
 floating around out there, admittedly it's all built around older crypto
 devices like Broadcom 582x's and Cavium's Nitrox (because there hasn't been
 any real need to come up with replacements) but I didn't think there'd be much
 problem with finding the necessary hardware, unless you've got some particular
 requirement that rules a lot of it out.

Nitrox doesn't have onboard key memory.  Cavium's FIPS140 certified
Nitrox board-level solutions include a smartcard and a bunch of
additional hardware and software which implement (among other things)
secure key storage -- but these are a world apart from the run of the
mill Nitrox parts one finds embedded in all kinds of commonplace
devices.  They also provide an API which is tailored for FIPS140 compliance:
good if you need it, far from ideal for the common case for web servers, and
very different from the standard set of tools one gets for the bare Nitrox
platform.

There are of course similar board-level solutions using BCM582x as the
crypto core.  But in terms of cost and complexity I might as well just
use custom hardware -- I'd probably come out ahead.  And you can't just
_ignore_ performance, nor new algorithms, so eventually using very old
crypto cores makes the whole thing fail to fly.  (If moderate
performance will suffice, I note that NBMK Encryption will still sell
you the old NetOctave NSP2000, which is a pretty nice design that has
onboard key storage but lacks AES, larger SHA variants, and other modern
features).

To the extent of my knowledge there are currently _no_ generally
available, general-purpose crypto accellerator chip-level products with
onboard key storage or key wrapping support, with the exception of parts
first sold more than 5 years ago and being shipped now from old stock.

This was once a somewhat common feature on accellerators targetted at
the SSL/IPsec market.  That appears to no longer be the case.

-- 
Thor Lancelot Simont...@rek.tjls.com
Even experienced UNIX users occasionally enter rm *.* at the UNIX
 prompt only to realize too late that they have removed the wrong
 segment of the directory structure. - Microsoft WSS whitepaper

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Solving password problems one at a time, Re: The password-reset paradox

2009-04-30 Thread Ben Laurie
Steven M. Bellovin wrote:
 We've become prisoners of dogma here.  In 1979, Bob Morris and Ken
 Thompson showed that passwords were guessable.  In 1979, that was
 really novel.  There was a lot of good work done in the next 15 years
 on that problem -- Spaf's empirical observations, Klein's '90 paper on
 improving password security, Lamport's algorithm that gave rise to
 S/Key, my and Mike Merritt's EKE, many others.  Guess what -- we're not
 living in that world now.  We have shadow password files on Unix
 systems; we have Kerberos; we have SecurID; we have SSL which rules out
 the network attacks and eavesdropping that EKE was intended to counter;
 etc.  We also have web-based systems whose failure modes are not nearly
 the same.  Why do we think that the solutions are the same?  There was
 a marvelous paper at Hotsec '07 that I resent simply because the
 authors got there before me; I had (somewhat after them) come to the
 same conclusions: the defenses we've built up against password failure
 since '79 don't the problems of today's world.  We have to recognize
 the new problems before we can solve them.  (I *think* that the paper
 is at
 http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf
 but I'm on an airplane now and can't check...

That's a pretty annoying paper.

Firstly, I don't care about the average rate of account compromise for
sites that host my stuff, I only care about _my_ account. This means
that I cannot, despite their claim, write down my long, secret user ID
because if anyone ever sees it, I'm sunk because of the short password
they are advocating.

Secondly, they claim that user IDs are in practice secret, on the basis
that if they weren't, then sites would be experiencing massive DoS
attacks. To prove this claim, they cite a case where SSNs are used as
user IDs. Now, if there's one thing we know, it's that SSNs aren't even
a little bit secret. Therefore the reason there is no widepsread DoS is
because no-one wants to mount the attack.

Thirdly, they really need to learn when to use apostrophes!

Incidentally, the reason we don't use EKE (and many other useful
schemes) is not because they don't solve our problems, its because the
rights holders won't let us use them.

 But usability is *the* problem, with server and client penetration a
 close second.

On this we agree. We do have any number of decent cryptographic schemes
that would complete solve phishing. All we have to do is figure out:

a) How to show the user that he is actually using the scheme and is not
being phished.

b) Get it rolled out everywhere.

I am not holding my breath, though perhaps '09 is the year for action?

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

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 majord...@metzdowd.com


RE: Destroying confidential information from database

2009-04-30 Thread ian.farquhar
 What I don't know is how to securely erase information from a
database.

 I cannot assume that the vendor solves this matter, anyone have a
clue?

I'd say your assumption is valid.  This is not to disrespect the
database vendors, but to point out that their risk modelling is
generally significantly looser than that which would be accepted by
someone who worries about secure data erasure on storage media.

I'd strongly suggest erasing the disk on which the database is stored,
using whatever mechanism meets your security needs (ie. From a DoD
secure erase right up to the full physical destruction of the media).

Also consider erasure of any areas of the disk where data might have
been cached, including but not limited to working tables and swap.

Ian.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Destroying confidential information from database

2009-04-30 Thread Sandy Harris
On Mon, Mar 9, 2009 at 10:32 PM, Mads m...@lsitec.org.br wrote:

 I know of procedures and programs to erase files securely from disks,
 Guttman did a paper on that

Yes, but that paper is over ten years old. In the meanwhile, disk
designs and perhaps encoding schemes have changed, journaling
file systems have become much more common and, for all I
know the attack technology may have changed too.

Is there a more recent analysis or is Guttman still the
best reference?

-- 
Sandy Harris,
Quanzhou, Fujian, China

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: SHA-1 collisions now at 2^{52}?

2009-04-30 Thread Perry E. Metzger

Eric Rescorla e...@networkresonance.com writes:
 McDonald, Hawkes and Pieprzyk claim that they have reduced the collision
 strength of SHA-1 to 2^{52}.

 Slides here:
 http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

 Thanks to Paul Hoffman for pointing me to this.

This is a very important result. The need to transition from SHA-1 is no
longer theoretical.

Perry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Destroying confidential information from database

2009-04-30 Thread james hughes


On Mar 9, 2009, at 10:32 PM, Mads wrote:



I know of procedures and programs to erase files securely from  
disks, Guttman did a paper on that


What I don't know is how to securely erase information from a  
database.


If the material is that sensitive, and you only want to selectively  
delete the information, the only way is to:


1) delete the information from the database using the commercial means,
2) export the database
3) Inspect the exported data to ensure all the sensitive information  
is deleted

4) import the database to another storage system.
5) destroy (degauss, wipe) the original storage system.
6) the truly paranoid would destroy the raid controllers also (since  
it contains NVRAM)


Not trivial...

Jim

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: CSPRNG algorithms

2009-04-30 Thread Sandy Harris
On Sat, Mar 14, 2009 at 3:16 AM, Travis
travis+ml-cryptogra...@subspacefield.org wrote:
 I have never seen a good catalog of computationally-strong
 pseudo-random number generators.  It seems that everyone tries to roll
 their own in whatever application they are using, and I bet there's a
 lot of waste and inefficiency and re-inventing the wheel involved.

 If this true, or is there a survey somewhere?  If not, would people
 like to help me create one by emailing me references to extant PRNG
 definitions?

Not complete, but this encyclopedia article has some links:
http://en.citizendium.org/wiki/Random_number#Random_sequences_from_physical_phenomena
It is a wiki so if you can improve it, please do.

No doubt Wikipedia has a list as well. All the usual
crypto texts have chapters on it, too.

-- 
Sandy Harris,
Quanzhou, Fujian, China

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: SHA-1 collisions now at 2^{52}?

2009-04-30 Thread Greg Rose


On 2009 Apr 30, at 4:31 , Perry E. Metzger wrote:



Eric Rescorla e...@networkresonance.com writes:
McDonald, Hawkes and Pieprzyk claim that they have reduced the  
collision

strength of SHA-1 to 2^{52}.

Slides here:
http://eurocrypt2009rump.cr.yp.to/ 
837a0a8086fa6ca714249409ddfae43d.pdf


Thanks to Paul Hoffman for pointing me to this.


This is a very important result. The need to transition from SHA-1  
is no

longer theoretical.


It already wasn't theoretical... if you know what I mean. The writing  
has been on the wall since Wang's attacks four years ago.


BTW, it is my (our) opinion that the current attacks can't be extended  
to the SHA-2 family, due to the avalanche effect in the data  
expansion, which is significantly different to the designs of its  
ancestors. SHA-2 would need a new breakthrough.


Greg.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: SHA-1 collisions now at 2^{52}?

2009-04-30 Thread Jon Callas


On Apr 30, 2009, at 4:31 PM, Perry E. Metzger wrote:



Eric Rescorla e...@networkresonance.com writes:
McDonald, Hawkes and Pieprzyk claim that they have reduced the  
collision

strength of SHA-1 to 2^{52}.

Slides here:
http://eurocrypt2009rump.cr.yp.to/ 
837a0a8086fa6ca714249409ddfae43d.pdf


Thanks to Paul Hoffman for pointing me to this.


This is a very important result. The need to transition from SHA-1  
is no

longer theoretical.


Let me make a couple of comments, one from each side of my mouth.

* I would like to see an implementation of this result, producing a  
collision. 2^52 is a nice number, but it needs a scale. I'm not  
worried about 2^52 years. Or even seconds. I say this solely because I  
expected a practical 2^63 collision by now, and have been wondering  
about what the scale of that 2^63. I would like to see an  
implementation.


* What do you mean by no longer theoretical? The accepted wisdom on  
80-bit security (which includes SHA-1, 1024-bit RSA and DSA keys, and  
other things) is that it is to be retired by the end of 2010. The end  
of 2010 fast approacheth. If you include into development time some  
reasonable level of market adoption, one might convincingly argue that  
the end of SHA-1 ought to be shipping this summer, or certainly in the  
fall, and no later than the *start* of 2010. The need to transition  
from SHA-1 is apparent and manifest. New results merely confirm  
conventional wisdom.


Jon

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: SHA-1 collisions now at 2^{52}?

2009-04-30 Thread Perry E. Metzger

Greg Rose g...@qualcomm.com writes:
 This is a very important result. The need to transition from SHA-1
 is no longer theoretical.

 It already wasn't theoretical... if you know what I mean. The writing
 has been on the wall since Wang's attacks four years ago.

Sure, but this should light a fire under people for things like TLS 1.2.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com