From perry at piermont.com Thu Jan 1 14:45:22 2009 From: perry at piermont.com (Perry E. Metzger) Date: Thu, 01 Jan 2009 14:45:22 -0500 Subject: enigma simulator in flash Message-ID: <87vdsyvmi5.fsf@snark.cb.piermont.com> http://enigmaco.de/enigma/enigma.swf Hat Tip: Robert Hettinga -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From paul.hoffman at vpnc.org Thu Jan 1 16:37:56 2009 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Thu, 1 Jan 2009 13:37:56 -0800 Subject: Security by asking the drunk whether he's drunk In-Reply-To: <98ADB9B7-1595-45BC-926E-B35BE447CB79@lrw.com> References: <495A8DDB.4030104@sidney.com> <495A90C7.7050300@sidney.com> <98ADB9B7-1595-45BC-926E-B35BE447CB79@lrw.com> Message-ID: At 10:19 PM -0500 12/30/08, Jerry Leichter wrote: >Robert Graham writes in Errata Security (http://erratasec.blogspot.com/2008/12/not-all-md5-certs-are-vulnerable.html) that the attack depends on being able to predict the serial number field that will be assigned to a legitimate certificate by the CA. That part is true. >Only a few CA's use predictable "serial numbers" That part, I think, is wrong. I looked into this a bit earlier this month and found that most of the ones I looked at are still using sequential numbers. >- the field is actually arbitrary text If by "arbitrary text" you mean "a non-negative integer". >and need only be certainly unique among all certificates issued by a given CA. True as well. >So: The current attack is only effective against a very small number of CA's which both use MD5 *and* have predictable sequence numbers. The attack is on end users who trust a root store that has a trust anchor from *any single* CA that uses MD5 and has predictable sequence numbers. The attack lets the attacker become a subordinate CA for that CA. At that point, the attacker can issue their own certs for any purpose. >So the sky isn't falling It never does. That's why it is the sky. >- though given how hard it is to "decertify" a CA (given that the "known good" CA's are known to literally billions of pieces of software, and that hardly anyone checks CRL's - and are there even CRL's for CA's?) this is certainly not a good situation. There are not CRLs for CAs. That's why is it is a root store. Oh, and how do you create a definitive list of CAs that use MD5 in their signatures? >This also doesn't mean that, now that the door has been opened, other attacks won't follow. In fact, it's hard to imagine that this is the end of the story.... Quite right. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From marcus.brinkmann at ruhr-uni-bochum.de Fri Jan 2 12:30:07 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 02 Jan 2009 18:30:07 +0100 Subject: A History of U.S. Communications Security In-Reply-To: <49563C65.3070702@kth.se> References: <49563C65.3070702@kth.se> Message-ID: <495E4F1F.5030800@ruhr-uni-bochum.de> Pehr S?derman wrote: > Freshly declassified and a rather interesting read: > > A History of U.S. Communications Security (Volumes I and II, 1973) > David G. Boak Lectures, National Security Agency (NSA) > > http://www.governmentattic.org/2docs/Hist_US_COMSEC_Boak_NSA_1973.pdf > > (From Bruce Schneier/Governmentattic) I like the informal style of the document, it's an easy read, even if one is not an intelligence buff. In the first volume, all but the first and last chapters are redacted (what is left is an introduction and TEMPEST). The second volume is more intact, and has some history DES, and a view on public key cryptography before affordable general computers. Certainly other things of which I don't realize the significance... Some of the redactions may be easily guessable, I fancy "iron curtain", "embassy", and later "Russia" on page 97. Why do they even bother? This would be a good exercise for some student to write a program doing a dictionary attack on the text using the properties of the used font. The last page has a puzzle, an "innocent text system" (steganography). Didn't solve it yet, but I think I found the clue, a misspelling of "be advised" to "he advised". Thanks, Marcus --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From len.sassaman at esat.kuleuven.be Fri Jan 2 13:22:39 2009 From: len.sassaman at esat.kuleuven.be (Len Sassaman) Date: Fri, 2 Jan 2009 10:22:39 -0800 (PST) Subject: MD5 considered harmful today In-Reply-To: <20081230195106.52DEA14F6E1@finney.org> References: <20081230195106.52DEA14F6E1@finney.org> Message-ID: On Tue, 30 Dec 2008, Hal Finney wrote: > > - The attack relies on cryptographic advances in the state of the art for > finding MD5 collisions from inputs with different prefixes. These advances > are not yet being published but will presumably appear in 2009. To insert a malicious "basicConstraints CA = TRUE" these advances appear necessary; I do not believe that they are necessary for the other very similar attack (where the malicious cert is a wildcard (*) certificate). I could be wrong about this, but I also don't think that the advances in cryptography to get from chosen prefix attacks to here are anywhere near as great as were needed to get the original chosen prefix work. We can evaluate the correctness of that statement when the work is published, of course. > - The collision was found using Arjen Lenstra's PlayStation Lab and used > 200 PS3s with collectively 30 GB of memory. The attack is in two parts, > a new preliminary "birthdaying" step which is highly parallelizable and > required 18 hours on the PS3s, and a second stage which constructs the > actual collision using 3 MD5 blocks and runs on a single quad core PC, > taking 3 to 10 hours. Prof. Lenstra's PlayStation Lab is definitely impressive, but there are many ways to get the computation time needed to perform this attack, including Amazon's EC2, botnets, and other high powered computing systems. It's not *that* much computation time. > My take on this is that because the method required advances in > cryptography and sophisticated hardware, it is unlikely that it could > be exploited by attackers before the publication of the method, or > the publication of equivalent improvements by other cryptographers. If > these CAs stop issuing MD5 certs before this time, we will be OK. Once > a CA stops issuing MD5 certs, it cannot be used for the attack. Its old > MD5 certs are safe and there is no danger of future successful attacks > along these lines. As the paper notes, changing to using random serial > numbers may be an easier short-term fix. I am worried that this may be too optimistic of an outlook. This attack was known and discussed by at least two research teams for at least a year (Dan Kaminsky, Meredith L. Patterson, and I worked out the attack at the last CCC). To be fully confident in the CA infrastructure, all certificates that have delegated signing authority granted to them by a higher CA (using MD5 on the certificate in question) should be audited to ensure they are not malicious. This of course includes private certificate infrastructures, too. I would be extremely surprised if this attack had been performed prior to the original chosen prefix work being published -- but since that time, there has been plenty of opportunity for a malicious party to quietly perform this attack in the wild. --Len. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Sun Jan 4 00:30:05 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Sun, 4 Jan 2009 00:30:05 -0500 Subject: very high speed hardware RNG In-Reply-To: References: <8763l3239y.fsf@snark.cb.piermont.com> <85E08273-4D26-46C7-BBF9-E51D469ED4A8@lrw.com> Message-ID: <13C4112B-ABB1-447B-804A-265BB508303B@solarsail.hcs.harvard.edu> On Dec 30, 2008, at 5:11 PM, Jerry Leichter wrote: > This is a highly chaotic process, and after a short time, you see a > completely random-looking dispersion of dye through the liquid. > Present this to someone and any likely test will say this is quite > random. But ... if you slow turn the inner cylinder backwards - > "slowly", for both directions of turn, depending on details of the > system - the original line of dye miraculously reappears. (Laminar flow: .) -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From rabbi at abditum.com Wed Jan 7 14:35:27 2009 From: rabbi at abditum.com (Len Sassaman) Date: Wed, 7 Jan 2009 11:35:27 -0800 (PST) Subject: CodeCon 2009 Call for Presentations Message-ID: CodeCon 2009 April 17-19, 2009 San Francisco CA, USA www.codecon.org Call For Presentations CodeCon is the premier showcase of cutting edge software development. It is an excellent opportunity for programmers to demonstrate their work and keep abreast of what's going on in their community. All presentations must include working demonstrations, ideally accompanied by source code. Presentations must be done by one of the active developers of the code in question. We emphasize that demonstrations be of *working* code. We hereby solicit papers and demonstrations. * Papers and proposals due: February 15, 2009 * All Authors notified: March 1, 2009 Possible topics include, but are by no means restricted to: * community-based web sites - forums, weblogs, personals * development tools - languages, debuggers, version control * file sharing systems - swarming distribution, distributed search * security products - mail encryption, intrusion detection, firewalls * malware analysis - detection, compensation, and mitigation of emerging threats -- As a new feature this year, CodeCon will be presenting a Biohack! track. While we will continue our tradition of presenting only one talk at a time, a portion of one of the days' talks will be reserved for interesting biotechnology hacking projects. A key requirement for these presentations is ease of reproduction with minimal access to expensive laboratory equipment. Example topics include: * Purifying DNA using common household items * Developing genetically-modified bacteria in a kitchen laboratory * Using specially-designed software to assist in bioengineering * The use of simple bioengineering techniques to solve real-world problems. Ideal Biohack! Track submissions will have a strong emphasis on the "hack" portion of the talk -- in the last few years, there has been a strong growth in the community of biology hackers; we aim to bring these hackers together to discuss their techniques for inexpensive, at home experimentation in biological engineering research. -- Presentations will be 30 minutes long, with an additional 15 minutes allocated for Q&A. Overruns will be truncated. Submission details: Submissions are being accepted immediately. Acceptance dates are February 7th and March 1st. After the first acceptance date, submissions will be either accepted, rejected, or deferred to the second acceptance date. The conference language is English. The conference venue is open to all ages. Ideally, technical demonstrations should be usable by attendees with 802.11b connected devices either via a web interface, or locally on Windows, UNIX-like, or MacOS platforms. Cross-platform applications are most desirable. Biohacking demonstrations should be viewable with a presenter-provided camera, or prepared movies for projection. To submit, send mail to submissions-2009 at codecon.org including the following information: * Project name * Code track or Biohack! track * url of project home page * tagline - one sentence or less summing up what the project does * names of presenter(s) and urls of their home pages, if they have any * one-paragraph bios of presenters, optional, under 100 words each * project history, under 150 words * what makes the project novel -- how it differs from similar projects * what will be done in the project demo, under 200 words * slides to be shown during the presentation, if applicable * future plans General Chairs: Jonathan Moore and Bram Cohen Program Chair: Jered Floyd and Len Sassaman Program Committee: * Jon Callas, PGP, USA * Bram Cohen, BitTorrent, USA * Roger Dingledine, The Tor Project, USA * Jered Floyd, Permabit, USA * Ben Laurie, Google, UK * David Molnar, University of California, Berkeley, USA * Jonathan Moore, Mosuki, USA * Meredith L. Patterson, Osogato, USA * Andrew S. Peek, Integrated DNA Technologies, USA * Len Sassaman, Katholieke Universiteit Leuven, BE * Cliff Skolnick * Paul Syverson, Naval Research Laboratory, USA * [Others may be added] Sponsorship: If your organization is interested in sponsoring CodeCon, we would love to hear from you. In particular, we are looking for sponsors for social meals and parties on any of the three days of the conference, as well as sponsors of the conference as a whole and donors of door prizes. If you might be interested in sponsoring any of these aspects, please contact the conference organizers at codecon2009 at codecon.org Press policy: CodeCon provides a limited number of passes to qualifying press. Complimentary press passes will be evaluated on request. Everyone is welcome to pay the low registration fee to attend without an official press credential. Questions: If you have questions about CodeCon, or would like to contact the organizers, please mail codecon2009 at codecon.org. Please note this address is only for questions and administrative requests, and not for workshop presentation submissions. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From noah at salzman.net Wed Jan 7 20:29:43 2009 From: noah at salzman.net (Noah Salzman) Date: Wed, 7 Jan 2009 17:29:43 -0800 Subject: BIS looking for feedback on export controls Message-ID: The BIS is looking for feedback on export controls, however, this is for foreign products. It does affect US makers of cryptography products if their products are re-packaged by a foreign entity. ------------- http://www.gpo.gov/bis/fedreg/ear_fedreg.html#74fr413 01/06/09 74 FR 413 Request for Public Comment on Foreign Produced Encryption Items That are made from U.S.-origin Encryption technology or software To determine the appropriate extent and scope of U.S. export controls on foreign products that are direct products of U.S. origin encryption technology or software, BIS is considering making subject to the Export Administration Regulations (EAR) all foreign items that would be controlled for Encryption Items (?EI?) reasons under the EAR (i.e., that would be classified under ECCN 5A002 or 5D002) if they are the direct product of U.S.-origin ECCN 5E002 technology or ECCN 5D002 software. BIS is seeking information regarding the impact this change would have on both U.S. exporters of encryption technology and software and foreign manufacturers of products that are derived in part or whole from U.S.-origin encryption technology or software. Comments are due March 9, 2009. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ray at unipay.nl Thu Jan 8 04:06:33 2009 From: ray at unipay.nl (R. Hirschfeld) Date: Thu, 8 Jan 2009 10:06:33 +0100 Subject: [tmoore@seas.harvard.edu: [fc-announce] Financial Crypto February 23-26 in Barbados, Early Registration Deadline Approaching] Message-ID: <200901080906.n0896X3C003152@home.unipay.nl> From: "Tyler Moore" Subject: [fc-announce] Financial Crypto February 23-26 in Barbados, Early Registration Deadline Approaching To: fc-announce at ifca.ai Date: Wed, 7 Jan 2009 21:58:44 -0500 Call for Participation Financial Cryptography and Data Security '09 http://fc09.ifca.ai/ Thirteenth International Conference February 23-26, 2009 Accra Beach Hotel & Resort Barbados Early registration deadline approaching fast! Register by January 21 to receive a discount. For full details, visit: http://fc09.ifca.ai/registration.html Also, reserve your hotel room by January 22 in order to guarantee availability: http://fc09.ifca.ai/accommodation.html Financial Cryptography and Data Security is a major international forum for research, advanced development, education, exploration and debate regarding information assurance in the context of finance and commerce. We have assembled a vibrant program featuring 21 peer- reviewed research paper presentations, two panels (on the economics of information security and on authentication), and a keynote address by David Dagon. To view the complete program, visit: http://fc09.ifca.ai/program.html We look forward to seeing you in Barbados! Tyler Moore FC '09 General Chair _______________________________________________ fc-announce mailing list fc-announce at ifca.ai http://mail.ifca.ai/mailman/listinfo/fc-announce ---------- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From satoshi at vistomail.com Thu Jan 8 14:27:40 2009 From: satoshi at vistomail.com (Satoshi Nakamoto) Date: Fri, 09 Jan 2009 03:27:40 +0800 Subject: Bitcoin v0.1 released Message-ID: Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority. See bitcoin.org for screenshots. Download link: http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar Windows only for now. Open source C++ code is included. - Unpack the files into a directory - Run BITCOIN.EXE - It automatically connects to other nodes If you can keep a node running that accepts incoming connections, you'll really be helping the network a lot. Port 8333 on your firewall needs to be open to receive incoming connections. The software is still alpha and experimental. There's no guarantee the system's state won't have to be restarted at some point if it becomes necessary, although I've done everything I can to build in extensibility and versioning. You can get coins by getting someone to send you some, or turn on Options->Generate Coins to run a node and generate blocks. I made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical PC will be able to generate coins in just a few hours. It'll get a lot harder when competition makes the automatic adjustment drive up the difficulty. Generated coins must wait 120 blocks to mature before they can be spent. There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections. Total circulation will be 21,000,000 coins. It'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years. first 4 years: 10,500,000 coins next 4 years: 5,250,000 coins next 4 years: 2,625,000 coins next 4 years: 1,312,500 coins etc... When that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free. Satoshi Nakamoto --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From dtrammell at breakingpoint.com Thu Jan 8 19:23:47 2009 From: dtrammell at breakingpoint.com (Dustin D. Trammell) Date: Thu, 08 Jan 2009 18:23:47 -0600 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20081230195106.52DEA14F6E1@finney.org> References: <20081230195106.52DEA14F6E1@finney.org> Message-ID: <1231460627.3430.73.camel@localhost> On Tue, 2008-12-30 at 11:51 -0800, "Hal Finney" wrote: > Therefore the highest priority should be for the six bad CAs to change > their procedures, at least start using random serial numbers and move > rapidly to SHA1. As long as this happens before Eurocrypt or whenever > the results end up being published, the danger will have been averted. > This, I think, is the main message that should be communicated from this > important result. Nearly everything I've seen regarding the proposed solutions to this attack have involved migration to SHA-1. SHA-1 is scheduled to be decertified by NIST in 2010, and NIST has already recommended[1] moving away from SHA-1 to SHA-2 (256, 512, etc.). Collision attacks have already been demonstrated[2] against SHA-1 back in 2005, and if history tells us anything then things will only get worse for SHA-1 from here. By not moving directly to at least SHA-2 (until the winner of the NIST hash competition is known), these vendors are likely setting themselves up for similar attacks in the (relatively) near future. [1] http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html [2] http://www.cryptography.com/cnews/hash.html -- Dustin D. Trammell Security Researcher BreakingPoint Systems, Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pgut001 at cs.auckland.ac.nz Fri Jan 9 06:49:00 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 10 Jan 2009 00:49:00 +1300 Subject: On the topic of "Asking the drunk"... Message-ID: https://visa.com/ Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ben at links.org Fri Jan 9 09:51:11 2009 From: ben at links.org (Ben Laurie) Date: Fri, 09 Jan 2009 14:51:11 +0000 Subject: OpenPGP:SDK v0.9 released Message-ID: <4967645F.5090206@links.org> I thought people might be interested in this now somewhat-complete, BSD-licensed OpenPGP library... http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9 -- 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 majordomo at metzdowd.com From perry at piermont.com Fri Jan 9 20:12:16 2009 From: perry at piermont.com (Perry E. Metzger) Date: Fri, 09 Jan 2009 20:12:16 -0500 Subject: feds try to argue touch tone content needs no wiretap order Message-ID: <87fxjs0xsf.fsf@snark.cb.piermont.com> Just about everyone knows that the FBI must obtain a formal wiretap order from a judge to listen in on your phone calls legally. But the U.S. Department of Justice believes that police don't need one if they want to eavesdrop on what touch tones you press during the call. Those touch tones can be innocuous ("press 0 for an operator"). Or they can include personal information including bank account numbers, passwords, prescription identification numbers, Social Security numbers, credit card numbers, and so on--all of which most of us would reasonably view as private and confidential. That brings us to New York state, where federal prosecutors have been arguing that no wiretap order is necessary. They insist that touch tones cannot be "content," a term of art that triggers legal protections under the Fourth Amendment. http://news.cnet.com/8301-13578_3-10138074-38.html?part=rss&tag=feed&subj=News-PoliticsandLaw -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Victor.Duchovni at morganstanley.com Fri Jan 9 23:09:07 2009 From: Victor.Duchovni at morganstanley.com (Victor Duchovni) Date: Fri, 9 Jan 2009 23:09:07 -0500 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <1231460627.3430.73.camel@localhost> References: <20081230195106.52DEA14F6E1@finney.org> <1231460627.3430.73.camel@localhost> Message-ID: <20090110040907.GD5177@hn305c2n2.ms.com> On Thu, Jan 08, 2009 at 06:23:47PM -0600, Dustin D. Trammell wrote: > Nearly everything I've seen regarding the proposed solutions to this > attack have involved migration to SHA-1. SHA-1 is scheduled to be > decertified by NIST in 2010, and NIST has already recommended[1] moving > away from SHA-1 to SHA-2 (256, 512, etc.). Collision attacks have > already been demonstrated[2] against SHA-1 back in 2005, and if history > tells us anything then things will only get worse for SHA-1 from here. > By not moving directly to at least SHA-2 (until the winner of the NIST > hash competition is known), these vendors are likely setting themselves > up for similar attacks in the (relatively) near future. All fine and good, but no existing OpenSSL release (including 0.9.9-dev) will by default inter-operate with the resulting (SHA2) certificates. The SSL_library_init() call only initializes "ssl" ciphers and digests, which do not include SHA-2. So most SSL applications won't be able to verify the certificate signatures. One needs to call OpenSSL_add_all_algorithms() before SHA-2 signed certificates work. Bottom line, anyone fielding a SHA-2 cert today is not going to be happy with their costly pile of bits. -- Viktor. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Sat Jan 10 06:13:49 2009 From: leichter at lrw.com (Jerry Leichter) Date: Sat, 10 Jan 2009 06:13:49 -0500 Subject: On the topic of "Asking the drunk"... In-Reply-To: References: Message-ID: <9CDFD7D1-8EA1-4920-B189-5174DA3760DC@lrw.com> On Jan 9, 2009, at 6:49 AM, Peter Gutmann wrote: > https://visa.com/ I get no response. None at https://www.visa.com either. On the other hand, the US-specific site, https://usa.visa.com, responds just fine - but it redirects you to http://usa.visa.com/index.html . Try that same address with https, and it's accepted - but again redirected to the http version. That one is at least in the Visa domain. It gets a bit more complex for other regions - e.g., the Asian sites are accessible via https://www.visa-asia.com/ - but that redirects to http://www.visa-asia.com/ap/index.shtml - even though https://www.visa-asia.com/ap/index.shtml actual works! I'm guessing that Visa has country- (or perhaps region-)specific certs, which would make some sense - but the random mix of http and https addresses is pretty broken. It's not clear there's anything at visa.com that's really in need of protecting, of course. It's not a card issuer, its member banks are. Then again ... if you start from https://usa.visa.com and go to "Access Account Information", you are sent to a (non-SSL) page that claims to have links to the largest issuing banks - except that none of the "links" actually works - which I guess is appropriate, since you shouldn't be trusting them anyway! A very strange set of sites.... -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Sat Jan 10 06:42:08 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sun, 11 Jan 2009 00:42:08 +1300 Subject: On the topic of "Asking the drunk"... In-Reply-To: <9CDFD7D1-8EA1-4920-B189-5174DA3760DC@lrw.com> Message-ID: Jerry Leichter writes: >On Jan 9, 2009, at 6:49 AM, Peter Gutmann wrote: >> https://visa.com/ >I get no response. None at https://www.visa.com either. Sigh, you wait awhile to make sure it's not an intermittent thing and then as soon as you post it it stops working (or maybe someone from Visa is reading this list and took it down quickly :-). What it was doing until now was a really convincing simulation of a phishing attack, the Firefox error message was: visa.com uses an invalid security certificate. The certificate is not trusted because it is self-signed. The certificate is only valid for MIA21793WWW002.managed.cln. (Error code: sec_error_ca_cert_invalid) Unfortunately posting that bit to the list kinda lessens the effect of seeing it live. Good thing I saved a screenshot while it was still active :-). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Sat Jan 10 12:50:41 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 10 Jan 2009 12:50:41 -0500 Subject: feds try to argue touch tone content needs no wiretap order In-Reply-To: <87fxjs0xsf.fsf@snark.cb.piermont.com> References: <87fxjs0xsf.fsf@snark.cb.piermont.com> Message-ID: <20090110125041.57066973@cs.columbia.edu> On Fri, 09 Jan 2009 20:12:16 -0500 "Perry E. Metzger" wrote: > > Just about everyone knows that the FBI must obtain a formal > wiretap order from a judge to listen in on your phone calls > legally. But the U.S. Department of Justice believes that police > don't need one if they want to eavesdrop on what touch tones you > press during the call. > > Those touch tones can be innocuous ("press 0 for an operator"). Or > they can include personal information including bank account > numbers, passwords, prescription identification numbers, Social > Security numbers, credit card numbers, and so on--all of which > most of us would reasonably view as private and confidential. > > That brings us to New York state, where federal prosecutors have > been arguing that no wiretap order is necessary. They insist that > touch tones cannot be "content," a term of art that triggers legal > protections under the Fourth Amendment. > > http://news.cnet.com/8301-13578_3-10138074-38.html?part=rss&tag=feed&subj=News-PoliticsandLaw > It's very much worth reading the whole article; the author, Declan McCullagh, does a good job with the historical background. I'll add one more historical tidbit: in the late 1980s, New York courts outlawed pen register taps, because the same equipment was used to detect touch tones as was used to record full content, and thus there was no protection against law enforcement agents exceeding the court's authority. If I may wax US-legal for a moment... According to a (U.S.) Supreme Court decision (Katz v U.S. 389 US 347 (1967)), phone call content is private, which therefore brings into play the full protection of the Fourth Amendment -- judges, warrants, probable cause, etc. However, under a later ruling (Smith v Maryland 442 US 735 (1979)), the numbers you call are information that is "given" to the phone company, and hence is no longer private. Accordingly, the Fourth Amendment does not apply, and a much easier-to-get court order is all that's needed, according to statute. (I personally regard the reasoning in Smith as convoluted and tortuous, but there have been several other, similar rulings: data you voluntarily give to another party is no longer considered private, so the Fourth Amendment doesn't apply.) The legitimate (under current law) problem that law enforcement would like to solve involves things like prepaid calling cards. Suppose I use one to call a terrorist friend, via some telco. The number of the calling card provider is available to law enforcement, under a pen register order, per Smith and 18 USC 3121, the relevant legislation. The telco will help law enforcement get that number. I next dial my account number; this is in effect a "conversation" between me and the calling card provider. Getting that number requires yet a different kind of court order, I believe, but I'll skip that one for now. I next dial the number of my terrorist friend. That's the number they now want -- and per Smith, they're entitled to it, since it's a dialed number via a telecommunications provider. There is no doubt they could go to that provider and ask for such a number. However, they want to ask the telco for it -- but the telco doesn't know what is a phone number, what is an account number, what is a password for an online bank account, and what is a password for an adult conference bridge. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From b.m.m.d.weger at TUE.nl Sat Jan 10 17:32:44 2009 From: b.m.m.d.weger at TUE.nl (Weger, B.M.M. de) Date: Sat, 10 Jan 2009 23:32:44 +0100 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090110040907.GD5177@hn305c2n2.ms.com> References: <20081230195106.52DEA14F6E1@finney.org> <1231460627.3430.73.camel@localhost> <20090110040907.GD5177@hn305c2n2.ms.com> Message-ID: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> Hi Victor, > Bottom line, anyone fielding a SHA-2 cert today is not going > to be happy with their costly pile of bits. Will this situation have changed by the end of 2010 (that's next year, by the way), when everybody who takes NIST seriously will have to switch to SHA-2? The first weakness shown in MD5 was not in 2004 but in 1995. Apparently it takes a very long time before the awareness about the implications of using weakened or broken crypto has reached a sufficient level. Though I understand the practical issues you're talking about, Victor, my bottom line is different. In my view, the main lesson that the information security community, and in particular its intersection with the application building community, has to learn from the recent MD5 and SHA-1 history, is that strategies for dealing with broken crypto need rethinking. [[Maybe in the previous sentence the word "intersection" should be replaced by "union".]] Grtz, Benne de Weger PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) offering the video and audio files of the 25c3 presentation "MD5 considered harmful today", provide for integrity checking of those files their, uhm, MD5 hashes. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From hal at finney.org Sat Jan 10 21:22:01 2009 From: hal at finney.org (Hal Finney) Date: Sat, 10 Jan 2009 18:22:01 -0800 (PST) Subject: Bitcoin v0.1 released Message-ID: <20090111022201.C084C14F6E1@finney.org> Satoshi Nakamoto writes: > Announcing the first release of Bitcoin, a new electronic cash > system that uses a peer-to-peer network to prevent double-spending. > It's completely decentralized with no server or central authority. > > See bitcoin.org for screenshots. > > Download link: > http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar Congratulations to Satoshi on this first alpha release. I am looking forward to trying it out. > Total circulation will be 21,000,000 coins. It'll be distributed > to network nodes when they make blocks, with the amount cut in half > every 4 years. > > first 4 years: 10,500,000 coins > next 4 years: 5,250,000 coins > next 4 years: 2,625,000 coins > next 4 years: 1,312,500 coins > etc... It's interesting that the system can be configured to only allow a certain maximum number of coins ever to be generated. I guess the idea is that the amount of work needed to generate a new coin will become more difficult as time goes on. One immediate problem with any new currency is how to value it. Even ignoring the practical problem that virtually no one will accept it at first, there is still a difficulty in coming up with a reasonable argument in favor of a particular non-zero value for the coins. As an amusing thought experiment, imagine that Bitcoin is successful and becomes the dominant payment system in use throughout the world. Then the total value of the currency should be equal to the total value of all the wealth in the world. Current estimates of total worldwide household wealth that I have found range from $100 trillion to $300 trillion. With 20 million coins, that gives each coin a value of about $10 million. So the possibility of generating coins today with a few cents of compute time may be quite a good bet, with a payoff of something like 100 million to 1! Even if the odds of Bitcoin succeeding to this degree are slim, are they really 100 million to one against? Something to think about... Hal --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Victor.Duchovni at morganstanley.com Sat Jan 10 23:06:46 2009 From: Victor.Duchovni at morganstanley.com (Victor Duchovni) Date: Sat, 10 Jan 2009 23:06:46 -0500 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> References: <20081230195106.52DEA14F6E1@finney.org> <1231460627.3430.73.camel@localhost> <20090110040907.GD5177@hn305c2n2.ms.com> <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> Message-ID: <20090111040645.GG5177@hn305c2n2.ms.com> On Sat, Jan 10, 2009 at 11:32:44PM +0100, Weger, B.M.M. de wrote: > Hi Victor, > > > Bottom line, anyone fielding a SHA-2 cert today is not going > > to be happy with their costly pile of bits. > > Will this situation have changed by the end of 2010 (that's > next year, by the way), when everybody who takes NIST seriously > will have to switch to SHA-2? Extremely unlikely in the case of SSL/TLS and X.509 certs. There is a huge install-base of systems on which SHA-2 certs will failed SSL handshakes. When Windows XP systems are <1% of the install-base, when OpenSSL 0.9.8 is <1% of the install-base and 0.9.9 too (if the support is not added before it goes official), and all the browsers, Java libraries, ... support SHA-2, then you can deploy SHA-2 certs. I would estimate 5-8 years, if developers of all relevant mainstream implementations start to address the issue now. SHA-1 will be with us well after 2010. New applications written in 2010 will ideally support SHA-2, but SHA-1 will probably still be the default digest in many applications through 2013 or 2015. -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Sun Jan 11 07:01:36 2009 From: leichter at lrw.com (Jerry Leichter) Date: Sun, 11 Jan 2009 07:01:36 -0500 Subject: What risk is being defended against here? Message-ID: <729DDF52-8E5A-430A-BDFD-B3EE9F3369B3@lrw.com> Not cryptography, but the members of this list think in these terms, so... Just recently, my 8th-grade daughter took a school placement test. This test (the ISEE) is administered internationally. When we arrived, we learned that she would not be allowed into the test room without *one* of the following: - A photo ID - A copy of the verification letter sent to her The verification letter is actually available - even now, after the test is complete - on a web site. So ... just what risk is being defended against here? You could imagine that the verification letter is essentially a ticket - the letter itself says thats what it is - but in fact the testing locations have a complete list of who is supposed to take the test - and of course you aren't *required* to have it with you. Many such "high value" tests now require photo id's. Some go further - the LSAT's, required with law school applications, fingerprint all test-takers. (I think other, similar exams - like the MCAT's for medical school and the GMAT's for MBA programs do the same.) There's an obvious risk here: I can hire someone to take the test for me. A photo ID makes that harder and a fingerprint provides strong evidence in case any questions arise. But if I hired someone to take the ISEE in my daughter's place, presumably I could easily give them a copy of the verification letter. I suppose the *combination* of the two does work as a ticket: Either you have the actual verification letter, or you name is on the list and the photo ID proves that that's your name. Seems a bit elaborate, especially since taking over someone else's test spot can't gain you anything - the results will be sent to schools in *their* name, not yours. Besides, there's really nothing preventing you from *registering* in someone else's name to begin with. Any speculations (beyond bureaucracy at its finest)? (The actual administration of this requirement was a mess. How many kids this age - the exam actually has three levels, so the age range would be from perhaps 9 to 17 - carry, or even have, photo id's? The verification letter itself mentions, with no emphasis, that you should bring it with you on the test date - a fact not mentioned on the ISEE web site, where they tell you to bring pencils and pens and not bring calculators or cell phones. Moreover, the verification letter can arrive way before test day - 3.5 months before, in our case. Luckily, we live close to the test center, arrived early ... and were able to rush back home for my daughter's recently-acquired passport, the only photo ID she actually has. Many others were caught in the same mess; some had to leave and reschedule for another day.) -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Sun Jan 11 13:26:40 2009 From: perry at piermont.com (Perry E. Metzger) Date: Sun, 11 Jan 2009 13:26:40 -0500 Subject: What risk is being defended against here? In-Reply-To: <729DDF52-8E5A-430A-BDFD-B3EE9F3369B3@lrw.com> (Jerry Leichter's message of "Sun\, 11 Jan 2009 07\:01\:36 -0500") References: <729DDF52-8E5A-430A-BDFD-B3EE9F3369B3@lrw.com> Message-ID: <87iqolzokf.fsf@snark.cb.piermont.com> Jerry Leichter writes: > When we arrived, we learned that she would not be allowed into the > test room without *one* of the following: > > - A photo ID > - A copy of the verification letter sent to her > > The verification letter is actually available - even now, after the > test is complete - on a web site. > > So ... just what risk is being defended against here? The risk being defended against is a reprimand against some bureaucrat for not "doing enough" to maintain test integrity. By demonstrating that they have "tight procedures" etc., they can deflect blame if any sort of cheating scandal occurs. In general, most such rules are designed for JobSec, not for ActualSec. In that light, a wide variety of stupid bureaucratic behavior becomes not merely explicable but obvious. Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jamesd at echeque.com Sun Jan 11 18:29:04 2009 From: jamesd at echeque.com (James A. Donald) Date: Mon, 12 Jan 2009 09:29:04 +1000 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090111040645.GG5177@hn305c2n2.ms.com> References: <20081230195106.52DEA14F6E1@finney.org> <1231460627.3430.73.camel@localhost> <20090110040907.GD5177@hn305c2n2.ms.com> <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090111040645.GG5177@hn305c2n2.ms.com> Message-ID: <496A80C0.3040809@echeque.com> Victor Duchovni wrote: > There is a huge install-base of systems on which SHA-2 > certs will failed SSL handshakes. When Windows XP > systems are <1% of the install-base, when OpenSSL > 0.9.8 is <1% of the install-base and 0.9.9 too (if the > support is not added before it goes official) It is now 2009. SHA-1 came under attack in 2005. That SHA-1 has been attacked, and SHA-2 not attacked, was evidence for the strength of SHA-2. Why did OpenSSL not support SHA-2 in 2006? Institutional paralysis? Protocol negotiation issues? Protocol negotiation issues that involved vested interests resulting in institutional paralysis? We cannot know why Microsoft acted as it acted, but if OpenSSL is open, we should be able to know why OpenSSL did even worse than Microsoft. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Sun Jan 11 22:05:08 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 12 Jan 2009 16:05:08 +1300 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> Message-ID: "Weger, B.M.M. de" writes: >> Bottom line, anyone fielding a SHA-2 cert today is not going=20 >> to be happy with their costly pile of bits. > >Will this situation have changed by the end of 2010 (that's next year, by the >way), when everybody who takes NIST seriously will have to switch to SHA-2? I have a general outline of a timeline for adoption of new crypto mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see "Question J" about 2/3 of the way down. It's not meant to be definitively accurate for all cases but was created as a rough guideline for people proposing to introduce new crypto mechanisms to give an idea of how long they should expect to wait to see them adopted. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From b.m.m.d.weger at TUE.nl Mon Jan 12 06:24:10 2009 From: b.m.m.d.weger at TUE.nl (Weger, B.M.M. de) Date: Mon, 12 Jan 2009 12:24:10 +0100 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> Message-ID: <7DF2365FF07C0E4E89419D65CCC93C9E014AEA3B3377@EXCHANGE11.campus.tue.nl> Hi Peter, > I have a general outline of a timeline for adoption of new > crypto mechanisms > (e.g. OAEP, PSS, that sort of thing, and not specifically > algorithms) in my > Crypto Gardening Guide and Planting Tips, > http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, > see "Question J" I had algorithms in mind, as the 'hash crisis' is about algorithms. For algorithms the situation might be simpler than for protocols. It is conceivable that one of these days some clever person comes up with, say, a practical chosen-prefix collision attack on SHA-1, enabling something similar as we did with MD5. It is also conceivable that some clever person completely breaks Rijndael, or RSA. Do software vendors (such as browser vendors) and service providers (such as CAs) have disaster recovery plans for such a situation? Or are these simply 'accepted risks' that nobody worries about? In my view it would be prudent to move SHA-1 out of the no-worry category. One level up, and maybe an example of a general lesson James was asking for: good practice to avoid availability problems is to add redundancy. In hash functions the security in many applications now seems to be completely based on SHA-1, a not-yet-broken but known-to-be-weak algorithm. How can we avoid such situations? (I am thinking long term here). When in 2012 the winner of the NIST SHA-3 competition will be known, and everybody will start using it (so that according to Peter's estimates, by 2018 half of the implementations actually uses it), do we then have enough redundancy? I was not around when Rijndael was chosen as the AES winner. Have there been discussions then about the number of winning algorithms? Why only one, and not three winners, say, with a sufficiently different design, that everybody then will implement? Can / should NIST do so with SHA-3? Is implementing three new hash functions at the same time much more complicated than implementing one? Grtz, Benne de Weger --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From marcus.brinkmann at ruhr-uni-bochum.de Mon Jan 12 07:20:34 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon, 12 Jan 2009 13:20:34 +0100 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> References: <20081230195106.52DEA14F6E1@finney.org> <1231460627.3430.73.camel@localhost> <20090110040907.GD5177@hn305c2n2.ms.com> <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> Message-ID: <496B3592.6050404@ruhr-uni-bochum.de> Weger, B.M.M. de wrote: > In my view, the main lesson that the information security community, > and in particular its intersection with the application building > community, has to learn from the recent MD5 and SHA-1 history, > is that strategies for dealing with broken crypto need rethinking. On the other hand, compared to many other aspects of our security infrastructure, even MD5 does quite well. Of course, that is not meant to be taken as an excuse. I agree with your call to have smooth transition systems to go from one cipher to another, but when to make the transition is a difficult decision to make. > PS: I find it ironic that the sites (such as ftp.ccc.de/congress/25c3/) > offering the video and audio files of the 25c3 presentation "MD5 > considered harmful today", provide for integrity checking of those > files their, uhm, MD5 hashes. It seems to me they are only provided to protect against transmission errors, and they are fine for that. Otherwise, it would be a more serious mistake to transfer them in-band. Security is a spectrum. Thanks, Marcus --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From fw at deneb.enyo.de Mon Jan 12 15:52:58 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 12 Jan 2009 21:52:58 +0100 Subject: What risk is being defended against here? In-Reply-To: <729DDF52-8E5A-430A-BDFD-B3EE9F3369B3@lrw.com> (Jerry Leichter's message of "Sun, 11 Jan 2009 07:01:36 -0500") References: <729DDF52-8E5A-430A-BDFD-B3EE9F3369B3@lrw.com> Message-ID: <877i50xn4l.fsf@mid.deneb.enyo.de> * Jerry Leichter: > Any speculations (beyond bureaucracy at its finest)? I wild guess would be fraudulent testing organizations which claim to have been subject to fraud themselves, and the testing standards body answered with some sort of regulation. (For certain German language test instances at certain sites, there used to me impossibly high participation numbers. The alleged certificates of the results were probably simply forged, but that's where I got the idea from.) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From eugen at leitl.org Thu Jan 15 12:10:47 2009 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 15 Jan 2009 18:10:47 +0100 Subject: [Opensim-dev] Technical assessment of Cable Beach asset server Message-ID: <20090115171047.GK11544@leitl.org> From: Toni Alatalo Subject: Re: [Opensim-dev] Technical assessment of Cable Beach asset server To: opensim-dev at lists.berlios.de Date: Thu, 15 Jan 2009 18:47:00 +0200 Reply-To: opensim-dev at lists.berlios.de Eugen Leitl kirjoitti: > On Thu, Jan 15, 2009 at 02:10:13PM +0900, Mike Mazur wrote: > As an aside from the peanut gallery, it would be nice to have asset > storage in a distributed cryptographic filestore like Tahoe > http://allmydata.org/~warner/pycon-tahoe.html > that has been my understanding as well. basically after worked a bit with the guys who pushed it in the Fenfire project (in 2002). i've understood that basically by using URIs as references to assets we get that: URLs for current http stuff and location independent URNs with distributed things like p2p networks. seems that Tahoe also uses "short URI-like strings" - dunno why 'URI-like' and not just URIs but anyway :) .. also as SL and OpenSim already uses UUIDs i guess some things are basically kind of ready for this. http://www.ht03.org/papers/pdfs/24.pdf is about the work in that area i was interested back long ago, dunno about the current implementations whether Tapestry, that Tahoe or something I haven't heard of is the thing, but i guess the basic idea is the same. in that Fenfire Storm the idea was to use content based hashes as IDs of files (like images), similar to Freenode -- the goal not being anonymous publishing in a secure p2p net, but instead having a nice storage system for both local own files and publishing them on the net. goals included the secure storage via redundancy, that seems to be emphasized in Tahoe and is indeed a great motivation for these things. looking forward to learning more, perhaps by testing Tahoe ~~Toni _______________________________________________ Opensim-dev mailing list Opensim-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ---------- -- Eugen* Leitl 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 majordomo at metzdowd.com From satoshi at vistomail.com Fri Jan 16 11:03:14 2009 From: satoshi at vistomail.com (Satoshi Nakamoto) Date: Sat, 17 Jan 2009 00:03:14 +0800 Subject: Bitcoin v0.1 released Message-ID: > Dustin D. Trammell wrote: > > Satoshi Nakamoto wrote: > > You know, I think there were a lot more people interested in the 90's, > > but after more than a decade of failed Trusted Third Party based systems > > (Digicash, etc), they see it as a lost cause. I hope they can make the > > distinction that this is the first time I know of that we're trying a > > non-trust-based system. > > Yea, that was the primary feature that caught my eye. The real trick > will be to get people to actually value the BitCoins so that they become > currency. I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet. It could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite. It can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like. It's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. "Send X bitcoins to my priority hotline at this IP and I'll read the message personally." Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial. It might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. Satoshi Nakamoto http://www.bitcoin.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Sat Jan 17 11:24:08 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 17 Jan 2009 11:24:08 -0500 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> Message-ID: <20090117112408.350646c5@bigboy.machshav.com> On Mon, 12 Jan 2009 16:05:08 +1300 pgut001 at cs.auckland.ac.nz (Peter Gutmann) wrote: > "Weger, B.M.M. de" writes: > > >> Bottom line, anyone fielding a SHA-2 cert today is not going=20 > >> to be happy with their costly pile of bits. > > > >Will this situation have changed by the end of 2010 (that's next > >year, by the way), when everybody who takes NIST seriously will have > >to switch to SHA-2? > > I have a general outline of a timeline for adoption of new crypto > mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically > algorithms) in my Crypto Gardening Guide and Planting Tips, > http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt, see > "Question J" about 2/3 of the way down. It's not meant to be > definitively accurate for all cases but was created as a rough > guideline for people proposing to introduce new crypto mechanisms to > give an idea of how long they should expect to wait to see them > adopted. > My analysis is similar to Peter's: 2-3 years for an RFC, 2-3 years for design/code/test, 2 years average delay for the next major release of Windows which will include it, 5 years for most of the older machines to die off. I've mentioned it before, but I'll point to the paper Eric Rescorla wrote a few years ago: http://www.cs.columbia.edu/~smb/papers/new-hash.ps or http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: if you're running a public-facing web server, you *can't* offer a SHA-2 certificate because you have no way of knowing if the client supports SHA-2. Fixing that requires a TLS fix; see the above timeline for that. -- --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jthorn at astro.indiana.edu Sat Jan 17 11:49:45 2009 From: jthorn at astro.indiana.edu (Jonathan Thornburg) Date: Sat, 17 Jan 2009 11:49:45 -0500 (EST) Subject: Bitcoin v0.1 released In-Reply-To: References: Message-ID: On Sat, 17 Jan 2009, Satoshi Nakamoto wrote: [[various possible uses of Bitcoin et al]] > Once it gets bootstrapped, there are so many > applications if you could effortlessly pay a few cents to a > website as easily as dropping coins in a vending machine. In the modern world, no major government wants to allow untracable international financial transactions above some fairly modest size thresholds. (The usual catch-phrases are things like "laundering drug money", "tax evasion", and/or "financing terrorist groups".) To this end, electronic financial transactions are currently monitored by various governments & their agencies, and any but the smallest of transactions now come with various ID requirements for the humans on each end. But if each machine in a million-node botnet sends 10 cents to a randomly chosen machine in another botnet on the other side of the world, you've just moved $100K, in a way that seems very hard to trace. To me, this means that no major government is likely to allow Bitcoin in its present form to operate on a large scale. I also worry about other "domestic" ways nasty people could exploit a widespread Bitcoin deployment: * Spammer botnets could burn through pay-per-send email filters trivially (as usual, the costs would fall on people other than the botnet herders & spammers). * If each machine in a botnet sends 1 cent to a herder, that can add up to a significant amount of money. In other words, Bitcoin would make botnet herding and the assorted malware industry even more profitable than it already is. Is there something obvious I've missed? Is there a clever aspect of the design which prevents botnets from exploiting the system? Is there a way for every major government to monitor all Bitcoin transactions to watch for botnet-to-botnet sending? -- -- From: "Jonathan Thornburg [remove -animal to reply]" Dept of Astronomy, Indiana University, Bloomington, Indiana, USA "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From paul.hoffman at vpnc.org Sat Jan 17 15:03:57 2009 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Sat, 17 Jan 2009 12:03:57 -0800 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <7DF2365FF07C0E4E89419D65CCC93C9E014AEA3B3377@EXCHANGE11.campus.tue.nl> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <7DF2365FF07C0E4E89419D65CCC93C9E014AEA3B3377@EXCHANGE11.campus.tue.nl> Message-ID: At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote: >When in 2012 the winner of the >NIST SHA-3 competition will be known, and everybody will start >using it (so that according to Peter's estimates, by 2018 half >of the implementations actually uses it), do we then have enough >redundancy? No offense, Benne, but are serious? Why would "everybody" even consider it? Give what we know about the design of SHA-2 (too little), how would we know whether SHA-3 is any better than SHA-2 for applications such as digital certificates? In specific, if most systems have implemented the whole SHA-2 family by the time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would argue that it is probably much more prudent to change to SHA-2/384 than to SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will have had significantly more study. It all depends on who you trust and why. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From bmoeller at acm.org Mon Jan 19 04:45:55 2009 From: bmoeller at acm.org (Bodo Moeller) Date: Mon, 19 Jan 2009 10:45:55 +0100 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090117112408.350646c5@bigboy.machshav.com> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090117112408.350646c5@bigboy.machshav.com> Message-ID: <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin wrote: > I've mentioned it before, but I'll point to the paper Eric Rescorla > wrote a few years ago: > http://www.cs.columbia.edu/~smb/papers/new-hash.ps or > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom line: > if you're running a public-facing web server, you *can't* offer a SHA-2 > certificate because you have no way of knowing if the client supports > SHA-2. Fixing that requires a TLS fix; see the above timeline for that. The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 mandatory), so you can send a SHA-256 certificate to clients that indicate they support TLS 1.2 or later. You'd still need some other certificate for interoperability with clients that don't support SHA-256, of course, and you'd be sending that one to clients that do support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which is not really a problem when CAs make sure to use the hash algorithm in a way that doesn't rely on hash collisions being hard to find, which probably is a good idea for *any* hash algorithm.) Bodo --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From stefan.kelm at secorvo.de Mon Jan 19 05:09:40 2009 From: stefan.kelm at secorvo.de (Stefan Kelm) Date: Mon, 19 Jan 2009 11:09:40 +0100 Subject: [heise online UK] Secure deletion: a single overwrite will do it Message-ID: <49745164.4050003@secorvo.de> The myth that to delete data really securely from a hard disk you have to overwrite it many times, using different patterns, has persisted for decades, despite the fact that even firms specialising in data recovery, openly admit that if a hard disk is overwritten with zeros just once, all of its data is irretrievably lost. Craig Wright, a forensics expert, claims to have put this legend finally to rest. He and his colleagues ran a scientific study to take a close look at hard disks of various makes and different ages, overwriting their data under controlled conditions and then examining the magnetic surfaces with a magnetic-force microscope. They presented their paper at ICISS 2008 and it has been published by Springer AG in its Lecture Notes in Computer Science series (Craig Wright, Dave Kleiman, Shyaam Sundhar R. S.: Overwriting Hard Drive Data: The Great Wiping Controversy). They concluded that, after a single overwrite of the data on a drive, whether it be an old 1-gigabyte disk or a current model (at the time of the study), the likelihood of still being able to reconstruct anything is practically zero. Well, OK, not quite: a single bit whose precise location is known can in fact be correctly reconstructed with 56 per cent probability (in one of the quoted examples). To recover a byte, however, correct head positioning would have to be precisely repeated eight times, and the probability of that is only 0.97 per cent. Recovering anything beyond a single byte is even less likely. Nevertheless, that doesn't stop the vendors of data-wiping programs offering software that overwrites data up to 35 times, based on decades-old security standards that were developed for diskettes. Although this may give a data wiper the psychological satisfaction of having done a thorough job, it's a pure waste of time. Something much more important, from a security point of view, is actually to overwrite all copies of the data that are to be deleted. If a sensitive document has been edited on a PC, overwriting the file is far from sufficient because, during editing, the data have been saved countless times to temporary files, back-ups, shadow copies, swap files ... and who knows where else? Really, to ensure that nothing more can be recovered from a hard disk, it has to be overwritten completely, sector by sector. Although this takes time, it costs nothing: the dd command in any Linux distribution will do the job perfectly. (djwm) http://www.heise-online.co.uk/news/Secure-deletion-a-single-overwrite-will-do-it--/112432 -------------------------------------------------------- T.I.S.P. - Lassen Sie Ihre Qualifikation zertifizieren vom 09.-13.03.2009 - http://www.secorvo.de/college/tisp/ --------------------------------------------------------- Stefan Kelm Security Consulting Secorvo Security Consulting GmbH Ettlinger Strasse 12-14, D-76137 Karlsruhe Tel. +49 721 255171-304, Fax +49 721 255171-100 stefan.kelm at secorvo.de, http://www.secorvo.de/ PGP: 87AE E858 CCBC C3A2 E633 D139 B0D9 212B Mannheim HRB 108319, Geschaeftsfuehrer: Dirk Fox --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Darren.Moffat at Sun.COM Mon Jan 19 08:38:02 2009 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 19 Jan 2009 13:38:02 +0000 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <7DF2365FF07C0E4E89419D65CCC93C9E014AEA3B3377@EXCHANGE11.campus.tue.nl> Message-ID: <4974823A.8040409@Sun.COM> Paul Hoffman wrote: > At 12:24 PM +0100 1/12/09, Weger, B.M.M. de wrote: >> When in 2012 the winner of the >> NIST SHA-3 competition will be known, and everybody will start >> using it (so that according to Peter's estimates, by 2018 half >> of the implementations actually uses it), do we then have enough >> redundancy? > > No offense, Benne, but are serious? Why would "everybody" even consider it? Give what we know about the design of SHA-2 (too little), how would we know whether SHA-3 is any better than SHA-2 for applications such as digital certificates? > > In specific, if most systems have implemented the whole SHA-2 family by the time SHA-3 is settled, and then there is a problem found in SHA-2/256, I would argue that it is probably much more prudent to change to SHA-2/384 than to SHA-3/256. SHA-2/384 will most likely be much than to SHA-3/256, but it will have had significantly more study. Can you state the assumptions for why you think that moving to SHA384 would be safe if SHA256 was considered vulnerable in some way please. SHA256,384,512 are a suite all built on the same basic algorithm construction. Depending on how SHA256 fell the whole suite could be vulnerable irrespective of the digest length or maybe it won't be. Until we know how the SHA3 digest is actually constructed the same could even be true of that. I don't think it depends at all on who you trust but on what algorithms are available in the protocols you need to use to run your business or use the apps important to you for some other reason. It also very much depends on why the app uses the crypto algorithm in question, and in the case of digest/hash algorithms wither they are key'd (HMAC) or not. -- Darren J Moffat --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From paul.hoffman at vpnc.org Mon Jan 19 11:33:26 2009 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon, 19 Jan 2009 08:33:26 -0800 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <4974823A.8040409@Sun.COM> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <7DF2365FF07C0E4E89419D65CCC93C9E014AEA3B3377@EXCHANGE11.campus.tue.nl> <4974823A.8040409@Sun.COM> Message-ID: At 1:38 PM +0000 1/19/09, Darren J Moffat wrote: >Can you state the assumptions for why you think that moving to SHA384 would be safe if SHA256 was considered vulnerable in some way please. Sure. I need 128 bits of pre-image protection for, say, a digital signature. SHA2/256 is giving me that. Then, due to some weakness, it is only giving me 112 bits of protection. The weakness is understood in the crypto community, and it's a straight-line loss of bits of protection. SHA2/384 would then give me 168 bits of protection, which is more than the 128 what I need. Even if you don't trust that there is a straight-line loss of bits, you would have to be believing that the attack is much worse for SHA2/384 than it was for SHA2/256 in order to bring the output down to the level that I need. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Victor.Duchovni at morganstanley.com Mon Jan 19 13:14:40 2009 From: Victor.Duchovni at morganstanley.com (Victor Duchovni) Date: Mon, 19 Jan 2009 13:14:40 -0500 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090117112408.350646c5@bigboy.machshav.com> <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> Message-ID: <20090119181440.GE12975@hn305c2n2.ms.com> On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote: > The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 > mandatory), so you can send a SHA-256 certificate to clients that > indicate they support TLS 1.2 or later. You'd still need some other > certificate for interoperability with clients that don't support > SHA-256, of course, and you'd be sending that one to clients that do > support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which > is not really a problem when CAs make sure to use the hash algorithm > in a way that doesn't rely on hash collisions being hard to find, > which probably is a good idea for *any* hash algorithm.) It would be helpful if as a first step, SSL_library_init() (a.k.a. OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests, I would make this change in the 0.9.9 development snapshots. [ Off topic: I find OpenSSL release-engineering a rather puzzling process. The "patch" releases are in fact feature releases, and there are no real patch releases even for critical security issues. I chose to backport the 0.9.8j security fixes to 0.9.8i and sit out all the new FIPS code, ... This should not be necessary. I really hope to see real OpenSSL patch releases some day with development of new features *strictly* in the development snapshots. Ideally this will start with 0.9.9a, with no new features, just bugfixes, in [b-z]. ] -- Viktor. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Mon Jan 19 16:37:45 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 19 Jan 2009 16:37:45 -0500 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090117112408.350646c5@bigboy.machshav.com> <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> Message-ID: <20090119163745.2339c51f@cs.columbia.edu> On Mon, 19 Jan 2009 10:45:55 +0100 Bodo Moeller wrote: > On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin > wrote: > > > I've mentioned it before, but I'll point to the paper Eric Rescorla > > wrote a few years ago: > > http://www.cs.columbia.edu/~smb/papers/new-hash.ps or > > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom > > line: if you're running a public-facing web server, you *can't* > > offer a SHA-2 certificate because you have no way of knowing if the > > client supports SHA-2. Fixing that requires a TLS fix; see the > > above timeline for that. > > The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 > mandatory), so you can send a SHA-256 certificate to clients that > indicate they support TLS 1.2 or later. You'd still need some other > certificate for interoperability with clients that don't support > SHA-256, of course, and you'd be sending that one to clients that do > support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which > is not really a problem when CAs make sure to use the hash algorithm > in a way that doesn't rely on hash collisions being hard to find, > which probably is a good idea for *any* hash algorithm.) > So -- who supports TLS 1.2? (Btw -- note the date of that RFC: August 2008. That's almost exactly 3 years after ekr and I published our paper. Since ekr is co-chair of the TLS working group, we can assume that that group was aware of the problem. See what Peter and I said about how long it takes to get any changes deployed.) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Mon Jan 19 23:57:09 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 20 Jan 2009 17:57:09 +1300 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090119163745.2339c51f@cs.columbia.edu> Message-ID: "Steven M. Bellovin" writes: >So -- who supports TLS 1.2? Not a lot, I think. The problem with 1.2 is that it introduces a pile of totally gratuitous incompatible changes to the protocol that require quite a bit of effort to implement (TLS 1.1 -> 1.2 is at least as big a step, if not a bigger step, than the change from SSL to TLS), complicate an implementation, are difficult to test because of the general lack of implementations supporting it, and provide no visible benefit. Why would anyone rush to implement this when what we've got now works[0] just fine? Peter. [0] For whatever level of "works" applies to SSL/TLS, in the sense that 1.2 won't "work" any better than 1.1 does. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jon at callas.org Tue Jan 20 13:04:52 2009 From: jon at callas.org (Jon Callas) Date: Tue, 20 Jan 2009 10:04:52 -0800 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: References: Message-ID: <05CEE8D1-1A4A-4CAF-B983-F96A89625505@callas.org> > I have a general outline of a timeline for adoption of new crypto > mechanisms (e.g. OAEP, PSS, that sort of thing, and not specifically > algorithms) in my Crypto Gardening Guide and Planting Tips, http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt > , see "Question J" about 2/3 of the way down. It's not meant to be > definitively accurate for all cases but was created as a rough > guideline for people proposing to introduce new crypto mechanisms to > give an idea of how long they should expect to wait to see them > adopted. I've always been pleased with your answer to Question J, so I'll say what we're doing at PGP. We deprecated MD5 in '97. That was one of the main points of the new formats that became OpenPGP was that agility has its own challenges, but it's worth it. We had a meeting recently to look at what we're going to do. Our first thoughts were that we would scrub MD5 from the UI and be done with it. Then we realized that we need to leave enough of the old UI so that people can *remove* MD5 from their use. We decided that we'll issue warnings in the annotations when we verify MD5 signatures. We can't stop verifying them, but we'll do an equivalent to what we do with 40-bit crypto in S/MIME. (40-bit still harries S/MIME; it's really a pity that we have to deal with it. Our solution is that 40-bit crypto is just a fancy form of plaintext. We decode it the way we decode quoted-printable, base64, and other fancy forms of plaintext.) We debated removing it from the APIs, and concluded that that is asking for trouble, because someone will need to do that for diagnostic and testing purposes. We've started deprecating the 160-bit hashes. There will be comments in the UI for both SHA-1 and RIPE-MD/160. We think NIST's advice for phasing them out next year is just fine, and so we'll start really phasing them out next year. Lastly, we considered other options for hash algorithms. Presently, it's too early to do anything, but we'll look at it again when we do more work on the 160-bit hashes. Jon --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Nicolas.Williams at sun.com Tue Jan 20 16:58:42 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Jan 2009 15:58:42 -0600 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <4974823A.8040409@Sun.COM> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <7DF2365FF07C0E4E89419D65CCC93C9E014AEA3B3377@EXCHANGE11.campus.tue.nl> <4974823A.8040409@Sun.COM> Message-ID: <20090120215842.GK884@Sun.COM> On Mon, Jan 19, 2009 at 01:38:02PM +0000, Darren J Moffat wrote: > I don't think it depends at all on who you trust but on what algorithms > are available in the protocols you need to use to run your business or > use the apps important to you for some other reason. It also very much > depends on why the app uses the crypto algorithm in question, and in the > case of digest/hash algorithms wither they are key'd (HMAC) or not. As Jeff Hutzelman suggested recently, inspired by the SSHv2 CBC mode vulnerability, hash algorithm agility for PKI really means having more than one signature, each using a different hash, in each certificate; this enlarges certificates. Alternatively, it needs to be possible to select what certificate to present to a peer based on an algorithm negotiation; this tends to mean adding round-trips to our protocols. Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jason at lunkwill.org Tue Jan 20 17:13:56 2009 From: jason at lunkwill.org (Jason) Date: Tue, 20 Jan 2009 22:13:56 +0000 (UTC) Subject: [heise online UK] Secure deletion: a single overwrite will do it In-Reply-To: <49745164.4050003@secorvo.de> References: <49745164.4050003@secorvo.de> Message-ID: On Mon, 19 Jan 2009, Stefan Kelm wrote: > ... and who knows where else? Really, to ensure that nothing more can be > recovered from a hard disk, it has to be overwritten completely, sector > by sector. Although this takes time, it costs nothing: the dd command in > any Linux distribution will do the job perfectly. I agree in general, although you still have to watch out for "reserve tracks" (search on this page): http://forum.hddguru.com/seagate-terminal-commands-t6411.html "All hard disks have reserved sectors, which are used automatically by the drive logic if there is a defect in the media.": http://cisn.metu.edu.tr/97-2/hardware.html Those could perhaps be used to smuggle data out of a wiped disk. Or, if your disk firmware is (or someday becomes) clever enough to transparently swap out dying sectors with those from its reserved store, you could accidentally end up with data on the disk that dd would miss. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From dan at geer.org Tue Jan 20 17:16:22 2009 From: dan at geer.org (dan at geer.org) Date: Tue, 20 Jan 2009 17:16:22 -0500 Subject: [heise online UK] Secure deletion: a single overwrite will do it In-Reply-To: Your message of "Mon, 19 Jan 2009 11:09:40 +0100." <49745164.4050003@secorvo.de> Message-ID: <20090120221622.8F5CA3435D@absinthe.tinho.net> Peter Gutmann has responded http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (see the "Further Epilogue" section well down the page) --dan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From dave at davekleiman.com Tue Jan 20 19:18:39 2009 From: dave at davekleiman.com (Dave Kleiman) Date: Tue, 20 Jan 2009 19:18:39 -0500 Subject: [heise online UK] Secure deletion: a single overwrite will do it In-Reply-To: References: <49745164.4050003@secorvo.de> Message-ID: <00f201c97b5d$d13f4790$73bdd6b0$@com> On Mon, 19 Jan 2009, Stefan Kelm wrote: > ...it has to be overwritten completely, sector > by sector. Although this takes time, it costs nothing: the dd command in > any Linux distribution will do the job perfectly. Note quite perfectly, and not nearly as fast as the built-in option (see below). On Mon, 20 Jan 2009, Jason wrote: >I agree in general, although you still have to watch out for "reserve tracks" >(search on this page)....."All hard disks have reserved sectors, which are used automatically by the >drive logic if there is a defect in the media.": Yes the main areas you are referring to are known as the P-List (Primary Defects List ? manufacture defect info that does not change) G-List (Grown Defects Lists ? sector relocation table). You can only access the P-List with special commands and tools. However, you can wipe the G-List are if you do it outside of an OS (or a tool that can access the system area), since the OS knows nothing of these sectors. The easiest (possible the best because of speed) way to accomplish this in modern ATA hard drives (2001 forward) is with the built-in Secure Erase program. Conveniently placed there for us by Recording Research (CMRR) headed by Gordon Hughes, Associate Director of CMRR, USSD on the Secure Erase Initiative. ""At the ANSI T-13 Committee meeting in 2004, Gordon described the differences between block erase as described in government document DoD2550 and Secure Erase. Unlike block level erase Secure Erase also overwrites reassigned blocks and can be up to eight times faster (per CMRR tests). In addition the enhanced SE command qualifies for Federal Government secret data classification erasure."" You can download a DOS-based utility HDDerase that securely erases all data on ATA hard disk drives via the internal secure erase command. http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml And yes, I am the same Dave Kleiman from the paper. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Wed Jan 21 01:07:50 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 21 Jan 2009 19:07:50 +1300 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <05CEE8D1-1A4A-4CAF-B983-F96A89625505@callas.org> Message-ID: Jon Callas writes: >I've always been pleased with your answer to Question J, so I'll say what >we're doing at PGP. That wasn't really meant as a compliment :-). The problem is that by leaping on things the instant they appear you end up having to support a menagerie of wierdo algorithms and mechanisms that the industry as a whole never adopts. How many crypto libraries that could be used to implement the OpenPGP spec actually support Haval, or Tiger, or Twofish, or SAFER-SK128? The result of this too-quick adoption has been a bunch of gaps in newer versions of the spec (look for a range of algorithm IDs marked as "reserved") where algorithms adopted too quickly were removed again when they failed to gain general (or any) acceptance. Another concern with too-quick adoption is the potential for moving to an algorithm that's later found to be flawed. This hasn't happened yet for cryptographer-designed algorithms and mechanisms (as opposed to WEP et al) but it's quite possible that some new algorithm introduced at Crypto n is shown to reduce to rot-13 in a paper published in Crypto n+1. I use an informal five- year rule that I won't make an algorithm a default (i.e. enabled without explicit user action) until it's had active attention paid to it for at least five years, where "active attention" means not so much published in an obscure conference somewhere but required in an industry spec or something similar that results in active scrutiny of its security. (Actually it's not quite that simple, it's more of a balancing act and the pace depends on whether there are credible threats to the current default algorithm or not). In crypto, "new" doesn't necessarily mean "better", it can also mean "riskier". Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From benl at google.com Fri Jan 23 00:01:50 2009 From: benl at google.com (Ben Laurie) Date: Fri, 23 Jan 2009 16:01:50 +1100 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090119181440.GE12975@hn305c2n2.ms.com> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090117112408.350646c5@bigboy.machshav.com> <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> <20090119181440.GE12975@hn305c2n2.ms.com> Message-ID: <1b587cab0901222101y2e5383ebkf93d47268d36c3b4@mail.gmail.com> On Tue, Jan 20, 2009 at 5:14 AM, Victor Duchovni wrote: > On Mon, Jan 19, 2009 at 10:45:55AM +0100, Bodo Moeller wrote: > >> The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 >> mandatory), so you can send a SHA-256 certificate to clients that >> indicate they support TLS 1.2 or later. You'd still need some other >> certificate for interoperability with clients that don't support >> SHA-256, of course, and you'd be sending that one to clients that do >> support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which >> is not really a problem when CAs make sure to use the hash algorithm >> in a way that doesn't rely on hash collisions being hard to find, >> which probably is a good idea for *any* hash algorithm.) > > It would be helpful if as a first step, SSL_library_init() (a.k.a. > OpenSSL_add_ssl_algorithms()) enabled the SHA-2 family of digests, > I would make this change in the 0.9.9 development snapshots. > > [ Off topic: I find OpenSSL release-engineering a rather puzzling > process. The "patch" releases are in fact feature releases, Who said they were "patch" releases? > and there > are no real patch releases even for critical security issues. I chose > to backport the 0.9.8j security fixes to 0.9.8i and sit out all the > new FIPS code, ... This should not be necessary. I really hope to see > real OpenSSL patch releases some day with development of new features > *strictly* in the development snapshots. Ideally this will start with > 0.9.9a, with no new features, just bugfixes, in [b-z]. ] I think that is not likely to happen, because that's not the way it works. The promise we try to keep is ABI compatibility between releases that have the same numbers. Letters signify new versions within that series. We do not have a bugfix-only branch. There doesn't seem to be much demand for one. > > -- > Viktor. > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Victor.Duchovni at morganstanley.com Fri Jan 23 10:36:33 2009 From: Victor.Duchovni at morganstanley.com (Victor Duchovni) Date: Fri, 23 Jan 2009 10:36:33 -0500 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <1b587cab0901222101y2e5383ebkf93d47268d36c3b4@mail.gmail.com> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090117112408.350646c5@bigboy.machshav.com> <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> <20090119181440.GE12975@hn305c2n2.ms.com> <1b587cab0901222101y2e5383ebkf93d47268d36c3b4@mail.gmail.com> Message-ID: <20090123153633.GF9572@hn305c2n2.ms.com> On Fri, Jan 23, 2009 at 04:01:50PM +1100, Ben Laurie wrote: > > I really hope to see > > real OpenSSL patch releases some day with development of new features > > *strictly* in the development snapshots. Ideally this will start with > > 0.9.9a, with no new features, just bug-fixes, in [b-z]. ] > > I think that is not likely to happen, because that's not the way it > works. The promise we try to keep is ABI compatibility between > releases that have the same numbers. Letters signify new versions > within that series. We do not have a bugfix-only branch. There doesn't > seem to be much demand for one. Don't want to start a long debate here, but I do want to respond to this. You seem to be out of touch I am afraid. Just look at what many O/S distributions do. They adopt a new OpenSSL 0.9.Xy release from time to time (for some initial "y") and back-port security fixes never changing the letter. One can't actually tell from "openssl version" what version one is running and which fixes have been applied. Why am I back-porting patch-sets to 0.9.8i? Is that because there is no demand for bugfix releases? There is indeed demand for real bugfix releases, just that people have gotten used to doing it themselves, but this is not very effective and is difficult to audit. OpenSSL has not infrequent security advisories, and these are always fixed in new feature releases not bugfix releases (which are misleadingly called "patch" releases). #define HEADER_OPENSSLV_H /* Numeric release version identifier: * MNNFFPPS: major minor fix patch status * The status nibble has one of the values 0 for development, 1 to e for betas * 1 to 14, and f for release. The patch level is exactly that. * For example: * 0.9.3-dev 0x00903000 * 0.9.3-beta1 0x00903001 * 0.9.3-beta2-dev 0x00903002 * 0.9.3-beta2 0x00903002 (same as ...beta2-dev) * 0.9.3 0x0090300f * 0.9.3a 0x0090301f * 0.9.4 0x0090400f * 1.2.3z 0x102031af * * For continuity reasons (because 0.9.5 is already out, and is coded * 0x00905100), between 0.9.5 and 0.9.6 the coding of the patch level * part is slightly different, by setting the highest bit. This means * that 0.9.5a looks like this: 0x0090581f. At 0.9.6, we can start * with 0x0090600S... * * (Prior to 0.9.3-dev a different scheme was used: 0.9.2b is 0x0922.) * (Prior to 0.9.5a beta1, a different scheme was used: MMNNFFRBB for * major minor fix final patch/beta) */ #define OPENSSL_VERSION_NUMBER 0x0090809fL -- /"\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAIL Morgan Stanley confidentiality or privilege, and use is prohibited. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ekr at networkresonance.com Fri Jan 23 12:23:05 2009 From: ekr at networkresonance.com (Eric Rescorla) Date: Fri, 23 Jan 2009 09:23:05 -0800 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: References: <20090119163745.2339c51f@cs.columbia.edu> Message-ID: <20090123172305.A9B1F50822@romeo.rtfm.com> At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote: > > "Steven M. Bellovin" writes: > > >So -- who supports TLS 1.2? > > Not a lot, I think. The problem with 1.2 is that it introduces a pile of > totally gratuitous incompatible changes to the protocol that require quite a > bit of effort to implement (TLS 1.1 -> 1.2 is at least as big a step, if not a > bigger step, than the change from SSL to TLS), complicate an implementation, > are difficult to test because of the general lack of implementations > supporting it, and provide no visible benefit. Why would anyone rush to > implement this when what we've got now works[0] just fine? Ordinarily I wouldn't bother to respond to Peter's curmudgeon act, but since I was obviously heavily involved with TLS 1.2, I think a bit of context is in order. Nearly all the changes to TLS between 1.1 and 1.2 were specifically designed to accomodate new digest algorithms throughout the protocol. For those of you who aren't TLS experts, TLS had MD5 and SHA-1 wired all throughout the protocol and we had to arrange to strip them out, plus find a way to signal that you were willing to support the newer algorithms. To avoid this becoming a huge pile of hacks, we had to restructure some of the less orthogonal negotiation mechanisms. The other major (and totally optional) change was the addition of combined cipher modes like GCM. That change was made primarily because we were in there and there was some demand for those modes. So, no, I don't consider these changes "gratuitous", though of course they are incompatible. Yes, there were simpler things we could have done, such as just specifying a new set of fixed digest algorithms to replace MD5 and SHA-1, but I and others felt that this was unwise from a futureproofing perspective. Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those between SSL and TLS. I'm not particularly happy about that either, but it's what we felt was necessary to do a principled job. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Fri Jan 23 20:55:15 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 24 Jan 2009 14:55:15 +1300 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090123172305.A9B1F50822@romeo.rtfm.com> Message-ID: Eric Rescorla writes: >At Tue, 20 Jan 2009 17:57:09 +1300, Peter Gutmann wrote: >> "Steven M. Bellovin" writes: >> >> >So -- who supports TLS 1.2? >> >> Not a lot, I think. The problem with 1.2 is that it introduces a pile of >> totally gratuitous incompatible changes to the protocol that require quite a >> bit of effort to implement (TLS 1.1 -> 1.2 is at least as big a step, if not a >> bigger step, than the change from SSL to TLS), complicate an implementation, >> are difficult to test because of the general lack of implementations >> supporting it, and provide no visible benefit. Why would anyone rush to >> implement this when what we've got now works[0] just fine? > >Ordinarily I wouldn't bother to respond to Peter's curmudgeon act, :-). >but since I was obviously heavily involved with TLS 1.2, I think a bit of >context is in order. I'm aware of why the changes were made, but the point of my comment was to explain their consequences in the lack of support for TLS 1.2. I had (AFAIK) one of the first implementations of TLS 1.1, an incremental upgrade of TLS 1.0 (and then had some fun trying to find things to interop against) but for TLS 1.2 I haven't implemented it and have no plans to implement it because it provides absolutely no benefit over TLS 1.1 and a great many downsides. >Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those >between SSL and TLS. I'm not particularly happy about that either, but it's >what we felt was necessary to do a principled job. It may have been a nicely principled job but what actual problem is the switch in hash algorithms actually solving? Making changes of such magnitude to a very, very widely-deployed protocol is always a tradeoff between the necessity of the change and the pain of doing so. In TLS 1.2 the pain is proportionate to the scale of the existing deployed base (i.e. very large) and the necessity of doing so appears to be zero. I don't know of any attack or threat to the existing dual-hash mechanism that TLS 1.2 addresses, and it may even make things worse by switching from the redundant dual-hash (a testament to the original SSL designers) to a single algorithm. This is why I called the changes "gratuitous", there is no threat that they address - it can even be argued (no doubt endlessly) that they make the PRF weaker rather than stronger - but they come at considerable cost. SSL/TLS is (and has been for many years) part of the Internet infrastructure. You don't make significant, totally incompatible changes to the infrastructure without very carefully weighing the advantages and disadvantages. Maybe there'll be a sudden flood of unexpected TLS 1.2 implementations right after I post this, but at the moment it seems that implementors have weighed up the cost and said "no thanks". Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From benl at google.com Sat Jan 24 00:39:24 2009 From: benl at google.com (Ben Laurie) Date: Sat, 24 Jan 2009 16:39:24 +1100 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: <20090123153633.GF9572@hn305c2n2.ms.com> References: <7DF2365FF07C0E4E89419D65CCC93C9E01435C239495@EXCHANGE11.campus.tue.nl> <20090117112408.350646c5@bigboy.machshav.com> <47015c2b0901190145o7081c2cbk810964cf69041165@mail.gmail.com> <20090119181440.GE12975@hn305c2n2.ms.com> <1b587cab0901222101y2e5383ebkf93d47268d36c3b4@mail.gmail.com> <20090123153633.GF9572@hn305c2n2.ms.com> Message-ID: <1b587cab0901232139l4922fa70la009884878a5f02a@mail.gmail.com> On Sat, Jan 24, 2009 at 2:36 AM, Victor Duchovni wrote: > You seem to be out of touch I am afraid. Just look at what many O/S > distributions do. They adopt a new OpenSSL 0.9.Xy release from time to > time (for some initial "y") and back-port security fixes never changing > the letter. One can't actually tell from "openssl version" what version > one is running and which fixes have been applied. > > Why am I back-porting patch-sets to 0.9.8i? Is that because there is no > demand for bugfix releases? There is indeed demand for real bugfix > releases, just that people have gotten used to doing it themselves, > but this is not very effective and is difficult to audit. It is not that I am unaware of this, I was pointing out what we actually do. But you do have a fair point and I will take it up with the team. However, I wonder how this is going to pan out? Since historically pretty much every release has been prompted by a security issue, but also includes new features and non-security bugfixes, in order to release 0.9.8j the way you want us to, we would also have to test and release security updates for 0.9.8 - 0.9.8i, for a total of 10 branched versions. I think this is asking rather a lot of volunteers! Don't suggest that we should release feature/bugfix versions less often, I think we already do that less often than we should. Perhaps the answer is that we security patch every version that is less than n months old, and end-of-life anything before that? Suggestions for reasonable values of n? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From hal at finney.org Sat Jan 24 11:48:03 2009 From: hal at finney.org (Hal Finney) Date: Sat, 24 Jan 2009 08:48:03 -0800 (PST) Subject: Bitcoin v0.1 released Message-ID: <20090124164803.A3B7414F6E1@finney.org> Jonathan Thornburg writes: > In the modern world, no major government wants to allow untracable > international financial transactions above some fairly modest size > thresholds. (The usual catch-phrases are things like "laundering > drug money", "tax evasion", and/or "financing terrorist groups".) > To this end, electronic financial transactions are currently monitored > by various governments & their agencies, and any but the smallest of > transactions now come with various ID requirements for the humans > on each end. > > But if each machine in a million-node botnet sends 10 cents to a > randomly chosen machine in another botnet on the other side of the > world, you've just moved $100K, in a way that seems very hard to > trace. To me, this means that no major government is likely to allow > Bitcoin in its present form to operate on a large scale. Certainly a valid point, and one which has been widely discussed in the debates over the years about electronic cash. Bitcoin has a couple of things going for it: one is that it is distributed, with no single point of failure, no "mint", no company with officers that can be subpoenaed and arrested and shut down. It is more like a P2P network, and as we have seen, despite degrees of at least governmental distaste, those are still around. Bitcoin could also conceivably operate in a less anonymous mode, with transfers being linked to individuals, rather than single-use keys. It would still be useful to have a large scale, decentralized electronic payment system. It also might be possible to refactor and restructure Bitcoin to separate out the key new idea, a decentralized, global, irreversible transaction database. Such a functionality might be useful for other purposes. Once it exists, using it to record monetary transfers would be a sort of side effect and might be harder to shut down. > I also worry about other "domestic" ways nasty people could exploit > a widespread Bitcoin deployment: > * Spammer botnets could burn through pay-per-send email filters > trivially (as usual, the costs would fall on people other than the > botnet herders & spammers). > * If each machine in a botnet sends 1 cent to a herder, that can add > up to a significant amount of money. In other words, Bitcoin would > make botnet herding and the assorted malware industry even more > profitable than it already is. It's important to understand that the proof-of-work (POW) aspect of Bitcoin is primarily oriented around ensuring the soundness of the historical transaction database. Each Bitcoin data block records a set of transactions, and includes a hash collision. Subsequent data blocks have their own transactions, their own collisions, and also chain to all earlier hashes. The result is that once a block is "buried" under enough new blocks, it is essentially certain (given the threat model, namely that attackers cannot muster more than X% of the compute power of legitimate node operators) that old transactions can't be reversed. Creating new coins is indeed currently also being done by POW, but I think that is seen as a temporary expedient, and in fact the current software phases that out over several years. Hence worries about botnets being able to manufacture large quantities of POW tokens are only a temporary concern, in the context of Bitcoin. There have been a number of discussions in the past about POW tokens as anti spam measures, given the botnet threat. References are available from "Proof-of-work system" on Wikipedia. Analyses have yielded mixed results, depending on the assumptions and system design. If POW tokens do become useful, and especially if they become money, machines will no longer sit idle. Users will expect their computers to be earning them money (assuming the reward is greater than the cost to operate). A computer whose earnings are being stolen by a botnet will be more noticeable to its owner than is the case today, hence we might expect that in that world, users will work harder to maintain their computers and clean them of botnet infestations. Countermeasures by botnet operators would include moderating their take, perhaps only stealing 10% of the productive capacity of invaded computers, so that their owners would be unlikely to notice. This kind of thinking quickly degenerates into unreliable speculation, but it points out the difficulties of analyzing the full ramifications of a world where POW tokens are valuble. Hal Finney --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ekr at networkresonance.com Sat Jan 24 12:51:34 2009 From: ekr at networkresonance.com (Eric Rescorla) Date: Sat, 24 Jan 2009 09:51:34 -0800 Subject: MD5 considered harmful today, SHA-1 considered harmful tomorrow In-Reply-To: References: <20090123172305.A9B1F50822@romeo.rtfm.com> Message-ID: <20090124175134.78B2F50822@romeo.rtfm.com> At Sat, 24 Jan 2009 14:55:15 +1300, Peter Gutmann wrote: > >Yes, the changes between TLS 1.1 and TLS 1.2 are about as big as those > >between SSL and TLS. I'm not particularly happy about that either, but it's > >what we felt was necessary to do a principled job. > > It may have been a nicely principled job but what actual problem is the switch > in hash algorithms actually solving? Making changes of such magnitude to a > very, very widely-deployed protocol is always a tradeoff between the necessity > of the change and the pain of doing so. In TLS 1.2 the pain is proportionate > to the scale of the existing deployed base (i.e. very large) and the necessity > of doing so appears to be zero. I don't know of any attack or threat to the > existing dual-hash mechanism that TLS 1.2 addresses, and it may even make > things worse by switching from the redundant dual-hash (a testament to the > original SSL designers) to a single algorithm. This is why I called the > changes "gratuitous", there is no threat that they address - it can even be > argued (no doubt endlessly) that they make the PRF weaker rather than stronger > - but they come at considerable cost. I agree that given the current set of attacks on SHA-1 and MD5, there was no existing attack on the protocol. However, that doesn't mean that improvements in analysis wouldn't lead to such attacks and so the general feeling of the community was to err on the side of safety. No doubt if we hadn't done so, there would be people screaming about how TLS still used MD5. Indeed, that's how this thread started. So, once again, I don't share your opinions about these changes being gratuitous. Moreover, the bulk of the changes weren't to the PRF. That's actually quite a trivial change to implement, but rather to have accurate signalling about what combinations of hashes and signatures implementations could support--something that was painfully non-orthogonal in SSLv3 and earlier versions of TLS. Again, one could argue that we could have hacked around this and indeed the original Bellovin-Rescorla paper described a number of such hacks, but the general feeling of the TLS WG was that it was more important to get it right. > SSL/TLS is (and has been for many years) part of the Internet infrastructure. > You don't make significant, totally incompatible changes to the infrastructure > without very carefully weighing the advantages and disadvantages. Which we did--including having the very discussion we are having now--and concluded that the course of action we took was the right one. You're of course free to weigh the evidence yourself and come to a different conclusion, and even to hold the opinion that those who agree with you are complete fools, but it's simply not accurate to imply, as you do here, that we didn't think about it. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From frantz at pwpconsult.com Sat Jan 24 18:22:21 2009 From: frantz at pwpconsult.com (Bill Frantz) Date: Sat, 24 Jan 2009 15:22:21 -0800 Subject: Bitcoin v0.1 released In-Reply-To: <20090124164803.A3B7414F6E1@finney.org> Message-ID: hal at finney.org ("Hal Finney") on Saturday, January 24, 2009 wrote: >Countermeasures by botnet operators would include moderating their take, >perhaps only stealing 10% of the productive capacity of invaded computers, >so that their owners would be unlikely to notice. This kind of thinking >quickly degenerates into unreliable speculation, but it points out the >difficulties of analyzing the full ramifications of a world where POW >tokens are valuble. Some people tell me that the 0wned machines are among the most secure on the network because botnet operators work hard to keep others from compromising "their" machines. I could see the operators moving toward being legitimate security firms, protecting computers against compromise in exchange for some of the proof of work (POW) money. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | When it comes to the world | Periwinkle (408)356-8506 | around us, is there any choice | 16345 Englewood Ave www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Sun Jan 25 07:04:59 2009 From: leichter at lrw.com (Jerry Leichter) Date: Sun, 25 Jan 2009 07:04:59 -0500 Subject: What EV certs are good for Message-ID: I just received a phishing email, allegedly from HSBC: Dear HSBC Member, Due to the high number of fraud attempts and phishing scams, it has been decided to implement EV SSL Certification on this Internet Banking website. The use of EV SSL certification works with high security Web browsers to clearly identify whether the site belongs to the company or is another site imitating that company's site.... (I hope I haven't quoted enough to trigger someone's spam detectors!) Needless to say, the message goes on to suggest clicking on a link to update your account. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From dan at geer.org Sat Jan 24 23:07:17 2009 From: dan at geer.org (dan at geer.org) Date: Sat, 24 Jan 2009 23:07:17 -0500 Subject: Bitcoin v0.1 released In-Reply-To: Your message of "Sat, 24 Jan 2009 15:22:21 PST." Message-ID: <20090125040718.2912034411@absinthe.tinho.net> Bill Frantz writes: -+----------------- | Some people tell me that the 0wned machines are among the most | secure on the network because botnet operators work hard to | keep others from compromising "their" machines. I could see the | operators moving toward being legitimate security firms, | protecting computers against compromise in exchange for some of | the proof of work (POW) money. I'm one of those people. Quoting from my speech of 1/20: > Virus attacks have, of course, become rarer over time, which is > to say that where infectious agents once ruled, today it is > parasites. Parasites have no reason to kill their hosts -- on > the contrary they want their hosts to survive well enough to > feed the parasite. A parasite will generally not care to be all > that visible, either. The difference between parasitism and > symbiosis can be a close call in some settings, and of the folks > who famously bragged of being able to take the Internet down in > twenty minutes, one has said that a computer may be better > managed once it is in a botnet than before since the bot-master > will be serious about closing the machine up tight against > further penetration and similarly serious about patch > management. Therefore, since one can then say that both the > machine's nominal owner and the bot master are mutually helped, > what we see is evolution from parasite to symbiont in action. > According to Margulis and Sagan, "Life did not take over the > globe by combat, but by networking." On this basis and others, > bot-nets are a life form. Rest of text upon request. Incidentally, I *highly* recommend Daniel Suarez's _Daemon_; trust me as to its relevance. Try this for a non-fiction taste: http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality --dan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From satoshi at vistomail.com Sun Jan 25 10:47:10 2009 From: satoshi at vistomail.com (Satoshi Nakamoto) Date: Sun, 25 Jan 2009 23:47:10 +0800 Subject: Bitcoin v0.1 released Message-ID: Hal Finney wrote: > > * Spammer botnets could burn through pay-per-send email filters > > trivially > If POW tokens do become useful, and especially if they become money, > machines will no longer sit idle. Users will expect their computers to > be earning them money (assuming the reward is greater than the cost to > operate). A computer whose earnings are being stolen by a botnet will > be more noticeable to its owner than is the case today, hence we might > expect that in that world, users will work harder to maintain their > computers and clean them of botnet infestations. Another factor that would mitigate spam if POW tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest POW tokens from spam. They'd essentially be reverse-spamming the spammers with automated mailboxes that collect their POW and don't read the message. The ratio of fake mailboxes to real people could become too high for spam to be cost effective. The process has the potential to establish the POW token's value in the first place, since spammers that don't have a botnet could buy tokens from harvesters. While the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers. Interestingly, one of the e-gold systems already has a form of spam called "dusting". Spammers send a tiny amount of gold dust in order to put a spam message in the transaction's comment field. If the system let users configure the minimum payment they're willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get paid to receive spam. Satoshi Nakamoto --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From gnu at toad.com Sun Jan 25 17:40:45 2009 From: gnu at toad.com (John Gilmore) Date: Sun, 25 Jan 2009 14:40:45 -0800 Subject: Proof of Work -> atmospheric carbon In-Reply-To: References: Message-ID: <200901252240.n0PMejwU002817@new.toad.com> > > If POW tokens do become useful, and especially if they become money, > > machines will no longer sit idle. Users will expect their computers to > > be earning them money (assuming the reward is greater than the cost to > > operate). Computers are already designed to consume much less electricity when idle than when running full tilt. This trend will continue and extend; some modern chips throttle down to zero MHz and virtually zero watts at idle, waking automatically at the next interrupt. The last thing we need is to deploy a system designed to burn all available cycles, consuming electricity and generating carbon dioxide, all over the Internet, in order to produce small amounts of bitbux to get emails or spams through. Can't we just convert actual money in a bank account into bitbux -- cheaply and without a carbon tax? Please? John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Mon Jan 26 02:49:31 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Mon, 26 Jan 2009 02:49:31 -0500 Subject: Obama's secure PDA Message-ID: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> As I'm sure many of you've heard by now, after some initial hesitation due to legal requirements regarding the preservation of presidential records, Mr. Obama has been allowed to continue using a wireless e- mail device after assuming the presidency. There are still conflicting reports about whether the hardware is an altered RIM BlackBerry or a different device, though the most likely contender for the latter option appears to be the General Dynamics Sect?ra Edge, which features a "trusted [secondary] display" and two buttons used to switch between classified and unclassified operation. Some details from Declan McCullagh: Manufacturer site and (not very detailed) specs: I know next to nothing about the state of the art of secure cell devices; do list members have any (public) knowledge or informed speculation about the mechanism behind the unclassified/classified switches? Are we talking two entire separate CPUs with a mutex-shared screen/keyboard? Or just offload of classified processing to a separate on-chip security domain (ala ARM TrustZone)? Similarly, the manufacturer lists separate class/unclass memory chips and separate class/unclass USB ports. Are these sitting on two physically separate buses? Finally, any idea why the Sect?ra is certified up to Top Secret for voice but only up to Secret for e-mail? (That is, what are the differing requirements?) Cheers, -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From paul.hoffman at vpnc.org Mon Jan 26 11:26:24 2009 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Mon, 26 Jan 2009 08:26:24 -0800 Subject: Obama's secure PDA In-Reply-To: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> Message-ID: At 2:49 AM -0500 1/26/09, Ivan Krsti? wrote: >There are still conflicting reports about whether the hardware is an altered RIM BlackBerry or a different device, though the most likely contender for the latter option appears to be the General Dynamics Sect?ra Edge, which features a "trusted [secondary] display" and two buttons used to switch between classified and unclassified operation. Government Computer News says it is definitely not a BlackBerry. However, GCN's reporters aren't always as good as they should be (or even as good as the regular IT press) on getting their facts straight on security issues. I too would like to hear more information on this, particularly the crypto that is known to be used on the Edge. --Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Mon Jan 26 15:08:32 2009 From: johnl at iecc.com (John Levine) Date: 26 Jan 2009 20:08:32 -0000 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <200901252240.n0PMejwU002817@new.toad.com> Message-ID: <20090126200832.17998.qmail@simone.iecc.com> >Can't we just convert actual money in a bank account into bitbux -- >cheaply and without a carbon tax? Please? If only. People have been saying for at least a decade that all we have to do to solve the spam problem is to charge a small fee for every message sent. Unfortunately, there's a variety of reasons that's never going to work. One of the larger reasons is that despite a lot of smart people working on micropayments, we have nothing approaching a system that will work for billions of tranactions per day, where 90% of the purported payments are bogus, along with the lack of any interface to the real world financial system that would scale and withstand the predictable attacks. My white paper could use a little updating, but the basic conclusions remain sound: http://www.taugh.com/epostage.pdf R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From tls at rek.tjls.com Mon Jan 26 15:30:49 2009 From: tls at rek.tjls.com (Thor Lancelot Simon) Date: Mon, 26 Jan 2009 15:30:49 -0500 Subject: Obama's secure PDA In-Reply-To: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> Message-ID: <20090126203048.GA21125@panix.com> On Mon, Jan 26, 2009 at 02:49:31AM -0500, Ivan Krsti? wrote: > > Finally, any idea why the Sect?ra is certified up to Top Secret for > voice but only up to Secret for e-mail? (That is, what are the differing > requirements?) I know no specific details but strongly suspect the difference in requirements, and thus certifications, stems from the likelyhood that the device stores (even very briefly) email and cached web objects, but does not store voice communications. Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Mon Jan 26 16:18:39 2009 From: leichter at lrw.com (Jerry Leichter) Date: Mon, 26 Jan 2009 16:18:39 -0500 Subject: Obama's secure PDA In-Reply-To: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> Message-ID: <0E7F2305-FF84-46E6-93A3-ACD8D024E0B2@lrw.com> On Jan 26, 2009, at 2:49 AM, Ivan Krsti? wrote: > [A]ny idea why the Sect?ra is certified up to Top Secret for voice > but only up to Secret for e-mail? (That is, what are the differing > requirements?) I have no information, but a guess: Phone conversation encryption, at all levels, has been around for many years. Email is a relative newcomer. Further, the problem for voice is inherently simpler: A conversation is transient. It's not expected to be recorded, and I'm sure the devices are designed to make recording a conversation difficult even for someone with full access to the phone. So you're dealing with establishing a secure session, with nothing left after the fact. If you're talking email, on the other hand, you're inherently dealing with information at rest. That changes the whole game, introducing issues of key management, maintenance of security level of time - a conversation once completed is gone, so the question of how to declassify it or move it to another compartment or whatever cannot arise - how to deal with forwarding, and so on. All of this is inherent in a usable email system. An email system for the White House has the additional complication of the Presidential Records Act: Phone conversations don't have to be recorded, but mail messages do (and have to remain accessible). It makes one wonder if this is a Sect?ra limitation, a Sect?ra-for- the-President limitation, or whether there is no Top Secret email infrastructure at all.... -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Mon Jan 26 16:56:19 2009 From: leichter at lrw.com (Jerry Leichter) Date: Mon, 26 Jan 2009 16:56:19 -0500 Subject: Obama's secure PDA In-Reply-To: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> Message-ID: <6A794151-EBAA-460D-83EE-E34C290FD49A@lrw.com> > I know next to nothing about the state of the art of secure cell > devices; do list members have any (public) knowledge or informed > speculation about the mechanism behind the unclassified/classified > switches? Are we talking two entire separate CPUs with a mutex- > shared screen/keyboard? Or just offload of classified processing to > a separate on-chip security domain (ala ARM TrustZone)? Similarly, > the manufacturer lists separate class/unclass memory chips and > separate class/unclass USB ports. Are these sitting on two > physically separate buses? The page you mention contains a link to a price list. The thing is surprisingly inexpensive: $3150. (Curiously, you have a choice of a 1 or 2 year warrantee. The second year adds $200 to the price. You can omit the wireless module and save $500 - presumably of interest if you already have one - they are also available separately - in Sprint, Verizon, GSM, and WiFi versions, for $700.) There are versions for the UK, Canada, NATO, and some other allies. There's a "Classified USB Cable for file transfer with Classified PC" which is "required for installing Classified Enclave Certificates". (Considering the obscene prices we pay for HDMI cables, this is a steal at only $75.) There is a similar "Unclassified USB Cable for file transfer with Unclass PC" which is "required for installing Unclassified Enclave Certificates". From the sound of it, this probably means the USB ports are set up to authenticate connections and, almost certainly, to encrypt everything that leaves the device. Any conversion to Unclassified form probably occurs on the receiving "Unclass PC". There are also both Classified and Unclassified keyboard/mouse USB cables. (These are marked as "delivery 6 months ARO" - everything else is available in 60 days. The obvious guess is that these don't really exist, but will be built if anyone wants them. For $100, there's a 2GB Micro SD card for Unclassified memory extension; the Classified memory apparently can't be extended. There's a mail server named "Apriva" that seems to go with this. Oh, and just to make everyone feel good about these things: They run Windows (mentioned in the FAQs). The FAQ, indirectly, answers the your previous question of why only Secret for email: Data-at-rest is encrypted using AES, which is only approved for Secret, not Top Secret, data. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Nicolas.Williams at sun.com Mon Jan 26 17:19:45 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Jan 2009 16:19:45 -0600 Subject: Obama's secure PDA In-Reply-To: <0E7F2305-FF84-46E6-93A3-ACD8D024E0B2@lrw.com> References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> <0E7F2305-FF84-46E6-93A3-ACD8D024E0B2@lrw.com> Message-ID: <20090126221944.GA1044@Sun.COM> On Mon, Jan 26, 2009 at 04:18:39PM -0500, Jerry Leichter wrote: > An email system for the White > House has the additional complication of the Presidential Records > Act: Phone conversations don't have to be recorded, but mail messages > do (and have to remain accessible). [OT for this list, I know.] It seems that the President's lawyers believe that IM is covered by the Presidential Records Act and shouldn't be used in the White House: http://www.newser.com/tag/31542/1/presidential-records-act.html http://www.newser.com/story/48239/team-obama-told-to-ditch-instant-messaging.html One possible workaround might be to allow WH staff to _receive_ IMs, and follow twitting from outside the WH, but not respond to any of it except by phone. (Even phone calls, though not recorded, are dangerous to the WH since there is a record of calls made and taken.) Of course, if there's nothing to hide, then, why not just use IM and be done? The legal advice seems sounds, but it's just advice. Obama and his staff could easily use and archive IMs and avoid embarrassment by, well, keeping discussions above board. Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From zookog at gmail.com Mon Jan 26 17:41:17 2009 From: zookog at gmail.com (Zooko O'Whielacronx) Date: Mon, 26 Jan 2009 15:41:17 -0700 Subject: Proof of Work -> atmospheric carbon Message-ID: On Jan 26, 2009, at 13:08 PM, John Levine wrote: > If only. People have been saying for at least a decade that all we > have to do to solve the spam problem is to charge a small fee for > every message sent. I was one of those people, a decade and a half ago, on the cypherpunks mailing list. In fact, as I recall I once discussed with John Gilmore after a Bay Area Cypherpunks Physical Meeting whether he would pay me to implement some sort of solution to spam, but we didn't agree on a strategy. > Unfortunately, there's a variety of reasons that's never going to work. Hey, the future is long. (We hope.) > One of the larger reasons is that despite a lot of smart people > working on micropayments, we have nothing approaching a system that > will work for billions of tranactions per day, where 90% of the > purported payments are bogus, along with the lack of any interface to > the real world financial system that would scale and withstand the > predictable attacks. Coincidentally, I just blogged today about how we are much closer to this now than we were then, even though none of the smart people that you were probably thinking of are involved in the new deployments: http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#%5B%5BDecentralized%20Money%5D%5D WoW-gold, for example, appears to have at least millions of transactions a day. Does anyone have more detail about the scale and scope of these currencies? > My white paper could use a little updating, but the basic conclusions > remain sound: > > http://www.taugh.com/epostage.pdf Thanks! I'll read this. Regards, Zooko --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Mon Jan 26 21:26:10 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 26 Jan 2009 21:26:10 -0500 Subject: Obama's secure PDA In-Reply-To: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> Message-ID: <20090126212610.7ab09af5@cs.columbia.edu> On Mon, 26 Jan 2009 02:49:31 -0500 Ivan Krsti? wrote: > Finally, any idea why the Sect?ra is certified up to Top Secret for > voice but only up to Secret for e-mail? (That is, what are the > differing requirements?) > I actually explained (my take on) that question to my class last week. Quite simply, voice offers one service -- voice. Data offers many services, and hence many venues for data-driven attacks: email (which includes many MIME types) and probably clicking on URLs, web (which includes HMTL, gif, jpeg, perhaps png, and almost certainly Javascript), and perhaps data files including pdf, Word, Powerpoint, and Excel. Any one of those data formats is far more complex than even compressed voice; the union of them makes me surprised it can handle even Secret data... Note especially that HTML involves IFRAMEs and third-party images, which means inherent cross-domain issues. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From benl at google.com Mon Jan 26 23:13:02 2009 From: benl at google.com (Ben Laurie) Date: Tue, 27 Jan 2009 15:13:02 +1100 Subject: What EV certs are good for In-Reply-To: References: Message-ID: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> On Sun, Jan 25, 2009 at 11:04 PM, Jerry Leichter wrote: > I just received a phishing email, allegedly from HSBC: > > Dear HSBC Member, > > Due to the high number of fraud attempts and phishing scams, it has been > decided to > implement EV SSL Certification on this Internet Banking website. > > The use of EV SSL certification works with high security Web browsers to > clearly > identify whether the site belongs to the company or is another site > imitating that > company's site.... > > (I hope I haven't quoted enough to trigger someone's spam detectors!) > Needless to say, the message goes on to suggest clicking on a link to > update your account. So did the link have a EV cert? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Tue Jan 27 09:04:45 2009 From: leichter at lrw.com (Jerry Leichter) Date: Tue, 27 Jan 2009 09:04:45 -0500 Subject: What EV certs are good for In-Reply-To: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> References: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> Message-ID: <19D986C5-859A-4E60-AC80-94EC5B1427E1@lrw.com> On Jan 26, 2009, at 11:13 PM, Ben Laurie wrote: > On Sun, Jan 25, 2009 at 11:04 PM, Jerry Leichter > wrote: >> I just received a phishing email, allegedly from HSBC: >> >> Dear HSBC Member, >> >> Due to the high number of fraud attempts and phishing scams, it >> has been >> decided to >> implement EV SSL Certification on this Internet Banking website. >> >> The use of EV SSL certification works with high security Web >> browsers to >> clearly >> identify whether the site belongs to the company or is another site >> imitating that >> company's site.... >> >> (I hope I haven't quoted enough to trigger someone's spam detectors!) >> Needless to say, the message goes on to suggest clicking on a link to >> update your account. > > So did the link have a EV cert? I didn't try it! While Safari on a Mac has been reasonably secure, it's not been *entirely* immune to attacks, and it didn't seem like a good idea to tempt fate. It might be useful to put together a special-purpose HTTPS client which would initiate a connection and tell you about the cert returned, then exit. Absent a nasty bug in SSL itself, that should be pretty safe. (The client might want to go through TOR to avoid adding your IP address to some spammer database of "IP's that follow links found in spam", though in practice I doubt that matters much - there are enough likely victims out there that such a database probably wouldn't be worth the bother.) -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From William.Soley at Sun.COM Tue Jan 27 13:14:49 2009 From: William.Soley at Sun.COM (William Soley) Date: Tue, 27 Jan 2009 10:14:49 -0800 Subject: What EV certs are good for In-Reply-To: <19D986C5-859A-4E60-AC80-94EC5B1427E1@lrw.com> References: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> <19D986C5-859A-4E60-AC80-94EC5B1427E1@lrw.com> Message-ID: <7CF09ED3-F552-4BA1-B690-1FC03F98A08A@Sun.COM> On Jan 27, 2009, at 6:04 AM, Jerry Leichter wrote: > It might be useful to put together a special-purpose HTTPS client > which would initiate a connection and tell you about the cert > returned, then exit. I use ... openssl s_client -connect www.whatever.com:443 -showcerts Ships with Mac OS, Solaris, Linux, etc. -Bill --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From fungi at yuggoth.org Tue Jan 27 13:46:21 2009 From: fungi at yuggoth.org (The Fungi) Date: Tue, 27 Jan 2009 18:46:21 +0000 Subject: What EV certs are good for In-Reply-To: <19D986C5-859A-4E60-AC80-94EC5B1427E1@lrw.com> References: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> <19D986C5-859A-4E60-AC80-94EC5B1427E1@lrw.com> Message-ID: <20090127184619.GQ2927@yuggoth.org> On Tue, Jan 27, 2009 at 09:04:45AM -0500, Jerry Leichter wrote: [...] > It might be useful to put together a special-purpose HTTPS client > which would initiate a connection and tell you about the cert > returned, then exit. [...] I often use this (though there's probably an easier way)... echo|openssl s_client -connect www.example.com:https|openssl x509 -text Quick and dirty, but gets the job done. -- { IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657); SMTP(fungi at yuggoth.org); IRC(fungi at irc.yuggoth.org#ccl); ICQ(114362511); AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi at yuggoth.org); MUD(fungi at katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); } --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From hal at finney.org Tue Jan 27 14:35:43 2009 From: hal at finney.org (Hal Finney) Date: Tue, 27 Jan 2009 11:35:43 -0800 (PST) Subject: Proof of Work -> atmospheric carbon Message-ID: <20090127193543.67F9314F6E1@finney.org> John Gilmore writes: > The last thing we need is to deploy a system designed to burn all > available cycles, consuming electricity and generating carbon dioxide, > all over the Internet, in order to produce small amounts of bitbux to > get emails or spams through. It's interesting to consider the ultimate technological resolution to this issue. Will a global-scale proof-of-work based system inherently consume substantial amounts of energy? Or are there ways of doing computing which would allow such a system to use only moderate energy consumption? This question relates to the thermodynamics of computation. It has long been known that logically reversible transformations can be done with arbitrarily low energy dissipation. Hence attention is focused on irreversible transformations, particularly those that require bit erasure. Erasing a bit dissipates approximately energy of approximately kT where k is Boltzmann's constant and T is temperature. The question is whether a POW system inherently involves a great deal of irreversible logical transitions, causing bit erasure and dissipating energy? Or could a POW token be created using solely reversible logic? One note is that any algorithm can in principle be made reversible except for the size of the output: compute it using reversible logic, possibly creating many excess bits which will allow the reversal, until we get the answer; then make a copy of the output; then reverse the calculation, consuming all the excess bits until we get back to the original value. The only irreversible step was saving the output. However this is impractical for large calculations like we are talking about, because the number of excess bits would dwarf the size of the calculation. The hash collisions used in systems like Bitcoin or Hashcash (technically not collisions, rather searches for pre-images of hash values with many leading zero bits) seem inherently irreversible. The algorithm typically sets up a pre-image that includes a counter value, computes the hash, increments the counter and repeats until a hash is found with the desired properties. The hash function itself typically uses many intrinsically irreversible transitions, since logical irreversibility is a defining requirement of a hash function. Even if we use the trick in the preceding paragraph to eliminate the cost of the intermediate steps in computing the hash, we would still need to erase the output result each iteration, dissipating energy. Typical POW systems in use today require millions to billions of iterations, and this would be likely to increase in the future, so the dissipation could be substantial. Replacing the hash with a logically invertible function might help to reduce the number of intermediate bits, and eliminate the need to use the run-backwards trick. One would require that both the pre-image and the post-image contain a number of bits in fixed positions. However this would still seem to require the same kind of search algorithm, causing dissipation as each intermediate result is erased. Perhaps a variation on this idea would work, if the logically invertible function was itself very slow, perhaps paramaterized to have a huge number of rounds. Then only a relatively small number of iterations would be needed before a lucky result is found, for a given level of POW effort. This would reduce dissipation. However it would slow down verification, and since verification of the POW will be done far more often than creation, we can't afford to tip things too far in that direction. Another idea I had was to use a deterministic POW rather than a random one like hash collision. Cryptographic work on "timed commitments" and related topics has shown that repeated squarings modulo an unknown RSA modulus allow for a relatively concise and quickly verifiable proofs that some very large number of squarings had taken place, with no shortcuts possible for the creation of the resulting certification. Broadly speaking, modular squaring is logically reversible, in that one could theoretically compute the square root. But in practice, as with the hash computation, computing a modular square using logically reversible operations will produce a large number of excess bits. Even if the excess from a single squaring could be consumed using the trick mentioned above, one would still be forced to erase the temporarily result of each individual squaring operation, as the POW would require a very large number of squarings. So the overall dissipation would appear to be similar to the hash computation. (Also, it's not clear that a deterministic POW works well for an application like Bitcoin; it might let the owner of the fastest computer win every POW race, giving him too much power.) So the question from John's challenge remains open: is there a POW system which could be built solely on logically reversible computation? The computation has to be intrinsically time consuming, but with a short and quickly verifiable certificate of validity. Hal Finney --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From benl at google.com Tue Jan 27 21:35:26 2009 From: benl at google.com (Ben Laurie) Date: Wed, 28 Jan 2009 13:35:26 +1100 Subject: What EV certs are good for In-Reply-To: <7CF09ED3-F552-4BA1-B690-1FC03F98A08A@Sun.COM> References: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> <19D986C5-859A-4E60-AC80-94EC5B1427E1@lrw.com> <7CF09ED3-F552-4BA1-B690-1FC03F98A08A@Sun.COM> Message-ID: <1b587cab0901271835u48b4ff96nbb0bcb024d4dfe88@mail.gmail.com> On Wed, Jan 28, 2009 at 5:14 AM, William Soley wrote: > On Jan 27, 2009, at 6:04 AM, Jerry Leichter wrote: >> >> It might be useful to put together a special-purpose HTTPS client which >> would initiate a connection and tell you about the cert returned, then exit. > > I use ... > > openssl s_client -connect www.whatever.com:443 -showcerts > > Ships with Mac OS, Solaris, Linux, etc. And to use TOR, put "torify" on the front. Having run the tor server, of course. Except on MacOS, where torify doesn't (can't? Does anyone know better) work. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Tue Jan 27 23:52:29 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 28 Jan 2009 17:52:29 +1300 Subject: Obama's secure PDA In-Reply-To: <6A794151-EBAA-460D-83EE-E34C290FD49A@lrw.com> Message-ID: Jerry Leichter writes: >There's a "Classified USB Cable for file transfer with Classified PC" I wonder what a "classified USB cable" is. Perhaps it's an unclassified USB cable with the little three-prong USB logo blacked out by the censors. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Wed Jan 28 09:54:24 2009 From: johnl at iecc.com (John Levine) Date: 28 Jan 2009 14:54:24 -0000 Subject: What EV certs are good for In-Reply-To: <1b587cab0901262013w64f6a6f5r395e9300632af1b5@mail.gmail.com> Message-ID: <20090128145424.79445.qmail@simone.iecc.com> >> I just received a phishing email, allegedly from HSBC: >> >> Dear HSBC Member, >So did the link have a EV cert? Hardly matters. HSBC has vast numbers of web servers all over the world, some with EV certs, some without. For example, their US customer site for deposit customers at https://www.us.hsbc.com/ doesn't, but their site for credit cards at https://www.hsbccreditcard.com/ does, although it's kind of hard to tell because they tend to put you on a non-https page until you log in. R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Wed Jan 28 14:03:57 2009 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 28 Jan 2009 14:03:57 -0500 Subject: Obama's secure PDA In-Reply-To: (Peter Gutmann's message of "Wed\, 28 Jan 2009 17\:52\:29 +1300") References: Message-ID: <8763jz9rs2.fsf@snark.cb.piermont.com> pgut001 at cs.auckland.ac.nz (Peter Gutmann) writes: > Jerry Leichter writes: > >>There's a "Classified USB Cable for file transfer with Classified PC" > > I wonder what a "classified USB cable" is. Perhaps it's an unclassified USB > cable with the little three-prong USB logo blacked out by the censors. I would imagine it is a tempest shielded cable, and appropriately altered connectors. Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Wed Jan 28 13:26:08 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 28 Jan 2009 13:26:08 -0500 Subject: full-disk encryption standards released Message-ID: <20090128132608.6616926f@cs.columbia.edu> http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9126869&intsrc=hm_ts_head --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Wed Jan 28 16:19:04 2009 From: johnl at iecc.com (John Levine) Date: 28 Jan 2009 21:19:04 -0000 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <20090127193543.67F9314F6E1@finney.org> Message-ID: <20090128211904.73633.qmail@simone.iecc.com> >(Also, it's not clear that a deterministic POW works well for an >application like Bitcoin; it might let the owner of the fastest computer >win every POW race, giving him too much power.) Indeed. And don't forget that through the magic of botnets, the bad guys have vastly more compute power available than the good guys. You know those crackpot ideas that keep showing up in snake oil crypto? Well, e-postage is snake oil antispam. R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Wed Jan 28 16:35:50 2009 From: leichter at lrw.com (Jerry Leichter) Date: Wed, 28 Jan 2009 16:35:50 -0500 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <20090127193543.67F9314F6E1@finney.org> References: <20090127193543.67F9314F6E1@finney.org> Message-ID: On Jan 27, 2009, at 2:35 PM, Hal Finney wrote: > John Gilmore writes: >> The last thing we need is to deploy a system designed to burn all >> available cycles, consuming electricity and generating carbon >> dioxide, >> all over the Internet, in order to produce small amounts of bitbux to >> get emails or spams through. > > It's interesting to consider the ultimate technological resolution > to this > issue. Will a global-scale proof-of-work based system inherently > consume > substantial amounts of energy? Or are there ways of doing computing > which would allow such a system to use only moderate energy > consumption? ... [Proposals to use reversible computation, which in principle consume no energy, elided.] There's a contradiction here between the computer science and economic parts of the problem being discussed. What gives a digital coin value is exactly that there is some real-world expense in creating it. We talk about "proof of work", but in fact "work" done by a computer doesn't, in and of itself, have any value. It gets a value only when it's a limited resource *which might have been used for something else* - i.e., the value of the spare cycles that might be thrown at doing the computations comes from the opportunity cost incurred. If this were not so, anyone could just create as many as they wanted at no cost to themselves. In fact, this is behind the cost model 'bot herders using other people's machines. But ultimately that only works for the 'bot herders because there is no significant loss to the owners of those machines either! Now, if instead we used algorithms not based on some abstraction notion of "work", but on the equivalent power that had to be dissipated to do the computation, then the value of a digital token would truly be grounded in the real world. Spare cycles would no longer be "free" - they would show up on your power bill. Sure, the 'bot herders wouldn't have to pay - but if the owners of the "pwned" machines saw a real cost, they would have an incentive to do something about it (which they basically don't, today). Eliminating the power cost puts you back to amortizing the fixed cost of the CPU and memory doing the computation - a cost that's dropping all the time. I don't see how you get to an economically viable mechanism that way. So, how do you tie the cost of a token to power? Curiously, something of the sort has already been proposed. It's been pointed out - I'm afraid I don't have the reference - that CPU's keep getting faster and more parallel and a high rate, but memories, while they are getting enormously bigger, aren't getting much faster. So what the paper I read proposed is hash functions that are expensive, not in CPU seconds, but in memory reads and writes. Memory writes are inherently non-reversible so inherently cost power; a high-memory-write algorithm is also one that uses power. (BTW, a number of years back, a VC friend ran by me a proposal to buy the spare cycles on people's set-top boxes - which have pretty hefty chips in them - and rent out the resulting "distributed compute server". The claim was that you didn't have to pay people much of anything for use of their boxes - you'd only do it when they were otherwise unoccupied, so they should be happy to get even very small payments. I pointed out the cost they had neglected: Increased power use. Sure, individuals probably wouldn't notice - but at some point some consumer organization would. The resulting bad publicity would kill the business. We did a bit of calculation to add that in to what would be paid to the box owners and the whole enterprise started looking less interesting from a purely economic point of view - not that it didn't have plenty of other problems.) -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Wed Jan 28 16:42:26 2009 From: leichter at lrw.com (Jerry Leichter) Date: Wed, 28 Jan 2009 16:42:26 -0500 Subject: Obama's secure PDA In-Reply-To: <8763jz9rs2.fsf@snark.cb.piermont.com> References: <8763jz9rs2.fsf@snark.cb.piermont.com> Message-ID: <9996D647-F01F-452C-90DD-7C4033216D38@lrw.com> On Jan 28, 2009, at 2:03 PM, Perry E. Metzger wrote: >> >>> There's a "Classified USB Cable for file transfer with Classified >>> PC" >> >> I wonder what a "classified USB cable" is. Perhaps it's an >> unclassified USB >> cable with the little three-prong USB logo blacked out by the >> censors. > > I would imagine it is a tempest shielded cable, and appropriately > altered connectors. That's probably a big part of it. I commented earlier that $3200 seemed surprisingly cheap. One of the articles on this claimed this was absurdly expensive - typical DoD gold plating. Well ... the real price of a standard Blackberry is a couple of hundred dollars, and put one in a room with a speaker phone and listen to the famous "Blackberry buzz". Shielding these things, even to avoid obvious interference, is *not* easy. Getting it to Tempest specs must take some impressive engineering. For a non-mass- market device with that kind of engineering, $3200 seems pretty cheap. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Wed Jan 28 18:38:43 2009 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 28 Jan 2009 18:38:43 -0500 Subject: hash trees to protect court evidence for genocide trials Message-ID: <87bptrj918.fsf@snark.cb.piermont.com> http://www.nytimes.com/2009/01/27/science/27arch.html -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ian.farquhar at rsa.com Wed Jan 28 18:49:29 2009 From: ian.farquhar at rsa.com (ian.farquhar at rsa.com) Date: Wed, 28 Jan 2009 18:49:29 -0500 Subject: Obama's secure PDA In-Reply-To: <8763jz9rs2.fsf@snark.cb.piermont.com> References: <8763jz9rs2.fsf@snark.cb.piermont.com> Message-ID: <21F6076E016FB149944A4D450EFFDCE502940EE9@CORPUSMX50B.corp.emc.com> Perry wrote: pgut001 at cs.auckland.ac.nz (Peter Gutmann) writes: >> I wonder what a "classified USB cable" is. Perhaps it's an unclassified USB >> cable with the little three-prong USB logo blacked out by the censors. > I would imagine it is a tempest shielded cable, and appropriately > altered connectors. It would definitely be shielded, but I doubt it's TEMPEST qualified at that price point. I suspect it's just a USB cable with a keyed connector, to enforce red/black sep in this somewhat atypical environment (eg. section 5.4.6.1.1.2 of MIL-HDBK-232A) Ian. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From arshad.noor at strongauth.com Wed Jan 28 19:09:12 2009 From: arshad.noor at strongauth.com (Arshad Noor) Date: Wed, 28 Jan 2009 16:09:12 -0800 Subject: full-disk encryption standards released In-Reply-To: <20090128132608.6616926f@cs.columbia.edu> References: <20090128132608.6616926f@cs.columbia.edu> Message-ID: <4980F3A8.4080209@strongauth.com> Steven M. Bellovin wrote: > http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9126869&intsrc=hm_ts_head I wonder if the 40+ breach-disclosure laws in US will now have to be updated to reflect that if data is breached on a "live" system using an encrypted-drive, one must still make the breach disclosure. The CEO of Heartland Payment Systems, however, will no longer be fooled by the salve that FDE drives promise; he's calling for end-to-end encryption, a control which he - and readers of this forum - know, the FDE drives cannot provide: http://www.snl.com/irweblinkx/file.aspx?IID=4094417&FID=7249269 Arshad Noor StrongAuth, Inc. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From frantz at pwpconsult.com Wed Jan 28 19:14:30 2009 From: frantz at pwpconsult.com (Bill Frantz) Date: Wed, 28 Jan 2009 16:14:30 -0800 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <20090128211904.73633.qmail@simone.iecc.com> Message-ID: johnl at iecc.com (John Levine) on Wednesday, January 28, 2009 wrote: >You know those crackpot ideas that keep showing up in snake oil crypto? >Well, e-postage is snake oil antispam. While I think this statement may be true for POW coinage, because for a bot net it "grows on trees", for money that traces back to the international monetary exchange system, it may not be completely true. Snail mail postage limits, but does not eliminate junk mail. I think, without proof, that most people can live with the amount of junk mail they receive. At least I don' hear a lot of conversations about the "Junk mail problem". Now it is certainly true that if machines have a small amount of money stored within them for "postage", someone who 0wns that machine could steal some of that money. There is a limit to the amount that can be stolen based on the person who pays for the machine noticing and being bothered. There is probably safe profit in skimming small amounts from large number of machines just like there was profit in skimming the round off in payroll calculations. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Nicolas.Williams at sun.com Wed Jan 28 18:52:37 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 Jan 2009 17:52:37 -0600 Subject: Proof of Work -> atmospheric carbon In-Reply-To: References: <20090127193543.67F9314F6E1@finney.org> Message-ID: <20090128235236.GR1044@Sun.COM> On Wed, Jan 28, 2009 at 04:35:50PM -0500, Jerry Leichter wrote: > [Proposals to use reversible computation, which in principle consume > no energy, elided.] > > There's a contradiction here between the computer science and economic > parts of the problem being discussed. What gives a digital coin value > is exactly that there is some real-world expense in creating it. For some definition of "digital coin." An alternative design where all coins are double-spend checked against on-line infrastructure belonging to the issuer don't have this constraint. Though they have different properties. For example, anonymity might then depend on trusting mixmaster-type networks to exchange coins the issuer knows you have for coins that the issuer doesn't know you have, but that might make anonymity entirely impractical. But then, how practical are POW coins anyways? I suspect most people in the formal sectors of most economies would gladly live with digital credit/bank cards most of the time and to heck with digital coins. > So, how do you tie the cost of a token to power? Curiously, something > of the sort has already been proposed. It's been pointed out - I'm > afraid I don't have the reference - that CPU's keep getting faster and > more parallel and a high rate, but memories, while they are getting > enormously bigger, aren't getting much faster. So what the paper I > read proposed is hash functions that are expensive, not in CPU > seconds, but in memory reads and writes. Memory writes are inherently > non-reversible so inherently cost power; a high-memory-write algorithm > is also one that uses power. Clever! Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From david_koontz at xtra.co.nz Wed Jan 28 22:27:11 2009 From: david_koontz at xtra.co.nz (David G. Koontz) Date: Thu, 29 Jan 2009 16:27:11 +1300 Subject: Obama's secure PDA In-Reply-To: <9996D647-F01F-452C-90DD-7C4033216D38@lrw.com> References: <8763jz9rs2.fsf@snark.cb.piermont.com> <9996D647-F01F-452C-90DD-7C4033216D38@lrw.com> Message-ID: <4981220F.5060206@xtra.co.nz> Jerry Leichter wrote: > I commented earlier that $3200 seemed surprisingly cheap. One of the > articles on this claimed this was absurdly expensive - typical DoD gold > plating. Well ... the real price of a standard Blackberry is a couple > of hundred dollars, and put one in a room with a speaker phone and > listen to the famous "Blackberry buzz". Shielding these things, even to > avoid obvious interference, is *not* easy. Getting it to Tempest specs > must take some impressive engineering. For a non-mass-market device > with that kind of engineering, $3200 seems pretty cheap. Quite a few TEMPEST approved devices are rather innocuous looking these days, the PDA a case in point. Having been present during the big TEMPEST adoption in the military (early 70's) and the introduction of FCC Part 15 (late 70's) I'd think that shielding requirements for compromising emanations are at least extremely closely related to EMI prevention. There's also Red/Black separation, electrical and physical isolation between circuitry carrying classified signals and those not. If I were to hazard a guess TEMPEST requirements are close to those found for VDE/CE approval today (a bit more stringent than FCC). I would expect that the reason for 'approved' cables has to do with insuring construction to an approved standard perhaps with some actual testing thrown in. The amount of shielding required in cabling is on par with the use of shielded twisted pairs. The additional cost of TEMPEST approved equipment primarily comes from design testing and certification. The engineering is otherwise on par with COTS best practices (today). I used to work on a non HY-11 CVSD secure voice link utilizing a KG-13/TSEC Key Generator, used in support of what we publicly know now as the National Reconnaissance Office. Got a late night call from the security officer complaining about picking up an AM radio station on the secure phone handset. The installation had a plan, nice Red/Black separation, ferrous conduits enclosing cabling, physical distance separations, power line filtering and separate power circuits, the whole nine yards. To make a long story short it was picking up the radio station because of a ground loop in the shield for the receive phone pair and a cold solder joint. Re-flowing the solder joint was sufficient to stop the impromptu crystal radio, and I broke the ground loop as well and sent off an annotated copy of the installation wiring diagram to the engineer who did the installation plan. The ground loop mixed inside and outside grounds exposing the shield for the receive pair to broadcast signals, this particularly strong local AM station in point. The cold solder joint acted as a rectifier. Working a few years later for a local video game company, one late night I had occasion to listen to the same AM station on the speaker of an arcade video game we were prototyping. That was cured by twisting a pair in the wiring harness. The next year FCC Part 15 was slated to go into effect and was causing all sorts of industry panic. A year or two later we were still seeing significant EMI from computer equipment. My upstairs neighbor's Apple II used to cause some serious interference with my TV reception using a pair of rabbit ears, some of the biggest EMI culprits for the longest time were power supplies. Today your desktop or laptop PC is generating a significant amount of power across various portions of the spectrum including up into the Giga Hertz range. The amount of EMI produced is closely on par with TEMPEST approved equipment, and the greatest threat to producing EMI or compromising emanations (following the demise of CRT displays) is cabled peripherals. The difference is that it isn't TEMPEST certified, nor has it necessarily been design with Red/Black separation in mind. There'd be strong motivation to use tested and approved cables in classified data handling equipment. While the reduction in EMI for any equipment is largely due to management of signal and power return paths, reduction in power by using smaller signal amplitudes, lower edge rates (rise and fall times as opposed to data rate) filtering and where necessary shielding. Connect one little cheap cable and the next thing you know someone is complaining about receiving AM broadcasts on their fancy (and expensive) secure voice system, or worse, being surveilled without knowing it. I'm not surprised you can hear a Blackberry with a speaker phone. It's got a radio transmitter, and more than likely the speaker phone has an RJ-11 connector on a long straight conductor cable. As a guess we'd be talking about a Blackberry within a couple of meters, and that phone wire strung across a conference table before reaching the floor. http://www.blackberry.com/solutions/pdfs/Healthcare/Wireless_EMI_in_Healthcare_Facilities_White_Paper.pdf You could note a preponderance of phone sensitivity due to proximity (Page 10). A secure handset will do the same thing. The difference is that there won't be any 'plaintext' from the secure phone detectable on the speaker phone. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Thu Jan 29 00:44:03 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 29 Jan 2009 18:44:03 +1300 Subject: full-disk encryption standards released In-Reply-To: <20090128132608.6616926f@cs.columbia.edu> Message-ID: "Steven M. Bellovin" writes: >http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9126869&intsrc=hm_ts_head >From a quick look at what's just been released (https://www.trustedcomputinggroup.org/groups/storage/) it doesn't actually tell you anything about how to do disk encryption, it's just... well I'll have to quote the doc itself because I'm not quite sure what its purpose is, but the document claims it's an "architecture for putting Storage Devices under policy control as determined by the trusted platform host". Reading through the Opal spec ("minimum requirements for storage devices used in PCs and laptops") is like reading a SCSI CDB reference, it outlines a means of connecting something over here with something else over there with no indication of what either of the two something's are. It seems to be mostly intended to be a means of tying a hard drive into the TPM framework, with the entire crypto-related portions of the Opal spec being: 2.4 Cryptographic Features An Opal SSC compliant SD SHALL implement Full Disk Encryption for all host accessible user data stored on media. AES-128 or AES-256 SHALL be supported (see [FIPS 197]). 2.5 Authentication An Opal SSC compliant SD SHALL support password authorities and authentication. There's an older draft from 2007 covering storage architecture which is... um... 266 pages of the sort of thing you'd expect to emerge if the TCG tried to define a standard for dealing with hard drives. So I wouldn't call these "full-disk encryption standards", it's more like "TPM glue for hard drives". The P1619/SISWG work is completely different, you can actually take this and implement drive encryption from it, and it specifies (in some detail) how to do it right. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From paul at ciphergoth.org Thu Jan 29 03:58:22 2009 From: paul at ciphergoth.org (Paul Crowley) Date: Thu, 29 Jan 2009 08:58:22 +0000 Subject: full-disk encryption standards released In-Reply-To: <20090128132608.6616926f@cs.columbia.edu> References: <20090128132608.6616926f@cs.columbia.edu> Message-ID: <49816FAE.4000702@ciphergoth.org> Steven M. Bellovin wrote: > http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9126869&intsrc=hm_ts_head I think the standard itself is here: https://www.trustedcomputinggroup.org/specs/Storage/ Browsing "TCG Storage Security Subsystem Class: Opal", I'm having a hard time seeing where the actual cryptography is specified. They mention that they use AES but I can't see where they tell us what mode of operation they are using. -- __ \/ o\ Paul Crowley /\__/ www.ciphergoth.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From d3e3e3 at gmail.com Thu Jan 29 10:07:42 2009 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Thu, 29 Jan 2009 10:07:42 -0500 Subject: "Attack of the Wireless Worms" Message-ID: <1028365c0901290707t6d530031i3a63368a11f6e595@mail.gmail.com> "Recent research has shown that a new and disturbing form of computer infection is readily spread: the epidemic copying of malicious code among wireless routers without the participation of intervening computers. Such an epidemic could easily strike cities, where the ranges of wireless routers often overlap." ============================= Donald E. Eastlake 3rd d3e3e3 at gmail.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Thu Jan 29 15:55:19 2009 From: johnl at iecc.com (John Levine) Date: 29 Jan 2009 20:55:19 -0000 Subject: Proof of Work -> atmospheric carbon In-Reply-To: Message-ID: <20090129205519.66149.qmail@simone.iecc.com> >>You know those crackpot ideas that keep showing up in snake oil crypto? >>Well, e-postage is snake oil antispam. > >While I think this statement may be true for POW coinage, because for a bot >net it "grows on trees", for money that traces back to the international >monetary exchange system, it may not be completely true. It's close enough to completely true. Stealing postage via bots is only one of multiple fatal problems. I wrote this white paper in 2004; some of the details could stand a little update but the conclusions are as clear as ever: http://www.taugh.com/epostage.pdf R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Thu Jan 29 16:12:08 2009 From: leichter at lrw.com (Jerry Leichter) Date: Thu, 29 Jan 2009 16:12:08 -0500 Subject: "Attack of the Wireless Worms" In-Reply-To: <1028365c0901290707t6d530031i3a63368a11f6e595@mail.gmail.com> References: <1028365c0901290707t6d530031i3a63368a11f6e595@mail.gmail.com> Message-ID: On Jan 29, 2009, at 10:07 AM, Donald Eastlake wrote: > "Recent research has shown that a new and disturbing form of computer > infection is readily spread: the epidemic copying of malicious code > among wireless routers without the participation of intervening > computers. Such an epidemic could easily strike cities, where the > ranges of wireless routers often overlap." > > > It's worth reading both the original article that describes the simulation - cited in the blog entry as http://arxiv.org/abs/0706.3146 - and the actual blog entry, which is much more reasonable. The original article posits that, if you can get onto a wireless network, you can load an update into the wireless router. (They should have said "access point", but ignore that; the confusion is now so well established that it doesn't much matter.) Given that assumption, and further given the assumption that not only could you do it, you could write a virus that would do it for you, across a wide variety of router models from multiple vendors, they use some simulations to determine how long it would take to infect all the routers in several "well-wirelessed" metropolitan areas. The numbers come out to a matter of days to hours. Their only recommendation is that everyone use WPA2 with a strong password. Of course, I could equally well write a paper on the assumption that car computers could infect other car computers by modulating the headlights, and then calculate how long it would take a virus to spread through all the cars in a city. Maybe we all need to cover the headlights of our cars "for security". Access to a wireless network is a long way from administrative access to the router for that network. Granted, some devices have weak administrative passwords. That's certainly a problem - but the right approach to fixing *that* problem is, well, to fix that problem: Use a strong password. It's very rare that anyone needs admin access to their wireless routers. There's no reason not to choose a complex password, write it on sticker, and attach it to the router: If someone has physical access to your router, your security is gone anyway. The Spectrum article makes this point, and also points out that this would be a non-problem if vendors shipped routers with unique passwords pre-set on them. (In fact, DSL routers - and probably cable routers - typically come that way. They can also usually be set to permit admin access only from the "home" side, not the "network" side - as some wireless routers can be set to allow admin access only from their wired ports.) There are many real problems around, but there are also many pseudo- problems. The pseudo-problems do let you publish neat papers sometimes, but it's important not to take them *too* seriously. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From gnu at toad.com Thu Jan 29 16:22:37 2009 From: gnu at toad.com (John Gilmore) Date: Thu, 29 Jan 2009 13:22:37 -0800 Subject: full-disk subversion standards released In-Reply-To: References: Message-ID: <200901292122.n0TLMbwU026364@new.toad.com> If it comes from the "Trusted Computing Group", you can pretty much assume that it will make your computer *less* trustworthy. Their idea of a trusted computer is one that random unrelated third parties can trust to subvert the will of the computer's owner. John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From benl at google.com Thu Jan 29 21:32:11 2009 From: benl at google.com (Ben Laurie) Date: Fri, 30 Jan 2009 13:32:11 +1100 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <200901252240.n0PMejwU002817@new.toad.com> References: <200901252240.n0PMejwU002817@new.toad.com> Message-ID: <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> On Mon, Jan 26, 2009 at 9:40 AM, John Gilmore wrote: >> > If POW tokens do become useful, and especially if they become money, >> > machines will no longer sit idle. Users will expect their computers to >> > be earning them money (assuming the reward is greater than the cost to >> > operate). > > Computers are already designed to consume much less electricity when > idle than when running full tilt. This trend will continue and > extend; some modern chips throttle down to zero MHz and virtually zero > watts at idle, waking automatically at the next interrupt. > > The last thing we need is to deploy a system designed to burn all > available cycles, consuming electricity and generating carbon dioxide, > all over the Internet, in order to produce small amounts of bitbux to > get emails or spams through. Richard Clayton and I claim that PoW doesn't work: http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Thu Jan 29 23:17:57 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Thu, 29 Jan 2009 23:17:57 -0500 Subject: Obama's secure PDA In-Reply-To: References: <3CA8BF10-C7A2-415D-BFAA-09418B04101B@solarsail.hcs.harvard.edu> Message-ID: Multiple responses inline: On Jan 26, 2009, at 11:26 AM, Paul Hoffman wrote: > I too would like to hear more information on this, particularly the > crypto that is known to be used on the Edge. See sections 'Secure Speech Processing' and 'Interoperability' of . The standard suites are used, as one would expect. On Jan 26, 2009, at 4:56 PM, Jerry Leichter wrote: > The FAQ, indirectly, answers the your previous question of why only > Secret for email: Data-at-rest is encrypted using AES, which is > only approved for Secret, not Top Secret, data. This isn't the case; AES is approved for Top Secret with 192- or 256- bit keys, per . On Jan 26, 2009, at 9:26 PM, Steven M. Bellovin wrote: > Quite simply, voice offers one service -- voice. Data offers many > services, and hence many venues for data-driven attacks: email > (which includes many MIME types) and probably clicking on URLs, web > (which includes HMTL, gif, jpeg, perhaps png, and almost certainly > Javascript), and perhaps data files including pdf, Word, Powerpoint, > and Excel. Any one of those data formats is far more complex than > even compressed voice; the union of them makes me surprised it can > handle even Secret data... Note especially that HTML involves > IFRAMEs and third-party images, which means inherent cross-domain > issues. I've thought about this, but I don't buy it. I'm a heavy user of wireless e-mail, but I use it as nothing more than a SMTP-addressable SMS service without a length limit. In other words, people can send me messages from a computer and not just from a mobile handset (true in the other direction, too), and I can read and write more than 160 characters at a time. I'd find mobile e-mail just as useful if it went through a proxy that stripped out _everything_ that's not plaintext. I open attachments on my phone about once in a blue moon, and wouldn't miss the ability if it were gone. Cheers, -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Thu Jan 29 23:46:27 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 30 Jan 2009 17:46:27 +1300 Subject: "Attack of the Wireless Worms" In-Reply-To: <1028365c0901290707t6d530031i3a63368a11f6e595@mail.gmail.com> Message-ID: Donald Eastlake writes: >"Recent research has shown that a new and disturbing form of computer >infection is readily spread: the epidemic copying of malicious code >among wireless routers without the participation of intervening >computers. Such an epidemic could easily strike cities, where the >ranges of wireless routers often overlap." Does anyone know whether anything like this actually exists? I've seen earlier work in this area that was either man-in-the-router proof-of-concept stuff or simulation (as this work appears to be), but I don't know of any in-the-wild mesh-network malware. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From thisnukes4u at gmail.com Fri Jan 30 13:40:12 2009 From: thisnukes4u at gmail.com (Thomas Coppi) Date: Fri, 30 Jan 2009 11:40:12 -0700 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <20090128211904.73633.qmail@simone.iecc.com> References: <20090127193543.67F9314F6E1@finney.org> <20090128211904.73633.qmail@simone.iecc.com> Message-ID: <5e04a4c60901301040m689b9f62y9dad80f162ad296c@mail.gmail.com> On Wed, Jan 28, 2009 at 2:19 PM, John Levine wrote: > Indeed. And don't forget that through the magic of botnets, the bad > guys have vastly more compute power available than the good guys. Just out of curiosity, does anyone happen to know of any documented examples of a botnet being used for something more interesting than just sending spam or DDoS? -- Thomas Coppi --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From tls at rek.tjls.com Fri Jan 30 13:49:56 2009 From: tls at rek.tjls.com (Thor Lancelot Simon) Date: Fri, 30 Jan 2009 13:49:56 -0500 Subject: full-disk subversion standards released In-Reply-To: <200901292122.n0TLMbwU026364@new.toad.com> References: <200901292122.n0TLMbwU026364@new.toad.com> Message-ID: <20090130184956.GA6369@panix.com> On Thu, Jan 29, 2009 at 01:22:37PM -0800, John Gilmore wrote: > > If it comes from the "Trusted Computing Group", you can pretty much > assume that it will make your computer *less* trustworthy. Their idea > of a trusted computer is one that random unrelated third parties can > trust to subvert the will of the computer's owner. People have funny notions of "ownership", don't they? It's very clear to me that I don't own my desktop machine at my office; my employer does. But even if TCG were to punch out a useful, reasonable standard (which I do not think they have done in any case so far), the policy problem of how to ensure that my desktop machine's actual owner could enforce its ownership of that machine against me, while the retailer who sold me my desktop machine at home -- which I do own -- or for that matter the U.S. Government, can't enforce _its_ "ownership" of my own machine against me; that's a real problem, and solutions to it are useful. Given such solutions, frameworks like what TCG is chartered to build are in fact good and useful. I don't think it's right to blame the tool (or the implementation details of a particular instance of a particular kind of tool) for the idiot carpenter. Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jthorn at astro.indiana.edu Fri Jan 30 16:41:56 2009 From: jthorn at astro.indiana.edu (Jonathan Thornburg) Date: Fri, 30 Jan 2009 16:41:56 -0500 (EST) Subject: full-disk subversion standards released In-Reply-To: <200901292122.n0TLMbwU026364@new.toad.com> References: <200901292122.n0TLMbwU026364@new.toad.com> Message-ID: On Thu, 29 Jan 2009, John Gilmore wrote: > If it comes from the "Trusted Computing Group", you can pretty much > assume that it will make your computer *less* trustworthy. Their idea > of a trusted computer is one that random unrelated third parties can > trust to subvert the will of the computer's owner. Indeed, the classic question is "I've just bought this new computer which claims to have full-disk encryption. Is there any practical way I can assure myself that there are (likely) no backdoors in/around the encryption?" For open-source software encryption (be it swap-space, file-system, and/or full-disk), the answer is "yes": I can assess the developers' reputations, I can read the source code, and/or I can take note of what other people say who've read the source code. Alas, I can think of no practical way to get a "yes" answer to my question if the encryption is done in hardware, disk-drive firmware, or indeed anywhere except "software that I fully control". -- -- Jonathan Thornburg Dept of Astronomy, Indiana University, Bloomington, Indiana, USA "Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral." -- quote by Freire / poster by Oxfam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From bear at sonic.net Fri Jan 30 16:47:23 2009 From: bear at sonic.net (Ray Dillinger) Date: Fri, 30 Jan 2009 13:47:23 -0800 Subject: UCE - a simpler approach using just digital signing? In-Reply-To: <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> References: <200901252240.n0PMejwU002817@new.toad.com> <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> Message-ID: <1233352043.28107.143.camel@localhost> I have a disgustingly simple proposal. It seems to me that one of the primary reasons why UCE-limiting systems fail is the astonishing complexity of having a trust infrastructure maintained by trusted third parties or shared by more than one user. Indeed, "trusted third party" and "trust shared by multiple users" may be oxymorons here. Trust, by nature, is not really knowable by any third party, not the same for any set of more than one user, and in fact the people most willing to pay for it at least where UCE is concerned, experience shows to be usually the _least_ trustworthy parties. So why hasn't anybody tried direct implementation of user- managed digital signatures yet? A key list maintained by individual recipients for themselves alone could be astonishingly simpler in practice, probably to the point of actually being practical. In fact, it is _necessary_ to eliminate third parties and shared infrastructure almost entirely in order to allow mail recipients to have the kind of fine-grained control that they actually need to address the problem by creating social and business feedback loops that promote good security. As matters stand today, there is no protection from UCE. If I know there is a user account named 'fred' on the host 'example.com', then I have an email address and I can send all the UCE I want. And poor fred has the same email address he gives everybody, so he gets spam from people who've gotten his address and he has no idea where they got it. All his legitimate correspondents are using the same email address, so he can't abandon it without abandoning *all* of them, and he doesn't know which of them gave his address to the spammers. What if email accounts weren't that simple? Consider the implications of a third field, or "trust token," which works like a "password" to fred's mail box. Your mailer's copy of fred's email address would look like "fred#token at example.com" where "token" was a field that was your own personal password to fred's mailbox. Your system would still send mail to "fred at example.com" but it would include a "Trust:" header based on the token. The simplest solution I can think of would be a direct application of digital signatures; the trust token would be (used as) a cryptographic key, and the headers of any message would have to include a "Trust" field containing a digital signature (a keyed cryptographic hash of the message, generated by that key). Messages to multiple recipients would need to contain one "Trust" field per recipient. Its use would follow simple rules: Each time Fred gives out his email address to a new sender, he creates a trust token for that sender. They must use it when they send him mail. So fred gives his bank a key when he gives them his email address. If fred were willing to recieve mail from strangers, he could publish a trust token on his webpage or on usenet or whatever - it would be painless to revoke it later, so why not? If fred trusted someone to give out his email address, he could give that person multiple trust tokens to pass along to others. Again, an error in judgement would be painless to revoke later. Fred can revoke any trust token from his system at any time, and does so whenever he gets spam with a trust token he issued. In UI terms there'd be a button in his mail reader that works as, "this message is spam, so revoke this trust token because now a spammer has it." Other messages sent with the same trust token would disappear from his mailbox instantly. Fred might not push this button every time, but at least he'd know what spam he was getting due to (say) his published trust token on his webpage or usenet, and what spam he was getting due to his relationship with a bank, and he'd have the option of turning any source of spam off instantly. In the short run the .aliases file on the mail host would need a line so it would know to deliver mail to "fred#anything at example.com" to fred. This is not because a legitimate email would ever include the literal key, but for purposes of alerting fred's MUA to protocol breaches, so it could do key management. Fred's MUA could then be upgraded to use tokens without affecting other users on the system. In later MDA's that handle trust tokens directly, this forwarding would be automatic. Whenever Fred gets email sent by someone using a trust token, his system tells him which token - ie, what sender he gave that trust token to. So email sent to fred using the trust token he gave his bank will show up in his mailbox under a heading that says "this was sent by someone using the trust token you gave your bank." Whenever fred gets email for "fred#token at example.com" and that's still a legitimate token, his system revokes the token, sends him an automatic note that says which trust token was revoked, and bounces the email with a message that says, "Your mailer is not using trust tokens. Your mail has not been delivered and the trust token you used has been automatically revoked because your mailer sent it in cleartext instead of using it correctly. Please update your mailer and contact fred via some other channel to obtain a new trust token." Whenever fred gets email for "fred#token at example.com" and it's not a legitimate token anymore, it bounces with the same message, but doesn't generate another note to fred. Fred can see the status of all his tokens (live or revoked) when he looks at his address book. Whenever Fred gets email with no trust token, his system bounces it with a message that says "Contact fred using some other means to get a trust token for email." Whenever Fred gets email with a revoked trust token, his system bounces it with a message that says, "Sorry, this token is known to have been compromised; if you're a legitimate sender then either you've sent mail using a mailer that doesn't handle trust tokens correctly or somehow a spammer has read your email database. If you are a legitimate sender and you've updated your mailer, repaired your data security, or stopped selling your mailing list to spammers, whichever is applicable to your situation, then please contact fred using some other means to get a new trust token." If fred gets UCE under his bank's trust token, then he can revoke that token, and have a few words with the bank about their information security and how some spammer was able to get his hands on that trust token. This would promote early detection of breaches of information security and suborned machines, and also rapid detection of institutions that sell email information to spammers in violation of the users' trust. The bank would have a motive it now lacks to keep spammers out of its email database; every address/token combination used to send spam would instantly stop working, requiring them to resort to (relatively) expensive paper mail or use the phone in order to contact their legit customer. And if it happens again, and again, and again, then fred is likely to do his banking elsewhere in the future. To me, this feedback is the invaluable missing link that all the third-party trust and shared-trust schemes I've seen lack. When fred maintains his own trust keyring, both fred and the bank know where the spammer got the trust token. Also, both of them know the other will know where the spammer got the trust token. A spammer getting the trust token fred gave the bank will cost the bank money, customer goodwill, and potentially business. And fred and the bank must have contact with each other about it if there is still a mutual wish to reestablish email communication. Machines suborned by spammers would be detected instantly because all the trust tokens would be revoked within minutes of the spammer using them. Spammers could not share trust tokens around to get thousands of spam delivered on each one, because fred would revoke the token the first time he got spam on it and all the other spam would disappear. This would destroy spammers' motive to cooperate by selling each other spamlists. And when fred did revoke a key, none of his legitimate email still arriving under non-compromised tokens would be affected. Literally *EVERY* piece of spam would be evidence of an information security breach traceable to a single entity that fred gave his address to, and every time spam were recieved there would be a single action that fred could take to stop getting spam derived from that particular information security breach. This is basic digital signatures; it would work. We know how to do it. We've known how to do it for a long time. People would need to add one field to their email information to keep trust tokens. Everything else you could implement in the Mail User Agents. My inner cynic says nobody's implemented it because nobody can figure a way to make money by selling trust when users manage their own keyrings rather than paying a third party to manage keyrings for them. Can anybody else think of a better reason, or are we really just lazy greedy bums who can't be bothered to work on something unless we can "make money fast" doing it? Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Fri Jan 30 18:01:29 2009 From: leichter at lrw.com (Jerry Leichter) Date: Fri, 30 Jan 2009 18:01:29 -0500 Subject: UCE - a simpler approach using just digital signing? In-Reply-To: <1233352043.28107.143.camel@localhost> References: <200901252240.n0PMejwU002817@new.toad.com> <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> <1233352043.28107.143.camel@localhost> Message-ID: <3DB7CDB1-4910-46C5-B94E-698FCA93EC67@lrw.com> On Jan 30, 2009, at 4:47 PM, Ray Dillinger wrote: > I have a disgustingly simple proposal. [Basically, always include a > cryptographic token when you send mail; always require it when you > receive mail.] There is little effective difference between this an whitelists. If I only accept mail from people on my whitelist, spammers can only send me mail through three modes of failure: 1. They randomly pick a return address that happens to match someone on my whitelist. I think we can agree that this is rare enough that it isn't worth worrying about. 2. A spammer somehow finds pairs of people S and R, where S sends to R, and fakes S as the sender for spam directed to R. This would be a new mode of attack - spammers today just spurt out millions of messages based on very little information. Sure, someone *could* start this kind of attack - but it's difficult to get the necessary information to mount it, and it seems unlikely that it would make economic sense to spammers, who can live with tiny response rates because they can so cheaply generate targets. 3. This is a variant of (2) that actually does occur today: The spammer takes over S's machine and sends to the same people S sends to. Viruses try to spread by this mechanism; they often succeed. In principle, a spammer could write a virus that simply sent the (S,R) information from the infected machine, though I don't know that they've ever bothered. Either a type 3 attack, or a type 2 attack where the information comes from invading S's, machine, can of course just as easily grab all the tokens on S's machine. The solution proposed is that this will be noticed quickly, and the tokens will be marked as no longer valid. But that's really no different from R simply removing S from his whitelist. Really, cryptography is a non-issue here. As long as S and R share some information - even S's address will do - that R can use to filter messages; and there is no cheap way to get large amounts of (S,R)-pair information; that information can be the key to a whitelist. (Some mailing lists do this: E.g., if you want to post to RISKS, you're asked to include the string "notsp" at the beginning or end of the subject line. This is public information, so a spammer could easily do this *if he chose to specifically target the RISKS mailing list*; but there's no way he can do this automatically on a mass scale. An individual could easily reach a similar agreement with anyone sending him mail. Of course, the downside is that you can now *only* receive mail from those on your (logical) whitelist. That's fine in some cases, unacceptable in others. You can semi- automatically grow your whitelist by sending using some kind of challenge/response. For example, if you could send back the message with a note saying: "You're not on my whitelist, if you want to reach me resend this message with 'xyzzy' in the subject line." Spammers don't bother to look for such messages right now (though if you made this automatic enough, and enough people adopted it, they would have a reason to!) so they won't be able to sneak on your whitelist that way. However, many people writing to you won't want to be bothered - and automated mailings that you *do* want to receive and don't know the details of ahead of time (e.g., approval messages for mailing list requests you make) won't get through either. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Fri Jan 30 18:03:26 2009 From: johnl at iecc.com (John Levine) Date: 30 Jan 2009 23:03:26 -0000 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> Message-ID: <20090130230326.7013.qmail@simone.iecc.com> >Richard Clayton and I claim that PoW doesn't work: >http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf I bumped into Cynthia Dwork, who originallyinvented PoW, at a CEAS meeting a couple of years ago, and she said she doesn't think it works, either. R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Fri Jan 30 18:16:36 2009 From: johnl at iecc.com (John Levine) Date: 30 Jan 2009 23:16:36 -0000 Subject: UCE - a simpler approach using just digital signing? In-Reply-To: <1233352043.28107.143.camel@localhost> Message-ID: <20090130231636.10237.qmail@simone.iecc.com> Hi. One of the hats I wear is the chair of the Anti-Spam Research Group of the Internet Research Task Force, which is down the virtual hall from the IETF. You know how you all feel when someone shows up with his super duper new unbreakable crypto scheme? Well, that's kind of how I feel here. Dealing with spam is surprisingly subtle, a lot of smart people have been thinking about it for a long time, and most new ideas turn out to be old ideas with well known flaws or limitations. > Consider the implications of a third field, or "trust token," which > works like a "password" to fred's mail box. Your mailer's copy of > fred's email address would look like "fred#token at example.com" where > "token" was a field that was your own personal password to fred's > mailbox. It's not a bad idea. Its best known implementation was done in 1996 by Robert Hall of AT&T Labs who called it Zoemail. You can learn all about it in US Patent 5,930,479. This is the wrong place to go into detail about its limitations, although it should be self-evident that if it were effective, sometime in the past 13 years we'd have started using it. You're all welcome in the ASRG, which has a wiki at http://wiki.asrg.sp.am with pointers to the mailing list and other resources. One of our slow moving projects is a taxonomy of anti-spam techniques, both ones that work and ones that don't work. If you'd like to contribute, drop me a note and I'll give you a password so you can edit it. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From taralx at gmail.com Fri Jan 30 18:35:33 2009 From: taralx at gmail.com (Taral) Date: Fri, 30 Jan 2009 15:35:33 -0800 Subject: UCE - a simpler approach using just digital signing? In-Reply-To: <1233352043.28107.143.camel@localhost> References: <200901252240.n0PMejwU002817@new.toad.com> <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> <1233352043.28107.143.camel@localhost> Message-ID: On Fri, Jan 30, 2009 at 1:47 PM, Ray Dillinger wrote: > This is basic digital signatures; it would work. What's your transition plan? How do you deal with stolen "trust tokens"? (Think trojans/worms.) Also see: http://craphound.com/spamsolutions.txt -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From taralx at gmail.com Fri Jan 30 18:37:22 2009 From: taralx at gmail.com (Taral) Date: Fri, 30 Jan 2009 15:37:22 -0800 Subject: full-disk subversion standards released In-Reply-To: References: <200901292122.n0TLMbwU026364@new.toad.com> Message-ID: On Fri, Jan 30, 2009 at 1:41 PM, Jonathan Thornburg wrote: > For open-source software encryption (be it swap-space, file-system, > and/or full-disk), the answer is "yes": I can assess the developers' > reputations, I can read the source code, and/or I can take note of > what other people say who've read the source code. Really? What about hardware backdoors? I'm thinking something like the old /bin/login backdoor that had compiler support, but in hardware. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From gnu at toad.com Fri Jan 30 19:08:07 2009 From: gnu at toad.com (John Gilmore) Date: Fri, 30 Jan 2009 16:08:07 -0800 Subject: full-disk subversion standards released In-Reply-To: <20090130184956.GA6369@panix.com> References: <200901292122.n0TLMbwU026364@new.toad.com> <20090130184956.GA6369@panix.com> Message-ID: <200901310008.n0V087wU028256@new.toad.com> > Given such solutions, frameworks like what TCG is chartered to build are > in fact good and useful. I don't think it's right to blame the tool (or > the implementation details of a particular instance of a particular kind > of tool) for the idiot carpenter. Given the charter of TCG, to produce DRM standards, it's pretty clear what activity their tool is designed to be used for. The theory that we should build "good and useful" tools capable of monopoly and totalitarianism, but use social mechanisms to prevent them from being used for that purpose, strikes me as naive. Had you not noticed obvious indications like the corruption of the Executive Branch by NSA, RIAA and MPAA (including the shiny new president), the concurrence of the Legislative Branch in that corruption, and the toothlessness of the States and the Judicial Branch in failing to actually reign in major federal constitutional violations? Yes, I'm analogizing DRM to wiretaps and jiggered voting machines. But isn't DRM like a wiretap deep inside your computer -- a foreign agent that spies on you and reports back whatever it chooses, against your will? Worse, it's like a man-in-the-middle attack, buried inside your computer. If Hollywood succeeded in injecting DRM into all our infrastructure, who among us would seriously believe the government would not muscle its way in and start also using the DRM capabilities against the citizens? The Four Horsemen of the Infopocalypse are alive and well. Are you one of those guys in *favor* of sex offenders being allowed free access to children on the Internet, buddy? It's so simple, everyone will just prove they aren't a sex offender before being granted access. It's just like getting on a plane. (TCG has excised all mention of DRM from recent publications -- but I have the original ones, which had DRM examples explaining the motivation for why they were doing this work. I'll append one such example, for those who can't readily search the archives back to 2003. Skip down to "TCPA" in the body below.) John Message-Id: <200312162153.hBGLrOds029690 at new.toad.com> To: Jerrold Leichter cc: cryptography at metzdowd.com, gnu Subject: Re: Difference between TCPA-Hardware and other forms of trust In-reply-to: Date: Tue, 16 Dec 2003 13:53:24 -0800 From: John Gilmore > | means that some entity is supposed to "trust" the kernel (what else?). If > | two entities, who do not completely trust each other, are supposed to both > | "trust" such a kernel, something very very fishy is going on. > > Why? If I'm going to use a time-shared machine, I have to trust that the > OS will keep me protected from other users of the machine. All the other > users have the same demands. The owner of the machine has similar demands. I used to run a commercial time-sharing mainframe in the 1970's. Jerrold's wrong. The owner of the machine has desires (what he calls "demands") different than those of the users. The users, for example, want to be charged fairly; the owner may not. We charged every user for their CPU time, but only for the fraction that they actually used. In a given second, we might charge eight users for different parts of that fraction. Suppose we charged those eight users amounts that added up to 1.3 seconds? How would they know? We'd increase our prices by 30%, in effect, by charging for 1.3 seconds of CPU for every one second that was really expended. Each user would just assume that they'd gotten a larger fraction of the CPU than they expected. If we were tricky enough, we'd do this in a way that never charged a single user for more than one second per second. Two users would then have to collude to notice that they together had been charged for more than a second per second. (Our CPU pricing was actually hard to manage as we shifted the load among different mainframes that ran different applications at different multiples of the speed of the previous mainframe. E.g. our Amdahl 470/V6 price for a CPU second might be 1.78x the price on an IBM 370/158. A user's bill might go up or down from running the same calculation on the same data, based on whether their instruction sequences ran more efficiently or less efficiently than average on the new CPU. And of course if our changed "average" price was slightly different than the actual CPU performance, this provided a way to cheat on our prices. Our CPU accounting also changed when we improved the OS's timer management, so it could record finer fractions of seconds. On average, this made the system fairer. But your application might suffer, if its pattern of context switches had been undercharged by the old algorithm.) The users had to trust us to keep our accounting and pricing fair. System security mechanisms that kept one user's files from access by another could not do this. It required actual trust, since the users didn't have access to the data required to check up on us (our entire billing logs, and our accounting software). TCPA is being built specifically at the behest of Hollywood. It is built around protecting "content" from "subscribers" for the benefit of a "service provider". I know this because I read, and kept, all the early public design documents, such as the white paper http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf (This is no longer available from the web site, but I have a copy.) It says, on page 7-8: The following usage scenarios briefly illustrate the benefits of TCPA compliance. Scenario I: Remote Attestation TCPA remote attestation allows an application (the "challenger") to trust a remote platform. This trust is built by obtaining integrity metrics for the remote platform, securely storing these metrics and then ensuring that the reporting of the metrics is secure. For example, before making content available to a subscriber, it is likely that a service provider will need to know that the remote platform is trustworthy. The service provider's platform (the "challenger") queries the remote platform. During system boot, the challenged platform creates a cryptographic hash of the system BIOS, using an algorithm to create a statistically unique identifier for the platform. The integrity metrics are then stored. When it receives the query from the challenger, the remote platform responds by digitally signing and then sending the integrity metrics. The digital signature prevents tampering and allows the challenger to verify the signature. If the signature is verified, the challenger can then determine whether the identity metrics are trustworthy. If so, the challenger, in this case the service provider, can then deliver the content. It is important to note that the TCPA process does not make judgments regarding the integrity metrics. It merely reports the metrics and lets the challenger make the final decision regarding the trustworthiness of the remote platform. They eventually censored out all the sample application scenarios like DRM'd online music, and ramped up the level of jargon significantly, so that nobody reading it can tell what it's for any more. Now all the documents available at that site go on for pages and pages saying things like "FIA_UAU.1 Timing of authentication. Hierarchical to: No other components. FIA_UAU.1.1 The TSF shall allow access to data and keys where entity owner has given the 'world' access based on the value of TCPA_AUTH_DATA_USAGE; access to the following commands: TPM_SelfTestFull, TPM_ContinueSelfTest, TPM_GetTestResult, TPM_PcrRead, TPM_DirRead, and TPM_EvictKey on behalf of the user to be performed before the user is authenticated." But the historical record is clear that DRM was "Usage Scenario #1" for TCPA. Now, back to Hollywood. If you have not read "This Business of Music" (a thick book on how musicians can arm themselves with knowledge to get slightly less screwed by the record industry -- including sample contracts and explanations of the impact and history of each provision), you won't know the long history of why Hollywood can be trusted only to cheat everyone they deal with. A music-industry contract equivalent to charging for 30% more seconds than you deliver, is the provision for "breakage". No artist gets paid for more than 90% of the albums that the record company sells, because in the days of shellac records, about 10% of them would break in shipping. That problem largely went away with vinyl records, and went even further away with CDs. Today's actual breakage is way under 1%. But record companies won't sign a contract that pays the artist for more than 90% of the albums shipped on CD. That 10% underpayment of musicians goes straight back to the record company's profits. Their DRM software will cheat users the same way -- or a different way -- or a hundred different ways. And TCPA will make it un-auditable by us. John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Nicolas.Williams at sun.com Fri Jan 30 19:26:30 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 30 Jan 2009 18:26:30 -0600 Subject: full-disk subversion standards released In-Reply-To: References: <200901292122.n0TLMbwU026364@new.toad.com> Message-ID: <20090131002630.GR1044@Sun.COM> On Fri, Jan 30, 2009 at 03:37:22PM -0800, Taral wrote: > On Fri, Jan 30, 2009 at 1:41 PM, Jonathan Thornburg > wrote: > > For open-source software encryption (be it swap-space, file-system, > > and/or full-disk), the answer is "yes": I can assess the developers' > > reputations, I can read the source code, and/or I can take note of > > what other people say who've read the source code. > > Really? What about hardware backdoors? I'm thinking something like the > old /bin/login backdoor that had compiler support, but in hardware. Plus: that's a lot of code to read! A single person can't hope to understand the tens of millions of lines of code that make up the software (and firmware, and hardware!) that they use every day on a single system. Note: that's not to say that open source doesn't have advantages over proprietary source. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From tls at rek.tjls.com Fri Jan 30 20:35:28 2009 From: tls at rek.tjls.com (Thor Lancelot Simon) Date: Fri, 30 Jan 2009 20:35:28 -0500 Subject: full-disk subversion standards released In-Reply-To: <200901310008.n0V087wU028256@new.toad.com> References: <200901292122.n0TLMbwU026364@new.toad.com> <20090130184956.GA6369@panix.com> <200901310008.n0V087wU028256@new.toad.com> Message-ID: <20090131013528.GA542@panix.com> On Fri, Jan 30, 2009 at 04:08:07PM -0800, John Gilmore wrote: > > The theory that we should build "good and useful" tools capable of > monopoly and totalitarianism, but use social mechanisms to prevent > them from being used for that purpose, strikes me as naive. Okay. In that case, please, explain to me why you are not opposed to the the manufacture and sale of digital computers. More gently: it seems to me that there is an "only" missing from your sentence above, or else it is almost by necessity a straw-man argument: it will, if consistently applied as you have stated it, hold against various tools I do not believe you actually oppose the manufacture or sale of, such as printing presses, guns, and door locks. Many of TCG's documents purport to specify mechanisms that are in fact generally useful for beneficial purposes, such as boot-time validation of software environments, secure storage of cryptographic keys, or low-bandwidth generation of good random numbers. Do you actually mean that such things should not be built, or only that you are suspicious of TCG's intent in building them? In text I've snipped, you claimed to describe TCG's charter. I must admit that I don't know if they even actually have such a document. But, on the other hand, they describe their own purpose like this (these are their actual words): "The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define, and promote open standards for hardware-enabled trusted computing and security technologies, including hardware building blocks and software interfaces, across multiple platforms, peripherals, and devices. TCG specifications will enable more secure computing environments without compromising functional integrity, privacy, or individual rights. The primary goal is to help users protect their information assets (data, passwords, keys, etc.) from compromise due to external software attack and physical theft." I happen to think that if those _stated_ goals were achieved, that would be a good thing, and that there are in fact hardware and software mechanisms that could help achieve them -- some of which TCG has made stabs at specifying, though they've generally missed the mark. Leaving aside your assertions about TCG's _actual_ goals -- which may be correct -- are you really of the position that what's described above, no matter who were to build it nor how well, would be only useful for "monopoly and totalitarianism"? Thor --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From bill.stewart at pobox.com Fri Jan 30 20:37:33 2009 From: bill.stewart at pobox.com (Bill Stewart) Date: Fri, 30 Jan 2009 17:37:33 -0800 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <5e04a4c60901301040m689b9f62y9dad80f162ad296c@mail.gmail.co m> References: <20090127193543.67F9314F6E1@finney.org> <20090128211904.73633.qmail@simone.iecc.com> <5e04a4c60901301040m689b9f62y9dad80f162ad296c@mail.gmail.com> Message-ID: <6.2.1.2.1.20090130173339.041a3840@pop.sonic.net> At 10:40 AM 1/30/2009, Thomas Coppi wrote: > Just out of curiosity, does anyone happen to know of any documented >examples of a botnet being used for something more interesting than >just sending spam or DDoS? There are good botnets and bad botnets. Good ones ask you if you want to join, bad ones don't. Good ones are typically things like SETI at home, Folding at home, Great Internet Mersenne Prime Search, DES crackers, etc., and if you've got something good to do, people will help. People usually only set up the bad ones if they want to do something bad - it may be interesting the first time they do it, like a new flavor of DDOS, but it's not usually doing the world any favors. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From nelson at crynwr.com Sat Jan 31 02:16:45 2009 From: nelson at crynwr.com (Russ Nelson) Date: Sat, 31 Jan 2009 02:16:45 -0500 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <20090126200832.17998.qmail@simone.iecc.com> References: <200901252240.n0PMejwU002817@new.toad.com> <20090126200832.17998.qmail@simone.iecc.com> Message-ID: <18819.64221.186554.80085@desk.crynwr.com> John Levine writes: > http://www.taugh.com/epostage.pdf I would also point out that nothing is preventing anyone from implementing their own epostage. Just send your email via a paypal Send Money, accompanied with whatever postage you feel is appropriate. No magic, no standards track epostage, no chicken-and-egg implementation problem, not even any crypto needed. Too boring to actually use, I guess. -- --my blog is at http://blog.russnelson.com | Delegislation is a slippery Cloudmade supports http://openstreetmap.org/ | slope to prosperity. 521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom. Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Sat Jan 31 05:19:14 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 31 Jan 2009 23:19:14 +1300 Subject: full-disk subversion standards released In-Reply-To: <200901310008.n0V087wU028256@new.toad.com> Message-ID: John Gilmore writes: >The theory that we should build "good and useful" tools capable of monopoly >and totalitarianism, but use social mechanisms to prevent them from being >used for that purpose, strikes me as naive. There's another problem with this theory and that's the practical implementation issue. I've read through... well, at least skimmed through the elephantine bulk of the TCG specs, and also read related papers and publications and talked to people who've worked with the technology, to see how I could use it as a crypto plugin for my software (which already supports some pretty diverse stuff, smart cards, HSMs, the VIA Padlock engine, ARM security cores, Fortezza cards (I even have my own USG-allocated Fortezza ID :-), and in general pretty much anything out there that does crypto in any way, shape, or form). However after detailed study of the TCG specs and discussions with users I found that the only thing you can really do with this, or at least the bits likely to be implemented and supported and not full of bugs and incompatibilities, is DRM. In all the time I've worked with crypto devices I've never seen something so totally unsuited to general-purpose crypto use as a TPM. There really is only one thing it can reliably be used for and that's DRM. Now admittedly if you look really hard you may find a particular vendor who has a hit-and-miss attempt at implementing some bits of the spec that, if you cross your eyes and squint, is almost usable for general-purpose crypto use, but that's it. Even with the best intentions in the world, the only thing you can really usefully do with a TPM is DRM. (NB: This was a few years ago, maybe things have improved since then but I haven't seen any real indication of this. Oh, and I'm not going to get into the rathole of whether the whole "attestation" thing is DRM or not, if you think it isn't then please replace all occurrences of "DRM" in the above text with "attestation"). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From sascha-ml-cryptography-metzdowd.com at silbe.org Sat Jan 31 06:35:48 2009 From: sascha-ml-cryptography-metzdowd.com at silbe.org (Sascha Silbe) Date: Sat, 31 Jan 2009 12:35:48 +0100 Subject: UCE - a simpler approach using just digital signing? In-Reply-To: <1233352043.28107.143.camel@localhost> References: <200901252240.n0PMejwU002817@new.toad.com> <1b587cab0901291832kd132e29uc7a58c4abbc5e7d@mail.gmail.com> <1233352043.28107.143.camel@localhost> Message-ID: <20090131113548.GA31730@twin.sascha.silbe.org> On Fri, Jan 30, 2009 at 01:47:23PM -0800, Ray Dillinger wrote: > Each time Fred gives out his email address to a new sender, he creates > a trust token for that sender. They must use it when they send him > mail. That's basically what I'm using, just without the digital signature part: each person/organisation/website/whatever gets a different email address for communicating with me (qmail makes this easy to implement); mailing list and bugtracker addresses are filtered to accept only mail with the correct headers. It works much better than content filters, but it's basically limited to 1:1 communication (with a mailing list looking like a single entity as it forwards traffic both ways). Most importantly, it breaks for CC parties (*). Address lists on paper given out to a large number of participants are problematic as well (those utilizing paper lists are mostly non-tech-savvy - thus prone to attacks - and changing the address is hard due to the long update interval of the list). To get on-topic again: Another scheme (that could be combined with the above one to solve only the CC party problem) would be accepting only PGP mail and use a manually updated whitelist / web of trust of PGP keys. Unfortunately, PGP still isn't widespread enough to reject non-PGP mails and the ones not using it are often far more susceptible to address harvesting malware, limiting the usefulness of such a filter. (*) CC party: group discussion without predetermined participants (so no mailing list could be set up in advance) CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: Digital signature URL: From smb at cs.columbia.edu Sat Jan 31 14:11:42 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Sat, 31 Jan 2009 14:11:42 -0500 Subject: Proof of Work -> atmospheric carbon In-Reply-To: <5e04a4c60901301040m689b9f62y9dad80f162ad296c@mail.gmail.com> References: <20090127193543.67F9314F6E1@finney.org> <20090128211904.73633.qmail@simone.iecc.com> <5e04a4c60901301040m689b9f62y9dad80f162ad296c@mail.gmail.com> Message-ID: <20090131141142.47483ce1@cs.columbia.edu> On Fri, 30 Jan 2009 11:40:12 -0700 Thomas Coppi wrote: > On Wed, Jan 28, 2009 at 2:19 PM, John Levine wrote: > > Indeed. And don't forget that through the magic of botnets, the bad > > guys have vastly more compute power available than the good guys. > > Just out of curiosity, does anyone happen to know of any documented > examples of a botnet being used for something more interesting than > just sending spam or DDoS? I asked Rob Thomas of Team Cymru this question (he and they study the underground). Here is his answer, posted with permission: ==== Botnets are routinely used as: 1. Proxies (IRC, HTTP & HTTPS) 2. To recover financial credentials, e.g. paypal, citibank, et al. This was the original purpose of the PSNIFF code in some of the early bots. Here's a code snippet from the now venerable rBot_rxbot_041504-dcom-priv-OPTIX_MASTERPASSWORD dating back several years: [ ... ] // Scaled down distributed network raw packet sniffer (ala Carnivore) // // When activated, watches for botnet login strings, and // reports them when found. // // The bots NIC must be configured for promiscuous mode (recieve // all). Chances are this already done, if not, you can enable it // by passing the SIO_RCVALL* DWORD option with a value of 1, to // disable promiscuous mode pass with value 0. // // This won't work on Win9x bots since SIO_RCVALL needs raw // socket support which only WinNT+ has. [ ... ] PSWORDS pswords[]={ {":.login",BOTP}, {":,login",BOTP}, {":!login",BOTP}, [ ... ] {"paypal",HTTPP}, {"PAYPAL",HTTPP}, {"paypal.com",HTTPP}, {"PAYPAL.COM",HTTPP}, {"Set-Cookie:",HTTPP}, {NULL,0} }; [ ... ] 3. Remember they're called "boats" now, so anything is possible. Screen captures are becoming increasingly popular. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From johnl at iecc.com Sat Jan 31 14:55:50 2009 From: johnl at iecc.com (John Levine) Date: 31 Jan 2009 19:55:50 -0000 Subject: UCE - a simpler approach using just digital signing? In-Reply-To: <20090131113548.GA31730@twin.sascha.silbe.org> Message-ID: <20090131195550.30363.qmail@simone.iecc.com> >That's basically what I'm using, just without the digital signature >part: each person/organisation/website/whatever gets a different email >address for communicating with me (qmail makes this easy to implement) I do that too -- I bet half the people on this list do, and there's lots of free and commercial services like Yahoo and Spamex who will let you do it. But it's not much of a solution to spam because it requires significant manual work to maintain the addresses, and only deals with places where you individually give them the address to send mail to. >Another scheme (that could be combined with the above one to solve only >the CC party problem) would be accepting only PGP mail and use a >manually updated white list This has the same fundamental problem as Zoemail and any other white list system. It's really easy to implement a white list. Unless your name is Paypal, the amount of mail forging your address is vanishingly small, and the utterly insecure From: line address works just fine for practical purposes. I use that to manage my 12 year old daughter's mail. But whitelists replace the spam problem with the equally intractable introduction problem, deciding whether to accept the first message from someone you don't know. People have been thinking about that for a long time (indeed, for millenia in contexts other than e-mail) and the snarky comments I made yesterday about wonderful anti-spam ideas apply here, too. The ASRG is still eager to hear from people who want to do just about anything related to spam other than hash over known-ineffective old ideas. See http://wiki.asrg.sp.am. R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From david_koontz at xtra.co.nz Sat Jan 31 21:33:54 2009 From: david_koontz at xtra.co.nz (David G. Koontz) Date: Sun, 01 Feb 2009 15:33:54 +1300 Subject: full-disk subversion standards released In-Reply-To: References: Message-ID: <49850A12.50904@xtra.co.nz> Peter Gutmann wrote: > John Gilmore writes: > >> The theory that we should build "good and useful" tools capable of monopoly >> and totalitarianism, but use social mechanisms to prevent them from being >> used for that purpose, strikes me as naive. > > There's another problem with this theory and that's the practical > implementation issue. I've read through... well, at least skimmed through the > elephantine bulk of the TCG specs, and also read related papers and > publications and talked to people who've worked with the technology, to see > how I could use it as a crypto plugin for my software (which already supports > some pretty diverse stuff, smart cards, HSMs, the VIA Padlock engine, ARM > security cores, Fortezza cards (I even have my own USG-allocated Fortezza ID > :-), and in general pretty much anything out there that does crypto in any > way, shape, or form). However after detailed study of the TCG specs and > discussions with users I found that the only thing you can really do with > this, or at least the bits likely to be implemented and supported and not full > of bugs and incompatibilities, is DRM. > You could note a certain overlap between the promoters of Digital Content Protection and the Trusted Computing Group: http://www.digital-cp.com/about_dcp Nearly 400 leading companies license the technology, including the following: Semiconductor: PC Companies: Consumer Electronics: AMD HP Panasonic Analog Devices Microsoft Samsung Intel Lenovo Sony Silicon Image Toshiba Full List of Licensees: Click here (Fuji Xerox Co., Ltd.) https://www.trustedcomputinggroup.org/about/members/ Current Members Promoter Contributor AMD ... Fujitsu Limited Panasonic Hewlett-Packard ... IBM Samsung Electronics Co. Infineon ... Intel Corporation Sony Corporation Lenovo Holdings Limited ... Microsoft Toshiba Corporation Seagate Technology Sun Microsystems, Inc. Wave Systems The costs and economy of scale say at some point all the disk drives will be capable of FDE, whether or not it is enabled (whether or not you pay for the 'extra' feature). The distinction is the added cost of testing the encryption versus the cost of two different testing regimes, when silicon is typically pin bound defining area and cost. The same integration cost advantages makes the like of HDMI close to zero cost to the television media consumer. Enterprise 'platform owners' have the capability of assuming control of the attestation chain, while 'personal computing' might have few opportunities other than to allow the likes of an operating system vendor to provide control 'in loco parentis' for the naive consumer. Loss of control of personal computing would come about by seduction - the offer of benefits in exchange for more of the camel edging under the tent skirt. More's the pity if it offers competitive advantage excluding open source. You'd think video content providers would be anxious for a way to provide secure delivery of content via download. Being able to stick video onto a disk protected by a plus thirteen Mage DMCA spell would be a definite benefit. I'd also imagine we'll see vulnerabilities that will allow content recovery. Getting 'secure' computing requires a secure operating system. Building a computer secure against end user tampering would incur high adoption costs that wouldn't be supportable in the marketplace. To borrow and mutilate a turn of phrase from Bruce, what we get is Kabuki security theater with the commiserate tendency toward prostitution. All that said and done, people may still well end up with better security - data encrypted at rest. I'd think fighting DRM would be a separate battle from opposing FDE. It may be worthwhile to show systemic vulnerabilities that despite the encryption endanger threaten 'content protection', because while DRM's proponents like to provide a stylized threat model the real world doesn't match up. The enterprise is able to leverage further behavioral limits on users actions during platform operation and the Trusted Computing threat model allows users within the cryptographic boundary (undoubtedly due to the cost of exclusion). Additional behavioral limits aren't available for the DRM usage model, and there is nothing stopping the malevolent end user from monitoring unencrypted data from a drive for example. Trusted Computing may never be suitable for DRM either. I'd expect an enterprise would field a careful selected configuration that they could manage to make work for their purposes. DRM has to work for any configuration. Portability for Trusted Computing may require virtualization. The TCG threat model may still prevent DRM from being anywhere near absolute in a virtualized environment. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com