SHA-1 collisions now 2^52
"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.)
From: Zooko O'Whielacronx 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 attac
SHA-1 collisions now at 2^{52}?
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
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
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?
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
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 instr
Brazilians hijack US military satellites
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
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 keep
Fwd: [tahoe-dev] NEWSFLASH -- Coder Goes Crazy! Laptop Versus Axe! Film At 11!
Begin forwarded message: From: Eugen Leitl 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 - From: Zooko O'Whielacronx 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 http://leitl.org";>leitl 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
"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
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=LbIul9mwYtsC&printsec=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
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
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
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
Thor Lancelot Simon 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
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
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
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
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 Apples 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?
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
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
Thor Lancelot Simon 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
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
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
> 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
On Mon, 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 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}?
Eric Rescorla 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
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
On Sat, Mar 14, 2009 at 3:16 AM, Travis 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}?
On 2009 Apr 30, at 4:31 , Perry E. Metzger wrote:
Eric Rescorla 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}?
On Apr 30, 2009, at 4:31 PM, Perry E. Metzger wrote:
Eric Rescorla 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}?
Greg Rose 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
