From Darren.Moffat at Sun.COM Tue Sep 1 05:39:21 2009 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 01 Sep 2009 10:39:21 +0100 Subject: AES-GMAC as a hash In-Reply-To: <20090831171932.ED71814F6E1@finney.org> References: <20090831171932.ED71814F6E1@finney.org> Message-ID: <4A9CEBC9.2090001@Sun.COM> Hal Finney wrote: > Darren J Moffat asks: >> Ignoring performance for now what is the consensus on the suitabilty of >> using AES-GMAC not as MAC but as a hash ? >> >> Would it be safe ? >> >> The "key" input to AES-GMAC would be something well known to the data >> and/or software. > > No, I don't think this would work. In general, giving a MAC a fixed key > cannot be expected to produce a good hash. With AES-GMAC in particular, > it is unusual in that it has a third input (besides key and data to MAC), > an IV, which makes your well-known-key strategy problematic. And even as a > MAC, it is very important that a given key/IV pair never be reused. Fixing > a value for the key and perhaps IV would defeat this provision. > > But even ignoring all that, GMAC amounts to a linear combination of > the text blocks - they are the coefficients of a polynomial. The reason > you can get away with it in GMAC is because the polynomial variable is > secret, it is based on the key. So you don't know how things are being > combined. But with a known key and IV, there would be no security at all. > It would be linear like a CRC. Thanks, that is pretty much what I suspected would be the answer but you have more detail than I could muster in my head at a first pass on this. Thanks. -- Darren J Moffat --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From matt.ball at ieee.org Tue Sep 1 12:37:24 2009 From: matt.ball at ieee.org (Matt Ball) Date: Tue, 1 Sep 2009 10:37:24 -0600 Subject: AES-GMAC as a hash In-Reply-To: <4A969C23.5090007@Sun.COM> References: <5733F11F-D4FA-4258-A8A7-331BFD4DA116@zooko.com> <9FB8FE44-09EF-4A2E-9502-11E417C26564@lrw.com> <4A969C23.5090007@Sun.COM> Message-ID: On Thu, Aug 27, 2009 at 8:45 AM, Darren J Moffat wrote: > > Ignoring performance for now what is the consensus on the suitabilty of using AES-GMAC not as MAC but as a hash ? > > Would it be safe ? > > The "key" input to AES-GMAC would be something well known to the data and/or software. > > The only reason I'm asking is assuming it can be made to perform on some classes of machine better than or close to SHA256 if it would be worth considering as an available alternate now until SHA-3 is choosen. In the 2005 Security in Storage Workshop (see http://ieeeia.org/sisw/2005/), David McGrew proposed using GMAC to protect large dynamic data sets, such a random access memory (RAM) (see http://ieeeia.org/sisw/2005/PreProceedings/10.pdf). The general idea is to use the linear characteristics of GMAC to dynamically update the MAC when updating a memory address. If your use-case is similar to this approach, then it would be possible to securely use GMAC. However, there are many caveats when using GMAC, so it's vitally important to understand all the constraints. Cheers, Matt Ball, Chair, IEEE P1619 Security in Storage Working Group Staff Engineer, Sun Microsystems, Inc. 500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021 Work: 303-272-7580, Cell: 303-717-2717 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Tue Sep 1 22:55:31 2009 From: leichter at lrw.com (Jerry Leichter) Date: Tue, 1 Sep 2009 22:55:31 -0400 Subject: "Fed's RFIDiocy pwnd at DefCon" Message-ID: <8C436C24-A2FA-4BAC-B843-F572133A7ECD@lrw.com> http://blogs.zdnet.com/storage/?p=565 "NSA spooks gather for a colleague?s retirement party at a bar. What they don?t know is that an RFID scanner is picking them out - and a wireless Bluetoothwebcam is taking their picture. Could that really happen? It already did. (The Feds got a taste of the real world risks of RFID passports and IDs at DefCon, the annual hacker conference. According to Wired http://www.wired.com/threatlevel/2009/08/fed-rfid/) : . . . federal agents at the conference got a scare on Friday when they were told they might have been caught in the sights of an RFID reader. The reader, connected to a web camera, sniffed data from RFID-enabled ID cards and other documents carried by attendees in pockets and backpacks as they passed a table where the equipment was stationed in full view...." -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pyelgar at yahoo.co.in Wed Sep 2 01:28:03 2009 From: pyelgar at yahoo.co.in (priya yelgar) Date: Wed, 2 Sep 2009 10:58:03 +0530 (IST) Subject: RNG using AES CTR as encryption algorithm Message-ID: <890362.773.qm@web95316.mail.in2.yahoo.com> Hi all, I have implemented RNG using AES algorithm in CTR mode. To test my implementation I needed some test vectors. How ever I searched on the CSRC site, but found the test vectors for AES_CBC not for AES CTR. Please? can any one tell me where to look for the test vectors to test RNG using? AES CTR. Thanks in advance Priya Ainapur Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Wed Sep 2 15:13:59 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 2 Sep 2009 15:13:59 -0400 Subject: Client Certificate UI for Chrome? In-Reply-To: <1b587cab0908260326v40cca144yfb8bb378b59fae71@mail.gmail.com> References: <4A7B869F.10801@echeque.com> <1b587cab0908260326v40cca144yfb8bb378b59fae71@mail.gmail.com> Message-ID: <6B01AD9C-D0A3-4F9F-8C82-CE1A6FBB3AC3@cs.columbia.edu> On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote: > On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann > wrote: >> More generally, I can't see that implementing client-side certs >> gives you much >> of anything in return for the massive amount of effort required >> because the >> problem is a lack of server auth, not of client auth. If I'm a >> phisher then I >> set up my bogus web site, get the user's certificate-based client >> auth >> message, throw it away, and report successful auth to the client. >> The browser >> then displays some sort of indicator that the high-security >> certificate auth >> was successful, and the user can feel more confident than usual in >> entering >> their credit card details. All you're doing is building even more >> substrate >> for phishing attacks. >> >> Without simultaneous mutual auth, which -SRP/-PSK provide but PKI >> doesn't, >> you're not getting any improvement, and potentially just making >> things worse >> by giving users a false sense of security. > > I certainly agree that if the problem you are trying to solve is > server authentication, then client certs don't get you very far. I > find it hard to feel very surprised by this conclusion. > > If the problem you are trying to solve is client authentication then > client certs have some obvious value. > > That said, I do tend to agree that mutual auth is also a good avenue > to pursue, and the UI you describe fits right in with Chrome's UI in > other areas. Perhaps I'll give it a try. This returns us to the previously-unsolved UI problem: how -- with today's users, and with something more or less like today's browsers since that's what today's users know -- can a spoof-proof password prompt be presented? --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From zooko at zooko.com Wed Sep 2 15:50:21 2009 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Wed, 2 Sep 2009 13:50:21 -0600 Subject: so how do *you* manage your keys, then? part 3 References: <31588621-B335-4508-838B-B0FCC3D59428@zooko.com> Message-ID: So How Do You Manage Your Keys Then, part 3 of 5 In part one of this series [1] I described how Tahoe-LAFS combines decryption, integrity-checking, identification, and access into one bitstring, called an "immutable file read-cap" (short for "capability"). In part two [2] I described how users can build tree- like structures of files which contain caps pointing to other files, and how the cap pointing to the root of such a structure can reside on a different computer than the ciphertext. (Which is necessary if you want someone to store the ciphertext for you but you don't want to give them the ability to read the file contents.) In this installment, consider the question of whether you can give someone a cap (which acts as a file handle) and then change the contents of the file that the cap points to, while preserving their ability to read with the original cap. This would be impossible with the immutable file read-caps that we have been using so far, because each immutable file read cap uses a secure hash function to identify and integrity-check exactly one file's contents -- one unique byte pattern. Any change to the file contents will cause the immutable file read-cap to no longer match. This can be a desirable property if what you want is a permanent identifier of one specific, immutable file. With this property nobody -- not even the person who wrote the file in the first place -- is able to cause anyone else's read-caps to point to any file contents other than the original file contents. But sometimes you want a different property, namely that an authorized writer *can* change the file contents and readers will be able to read the new file contents without first having to acquire a new file handle. To accomplish this requires the use of public key cryptography, specifically digital signatures. Using digital signatures, Tahoe- LAFS implements a second kind of capability, in addition to the immutable-file capability, which is called a "mutable file capability". Whenever you create a new mutable file, you get *two* caps to it: a write-cap and a read-cap. (Actually you can always derive the read-cap from the write-cap, so for API simplicity you get just the write-cap to your newly created mutable file.) Possession of the read-cap to the mutable file gives you two things: it gives you the symmetric encryption key with which you decrypt the file contents, and it gives you the public key with which you check a digital signature in order to be sure that the file contents were written by an authorized writer. The decryption and signature verification both happen automatically whenever you read data from that file handle (it downloads the digital signature which is stored with the ciphertext). Possession of the write-cap gives two things: the symmetric key with which you can encrypt the ciphertext, and the private key with which you can sign the contents. Both are done automatically whenever you write data to that file handle. The important thing about this scheme is that what we crypto geeks call "key management" is almost completely invisible to the users. As far as the users can tell, there aren't any "keys" here! The only objects in sight are the file handles, which they already use all the time. All users need to know is that a write-cap grants write authority (only to that one file), and the read-cap grants read authority. They can conveniently delegate some of their read- or write- authority to another user, simply by giving that user a copy of that cap, without delegating their other authorities. They can bundle multiple caps (of any kind) together into a file and then use the capability to that file as a handle to that bundle of authorities. At least, this is the theory that the object-capability community taught me, and I'm pleased to see that -- so far -- it has worked out in practice. Programmers and end users appear to have no difficulty understanding the access control consequences of this scheme and then using the scheme appropriately to achieve their desired ends. Installment 4 of this series will be about Tahoe-LAFS directories (those are the most convenient way to bundle together multiple caps -- put them all into a directory and then use the cap which points to that directory). Installment 5 will be about future work and new crypto ideas. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-August/002637.html # installment 1: immutable file caps [2] http://allmydata.org/pipermail/tahoe-dev/2009-August/002656.html # installment 2: tree-like structure (like encrypted git) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jamesd at echeque.com Wed Sep 2 20:07:00 2009 From: jamesd at echeque.com (James A. Donald) Date: Thu, 03 Sep 2009 10:07:00 +1000 Subject: Client Certificate UI for Chrome? In-Reply-To: <6B01AD9C-D0A3-4F9F-8C82-CE1A6FBB3AC3@cs.columbia.edu> References: <4A7B869F.10801@echeque.com> <1b587cab0908260326v40cca144yfb8bb378b59fae71@mail.gmail.com> <6B01AD9C-D0A3-4F9F-8C82-CE1A6FBB3AC3@cs.columbia.edu> Message-ID: <4A9F08A4.3010103@echeque.com> Steven Bellovin wrote: > This returns us to the previously-unsolved UI problem: how -- with > today's users, and with something more or less like today's browsers > since that's what today's users know -- can a spoof-proof password > prompt be presented? When the user clicks on a button generated by a particular special kind of html tag, perhaps Message-ID: Steven Bellovin writes: >This returns us to the previously-unsolved UI problem: how -- with today's >users, and with something more or less like today's browsers since that's >what today's users know -- can a spoof-proof password prompt be presented? Good enough to satisfy security geeks, no, because no measure you take will ever be good enough. However if you want something that's good enough for most purposes then Camino has been doing something pretty close to this since it was first released (I'm not aware of any other browser that's even tried). When you're asked for credentials, the dialog rolls down out of the browser title bar in a hard-to-describe scrolling motion a bit like a supermarket till printout. In other words instead of a random popup appearing in front of you from who knows what source and asking for a password, you've got a direct visual link to the thing that the credentials are being requested for. You can obviously pepper and salt this as required (and I wouldn't dream of deploying something like this without getting UI folks to comment and test it on real users first), but doing this is a tractable UI design issue and not an intractable business-model/political/social/etc problem. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From rah at shipwright.com Fri Sep 4 14:32:36 2009 From: rah at shipwright.com (R.A. Hettinga) Date: Fri, 4 Sep 2009 14:32:36 -0400 Subject: [fc-announce] Financial Crypto and Data Security 2010: speakers and workshops [submission deadline: September 15, 2009] References: Message-ID: Begin forwarded message: From: Radu Sion Date: September 4, 2009 12:14:45 PM GMT-04:00 To: fc-announce at ifca.ai Subject: [fc-announce] Financial Crypto and Data Security 2010: speakers and workshops [submission deadline: September 15, 2009] Financial Cryptography and Data Security Tenerife, Canary Islands, Spain 25-28 January 2010 http://fc10.ifca.ai Financial Cryptography and Data Security is a major international forum for research, advanced development, education, exploration, and debate regarding information assurance, with a specific focus on commercial contexts. The conference covers all aspects of securing transactions and systems. Original works focusing on both fundamental and applied real-world deployments on all aspects surrounding commerce security are solicited. SUBMISSIONS NEED NOT BE EXCLUSIVELY CONCERNED WITH CRYPTOGRAPHY. Systems security and inter-disciplinary efforts are particularly encouraged. Topics include: Anonymity and Privacy, Auctions and Audits, Authentication and Identification, Backup Authentication, Biometrics, Certification and Authorization, Cloud Computing Security, Commercial Cryptographic Applications, Transactions and Contracts, Data Outsourcing Security, Digital Cash and Payment Systems, Digital Incentive and Loyalty Systems, Digital Rights Management, Fraud Detection, Game Theoretic Approaches to Security, Identity Theft, Spam, Phishing and Social Engineering, Infrastructure Design, Legal and Regulatory Issues, Management and Operations, Microfinance and Micropayments, Mobile Internet Device Security, Monitoring, Reputation Systems, RFID-Based and Contactless Payment Systems, Risk Assessment and Management, Secure Banking and Financial Web Services, Securing Emerging Computational Paradigms, Security and Risk Perceptions and Judgments, Security Economics, Smartcards, Secure Tokens and Hardware, Trust Management, Underground-Market Economics, Usability, Virtual Economies, Voting Systems INVITED SPEAKERS Lorrie Cranor, CMU http://lorrie.cranor.org/ Ueli Maurer, ETH Zurich http://www.crypto.ethz.ch/~maurer/ WORKSHOPS Workshop on Real-Life Cryptographic Protocols and Standardization (RLCPS.10) https://www.nec.co.jp/rd/en/event/RLCPS10.html Workshop on Ethics in Computer Security Research (WECSR 2010) http://www.cs.stevens.edu/~spock/wecsr2010/ Workshop on Lightweight Cryptography for Resource-Constrained Devices (WLC'2010) http://www.wlc2010.udl.cat/ IMPORTANT DATES Paper Submission: September 15, 2009, 11:59pm Pacific Time Paper Notification: October 25, 2009 Final Papers: November 29, 2009 Poster and Panel Submission: November 10, 2009 Poster and Panel Notification: November 20, 2009 SUBMISSION Submission categories: (i) regular papers (15 pg LNCS), (ii) short papers (6 pg), (iii) panels and workshops (2 pg), and (iv) posters (1-2 pg). Anonymized submissions will be double-blind reviewed. More details can be found online at http://fc10.ifca.ai. ORGANIZERS General Chair: Pino Caballero-Gil, University of La Laguna Local Chair: Candelaria Hernandez-Goya, University of La Laguna Local Committee Luisa Arranz Chacon, Alcatel Espana, S.A. Candido Caballero Gil, University of La Laguna Amparo Fter Sabater, IFA-CSIC Felix Herrera Priano, University of La Laguna Belen Melian Batista, University of La Laguna Jezabel Molina Gil, University of La Laguna Jose Moreno Perez, University of La Laguna Marcos Moreno Vega, University of La Laguna Alberto Peinado Dominguez, University of Malaga Alexis Quesada Arencibia, University of Las Palmas de Gran Canaria Jorge Ramio Aguirre, Polytechnic University of Madrid Victoria Reyes Sanchez, University of La Laguna PROGRAM COMMITTEE Program Chair: Radu Sion, Stony Brook University Ross Anderson, University of Cambridge Lucas Ballard, Google Inc. Adam Barth, UC Berkeley Luc Bouganim, INRIA Rocquencourt Bogdan Carbunar, Motorola Labs Ivan Damgard, Aarhus University Ernesto Damiani, University of Milano George Danezis, Microsoft Research Sabrina de Capitani di Vimercati, University of Milano Rachna Dhamija, Harvard University Sven Dietrich, Stevens Institute of Technology Roger Dingledine, The Tor Project Josep Domingo-Ferrer, University of Rovira i Virgili Stefan Dziembowski, University of Rome "La Sapienza" Bernhard Esslinger, Siegen University Simone Fischer-Hner, Karlstad University Amparo Fuster-Sabater, Instituto de Fica Aplicada Madrid Philippe Golle, Palo Alto Research Center Dieter Gollmann, Technische Universitaet Hamburg-Harburg Rachel Greenstadt, Drexel University Markus Jakobsson, Palo Alto Research Center and Indiana University Rob Johnson, Stony Brook University Ton Kalker, HP Labs Stefan Katzenbeisser, Technische Universit Darmstadt Angelos Keromytis, Columbia University Lars R. Knudsen, Technical University of Denmark Wenke Lee, Georgia Tech Arjen Lenstra, Ecole Polytechnique Federale de Lausanne (EPFL) and Alcatel-Lucent Bell Laboratories Helger Lipmaa, Cybernetica AS Javier Lopez, University of Malaga Luigi Vincenzo Mancini, University of Rome "La Sapienza" Refik Molva, Eurecom Sophia Antipolis Fabian Monrose, University of North Carolina at Chapel Hill Steven Murdoch, University of Cambridge David Naccache, Ecole Normale Superieure (ENS) David Pointcheval, Ecole Normale Superieure (ENS) and CNRS Bart Preneel, Katholieke Universiteit Leuven Josep Rifa Coma, Autonomous University of Barcelona Ahmad-Reza Sadeghi, Ruhr-University Bochum Angela Sasse, University College London Vitaly Shmatikov, University of Texas at Austin Miguel Soriano, Polytechnic University of Catalonia Miroslava Sotakova, Aarhus University Angelos Stavrou, George Mason University Patrick Traynor, Georgia Tech Nicholas Weaver, International Computer Science Institute Berkeley Proceedings Chair: Reza Curtmola, New Jersey Institute of Technology Poster Chair: Peter Williams, Stony Brook University _______________________________________________ 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 Nicolas.Williams at sun.com Fri Sep 4 15:58:10 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 4 Sep 2009 14:58:10 -0500 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: <890362.773.qm@web95316.mail.in2.yahoo.com> References: <890362.773.qm@web95316.mail.in2.yahoo.com> Message-ID: <20090904195810.GP1033@Sun.COM> On Wed, Sep 02, 2009 at 10:58:03AM +0530, priya yelgar wrote: > How ever I searched on the CSRC site, but found the test vectors for > AES_CBC not for AES CTR. > > Please? can any one tell me where to look for the test vectors to test > RNG using? AES CTR. They are trivially constructed from the test vectors for AES in ECB mode (just as counter mode is trivially constructed from ECB mode). Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From lloyd at randombit.net Fri Sep 4 16:14:19 2009 From: lloyd at randombit.net (Jack Lloyd) Date: Fri, 4 Sep 2009 16:14:19 -0400 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: <890362.773.qm@web95316.mail.in2.yahoo.com> References: <890362.773.qm@web95316.mail.in2.yahoo.com> Message-ID: <20090904201419.GQ7567@randombit.net> On Wed, Sep 02, 2009 at 10:58:03AM +0530, priya yelgar wrote: > Hi all, > > I have implemented RNG using AES algorithm in CTR mode. > > To test my implementation I needed some test vectors. > > How ever I searched on the CSRC site, but found the test vectors for AES_CBC not for AES CTR. > > Please? can any one tell me where to look for the test vectors to test RNG using? AES CTR. NIST SP 800-38A "Recommendation for Block Cipher Modes of Operation" contains a set of AES/CTR test vectors in Appendix F.5 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf -Jack --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From crawdad at fnal.gov Fri Sep 4 16:24:30 2009 From: crawdad at fnal.gov (Matt Crawford) Date: Fri, 04 Sep 2009 15:24:30 -0500 Subject: "Fed's RFIDiocy pwnd at DefCon" In-Reply-To: <8C436C24-A2FA-4BAC-B843-F572133A7ECD@lrw.com> References: <8C436C24-A2FA-4BAC-B843-F572133A7ECD@lrw.com> Message-ID: <2DBB37B5-033A-4E8E-BB9B-71F1D2225464@fnal.gov> On Sep 1, 2009, at 9:55 PM, Jerry Leichter wrote: > ". . . federal agents at the conference got a scare on Friday when > they were told they might have been caught in the sights of an RFID > reader. > > The reader, connected to a web camera, sniffed data from RFID- > enabled ID cards and other documents carried by attendees in pockets > and backpacks as they passed a table where the equipment was > stationed in full view...." I told them so... http://csrc.nist.gov/groups/SNS/piv/documents/FIPS201-Public-Comments/Fermilab-Computer-Security.pdf --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Nicolas.Williams at sun.com Fri Sep 4 16:09:23 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 4 Sep 2009 15:09:23 -0500 Subject: Client Certificate UI for Chrome? In-Reply-To: References: <6B01AD9C-D0A3-4F9F-8C82-CE1A6FBB3AC3@cs.columbia.edu> Message-ID: <20090904200923.GQ1033@Sun.COM> On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote: > Steven Bellovin writes: > >This returns us to the previously-unsolved UI problem: how -- with today's > >users, and with something more or less like today's browsers since that's > >what today's users know -- can a spoof-proof password prompt be presented? > > Good enough to satisfy security geeks, no, because no measure you take will > ever be good enough. [...] Well, if you're willing to reserve screen real estate, keyboard key combinations, and so on, with said reserved screen space used to indicate unambiguously the nature of other things displayed, and reserved input combinations used to trigger trusted software paths, then yes, you can solve that problem. That's the premise of "trusted desktops", at any rate. There are caveats, like just how large the TCB becomes (including parts of the browser), the complexity of the trusted information to be presented to users versus the limited amount of screen real estate available to convey it, the need to train users to understand the concept of trusted desktops, no fullscreen apps can be allowed, accessibility issues, it all falls apart if the TCB is compromised, ... Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From eay at pobox.com Fri Sep 4 18:25:30 2009 From: eay at pobox.com (Eric Young) Date: Sat, 05 Sep 2009 08:25:30 +1000 Subject: [cryptography] AES-GMAC as a hash In-Reply-To: <4A969C23.5090007@Sun.COM> References: <5733F11F-D4FA-4258-A8A7-331BFD4DA116@zooko.com> <9FB8FE44-09EF-4A2E-9502-11E417C26564@lrw.com> <4A969C23.5090007@Sun.COM> Message-ID: <4AA193DA.4080706@pobox.com> Darren J Moffat wrote: > Ignoring performance for now what is the consensus on the suitabilty > of using AES-GMAC not as MAC but as a hash ? > > Would it be safe ? > > The "key" input to AES-GMAC would be something well known to the data > and/or software. > > The only reason I'm asking is assuming it can be made to perform on > some classes of machine better than or close to SHA256 if it would be > worth considering as an available alternate now until SHA-3 is choosen. > Regarding the speed of GMAC, Intel has added a carry-less-multiplication instruction to their next generation CPUs (PCLMULQDQ)[1]. The core is the Westmere, and is shipping in engineering samples, now. This is also the CPU generation to contain the AES instructions. Unfortunately I'm only running my implementation under the intel simulator which is not cycle accurate, so I'm not sure just how fast this hardware support will make things. My understanding is that the next generation AMD CPUs, (bulldozer) will also support these instructions. eric [1] http://software.intel.com/en-us/articles/carry-less-multiplication-and-its-usage-for-computing-the-gcm-mode/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From dj at deadhat.com Fri Sep 4 23:57:30 2009 From: dj at deadhat.com (David Johnston) Date: Fri, 04 Sep 2009 20:57:30 -0700 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: <890362.773.qm@web95316.mail.in2.yahoo.com> References: <890362.773.qm@web95316.mail.in2.yahoo.com> Message-ID: <4AA1E1AA.8060006@deadhat.com> NIST doesn't provide specific KAT vectors for AES-CTR because the results depend on your specific counter construction. When you interact with a FIPS test lab, you will provide them with your counter construction, they will provide you with the KATs and you will then test to those KATs. This is probably why you are not finding AES-CTR vectors in the same places you might find AES-CBC vectors. NIST explains this somewhere in their publications. Convincing yourself that you have implemented AES-CTR correctly usually involves first checking that your AES-ECB is correct, then putting the output of you counter construction into some other known good AES-CTR implementation and comparing the results with your implementation. Regards, DJ priya yelgar wrote: > Hi all, > > I have implemented RNG using AES algorithm in CTR mode. > > To test my implementation I needed some test vectors. > > How ever I searched on the CSRC site, but found the test vectors for AES_CBC not for AES CTR. > > Please can any one tell me where to look for the test vectors to test RNG using AES CTR. > > > Thanks in advance > Priya Ainapur > > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jamesd at echeque.com Sat Sep 5 02:14:46 2009 From: jamesd at echeque.com (James A. Donald) Date: Sat, 05 Sep 2009 16:14:46 +1000 Subject: [tahoe-dev] Bringing Tahoe ideas to HTTP In-Reply-To: <4A9C4A1B.4000900@lothar.com> References: <4A970144.8020709@lothar.com> <20090831164845.GO1033@Sun.COM> <4A9C4A1B.4000900@lothar.com> Message-ID: <4AA201D6.7030803@echeque.com> Nicolas Williams wrote: > > One possible problem: streaming [real-time] content. Brian Warner wrote: > Yeah, that's a very different problem space. You need > the low-alacrity stuff from Tahoe, but also you don't > generally know the full contents in advance. So you're > talking about a mutable stream rather than an > immutable file. Not mutable, just incomplete. Immutable streaming content needs a tiger hash or a patricia hash, which can handle the fact that some of the stream will be lost in transmission, and that one needs to validate the small part of the stream that one has already received rather than waiting for the end. > upgrade bundles are produced by a very strict process, > and are rigidly immutable [...] For software upgrades, > it would reduce the attack surface significantly. But how does one know which immutable file is the one that has been blessed by proper authority? Although Version 3.5.0 is immutable, what makes it Version 3.5.0, rather than haxx350, is that some authority says so - the same authority that said that your current version is 3.4.7 - and it should not even be possible to get a file named by some different authority as an upgrade. Of course, one would like a protocol that committed the authority to say the same thing for everyone, and the same thing for all time, saying new things in future, but never being able to retroactively adjust past things it has said. In other words, upgrades should be rooted in an append only capability. I suppose this could be implemented as a signed dag of hashes, in which whenever one upgraded, one checked that the signed dag that validates the upgrade is consistent with the signed dag that validated the current version. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Sun Sep 6 03:34:24 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sun, 06 Sep 2009 19:34:24 +1200 Subject: Client Certificate UI for Chrome? In-Reply-To: <4AA18796.1020808@systemics.com> Message-ID: Ian G writes: >If one is trying to solve the whole thing, then using the much-commented >secure-bookmarks model would do this. Within the secure bookmark, record the >user's certificate and cache enough info on the server's cert to deal with >replacements (like, cert, name, CA). There's a variant of this, the site-specific browser (SSB), that takes you to (for example) your bank in a strongly sandboxed, hardened environment. This reduces the cognitive load on the user from a more or less impossible-to- follow set of instructions to "only ever do your banking by clicking on this desktop icon". This isn't by any means a general solution, but by solving for the most common cases (your bank, Paypal, eBay, Amazon) you'd address a fairly large chunk of the problem. See "Breaking out of the Browser to Defend Against Phishing Attacks" by Smetters and Stewart for more details on this. >Others have suggested some ideas, so I'll just add: the problem isn't IMO >how to do it. There are lots of good ideas. Actually that does point out one problem, which I alluded to in my previous post: we have lots and lots of good ideas, but little hard data to indicate which ones will work and which won't, or which ones work better than others (although the cynical response to this might be that almost anything would work better than what we've got now). Specifically, there are a pile of papers along the lines of "here's an experiment showing that what we're doing now doesn't work, here's a completely new security mechanism we've invented that involves redesigning the browser and server authentication back-end, and as a side-effect here are some UI ideas to go with it". What we don't have however is "here's a real-world evaluation of various ideas that have been proposed for fixing what we already have built into browsers and servers". Unfortunately without this data we (including myself) are to some extent just "people wanking around with their opinions" [0]. It's also not certain how such data would be published. Which journal or conference would accept a paper with no "new ideas" in it, just a straightforward evaluation of existing material? Peter. [0] A Linus quote, brought about by a discussion on the difference between OS secheduler design and security design: "the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is 'hard science'. The other one is 'people wanking around with their opinions'". --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Sun Sep 6 20:12:37 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 6 Sep 2009 20:12:37 -0400 Subject: Client Certificate UI for Chrome? In-Reply-To: References: Message-ID: <960F77F7-29AD-4855-A670-DBFF170CC06D@cs.columbia.edu> On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote: > Steven Bellovin writes: > >> This returns us to the previously-unsolved UI problem: how -- with >> today's >> users, and with something more or less like today's browsers since >> that's >> what today's users know -- can a spoof-proof password prompt be >> presented? > > Good enough to satisfy security geeks, no, because no measure you > take will > ever be good enough. However if you want something that's good > enough for > most purposes then Camino has been doing something pretty close to > this since > it was first released (I'm not aware of any other browser that's > even tried). > When you're asked for credentials, the dialog rolls down out of the > browser > title bar in a hard-to-describe scrolling motion a bit like a > supermarket till > printout. In other words instead of a random popup appearing in > front of you > from who knows what source and asking for a password, you've got a > direct > visual link to the thing that the credentials are being requested > for. You > can obviously pepper and salt this as required (and I wouldn't dream > of > deploying something like this without getting UI folks to comment > and test it > on real users first), but doing this is a tractable UI design issue > and not an > intractable business-model/political/social/etc problem. Several other people made similar suggestions. They all boil down to the same thing, IMO -- assume that the user will recognize something distinctive or know to do something special for special sites like banks. Both, to me, are unproven assumptions. Worse yet, both the security literature and what I've seen of user behavior strongly suggest to me that neither scenario is true. Peter, I'm not sure what you mean by "good enough to satisfy security geeks" vs. "good enough for most purposes". I'm not looking for theoretically good enough, for any value of "theory"; my metric -- as a card-carrying security geek -- is precisely "good enough for most purposes". A review of user studies of many different distinctive markers, from yellow URL bars to green partial-URL bars to special pictures to you-name-it shows that users either never notice the *absence* of the distinctive feature or are fooled by a tailored attack (see, e.g., the paper on picture-in-picture attacks). Maybe Camino is really better -- or maybe it just hasn't been properly attacked yet, say by a clever flash animation or some AJAX weirdness. Given the failure of all previous attempts -- who, amongst the proponents of EV certificates, realized that attackers could and would use all-green favicon.ico files to fool users -- I think the burden of proof is on the proponents. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From warner at lothar.com Mon Sep 7 04:05:20 2009 From: warner at lothar.com (Brian Warner) Date: Mon, 07 Sep 2009 01:05:20 -0700 Subject: [tahoe-dev] Bringing Tahoe ideas to HTTP In-Reply-To: <4AA201D6.7030803@echeque.com> References: <4A970144.8020709@lothar.com> <20090831164845.GO1033@Sun.COM> <4A9C4A1B.4000900@lothar.com> <4AA201D6.7030803@echeque.com> Message-ID: <4AA4BEC0.1030907@lothar.com> James A. Donald wrote: > Nicolas Williams wrote: > > > One possible problem: streaming [real-time] content. > > Brian Warner wrote: > > Yeah, that's a very different problem space. You need > > the low-alacrity stuff from Tahoe, but also you don't > > generally know the full contents in advance. So you're > > talking about a mutable stream rather than an > > immutable file. > > Not mutable, just incomplete. > > Immutable streaming content needs a tiger hash or a > patricia hash, which can handle the fact that some of > the stream will be lost in transmission, and that one > needs to validate the small part of the stream that one > has already received rather than waiting for the end. I was assuming a real-time stream, so the goal would be to provide a filecap before the source had finished generating all the bits. This would necessarily be a mutable filecap, unless you've got some way of predicting the future :-). If instead, you just have a large file that a client wants to fetch one piece at a time, well, Tahoe's immutable-file merkle trees already handle the goal of quickly validating a small part of a large byte sequence. You could use this in a non-real-time stream, in which you process the entire input stream, produce and publish the filecap, then a client fetches pieces of that stream at their own pace. > > upgrade bundles are produced by a very strict process, > > and are rigidly immutable [...] For software upgrades, > > it would reduce the attack surface significantly. > > But how does one know which immutable file is the one > that has been blessed by proper authority? You're right, I was assuming a pre-existing secure "what to upgrade to" channel which could send down an integrity-enhanced download URL. To actually implement such a channel would require further integrity guarantees over mutable data. As I understand it, Firefox actually has a fairly complex upgrade path, because only certain combinations of from-version/to-version are fully tested by QA. Sometimes moving from e.g. 3.0.0.8 to 3.5.0.3 requires going through a 3.0.0.8->3.0.0.9->3.5.0.0->3.5.0.2->3.5.0.3 sort of path. The upgrade channel basically provides instructions to each older version, telling them which new version they should move to. The best sort of integrity guarantees I could think of would be a rule that says "the new version must be signed by my baked-in DSA key and have a version number that is greater than mine", or maybe just "the upgrade instructions must be signed by that DSA key". It's probably not a robust idea to make the rules too strict. cheers, -Brian --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Mon Sep 7 08:41:24 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 08 Sep 2009 00:41:24 +1200 Subject: Client Certificate UI for Chrome? In-Reply-To: <960F77F7-29AD-4855-A670-DBFF170CC06D@cs.columbia.edu> Message-ID: Steven Bellovin writes: >Peter, I'm not sure what you mean by "good enough to satisfy security geeks" >vs. "good enough for most purposes". I'm not looking for theoretically good >enough, for any value of "theory"; my metric -- as a card-carrying security >geek -- is precisely "good enough for most purposes". Here's a real-world example of the problem I was referring to, from a discussion with some browser developers. We were going over the above issue - how to use the results of usability studies to improve the browser security UI - and I asked why, if they were aware of this work, no-one had done anything with it. The response was that "if we implement this then attackers will use XUL to spoof it, and because of that it's not even worth trying". In other words because a hypoethetical weakness existed, it wasn't even worth attempting to improve anything. Instead of trying to help at least some of the people some of the time, it was better to leave everyone unprotected all of the time. >Given the failure of all previous attempts -- who, amongst the proponents of >EV certificates, realized that attackers could and would use all-green >favicon.ico files to fool users -- I think the burden of proof is on the >proponents. But the problem with these approaches is that they're pretty much all just random tweaking of the same thing, aimlessly rearranging the UI elements in the hope that eventually something will work after (as you point out) the twenty more or less identical previous attempts have failed. For example the Firefox password-entry mechanism (a generic popup dialog with a gibberish title) hasn't changed in at least ten years (possibly even longer, I can't remember what the Netscape 2.0 one looked like any more), all that's changed is that every major release a few new bits of flair get added to the browser chrome. The "previous attempts" aren't lots of different approaches, it's the same failed approach tried over and over and over again, with slight variations over time in the hope that one of them might work. What I was advocating was trying new approaches based on ideas from UI research, not just fiddling with the chrome in the hope that this time it'll finally start working. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Mon Sep 7 08:58:10 2009 From: leichter at lrw.com (Jerry Leichter) Date: Mon, 7 Sep 2009 08:58:10 -0400 Subject: Client Certificate UI for Chrome? In-Reply-To: References: Message-ID: On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote: >> This returns us to the previously-unsolved UI problem: how -- with >> today's >> users, and with something more or less like today's browsers since >> that's >> what today's users know -- can a spoof-proof password prompt be >> presented? > > Good enough to satisfy security geeks, no, because no measure you > take will > ever be good enough. However if you want something that's good > enough for > most purposes then Camino has been doing something pretty close to > this since > it was first released (I'm not aware of any other browser that's > even tried). > When you're asked for credentials, the dialog rolls down out of the > browser > title bar in a hard-to-describe scrolling motion a bit like a > supermarket till printout.... I'm not sure what version of Camino you're running. The most recent versions use a standard Mac OS GUI element to prompt for passwords - it's indistinguishable from what you get from Safari. In both cases, a special prompt window scrolls down out of the chrome, covering some of the main body of the window. It has a distinctive look: After it's scrolled down, it appears to be "under" the chrome but over the top of the body. In Safari - I didn't experiment with Camino - it's physically tied to the browser window, moving and iconifying with it, and is fully modal at the window level - you can't switch to another tab in the same window. (Curiously, you *can* switch to a different window.) The "loading" indicator in the address bar remains active while you're being prompted. The *intent* is clearly to create something hard to spoof, but I don't know enough Flash to say if one could produce an accurate, or even plausible, fake. (Of course, *most* passwords on the Web are entered into some random web page. A distinctive secure prompt that only appears in a minority of cases doesn't help much.) The most common MacOS password prompts are from the keychain program, since you typically store your passwords there. (There are configurations in which it just asks for permission, not for a password; and configurations in which it just sends the password. But if you want to be careful, you only want keychains unlocked when you intend to use them.) Since *any* program - including programs with no visible GUI - can use keychains, these prompts are necessarily stand- alone windows at least sometimes (and for uniformity, they are so all the time). Those could be spoofed more easily (though if you're really cautious, you can unlock the necessary keychain by hand ahead of time and arrange to just give permission to use the entry later, so you're never entering your password into a window that just pops up on its own). -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Mon Sep 7 09:02:43 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 08 Sep 2009 01:02:43 +1200 Subject: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git) In-Reply-To: <20090827152340.GA1172@rek.tjls.com> Message-ID: Thor Lancelot Simon writes: >I think we're largely talking past one another. As regards "new horrible >problems" I meant simply that if there _are_ "new horrible problems_ such >that we need to switch away from SHA1 in the TLS PRF, the design mistakes >made in TLS 1.1 will make it much harder. Well, let's move the TLS 1.2 aspect out of the discussion and look at the underlying issues. If you're looking at this purely from a theoretical point of view then it's possible that the ability to use SHA-2 in the PRF is an improvement (it may also be a step backwards since you're now relying on a single hash rather than the dual hash used in the original design). Since no- one knows of any attacks, we don't know whether it's a step backwards, a step forwards, or (most likely) a no-op. However there's more to it than this. Once you've got the crypto sorted out, you need to implement it, and then deploy it. So looking at the two options you have: Old: No known crypto weaknesses. Interoperable with all deployed implementations. Only one option, so not much to get wrong. New: No known crypto weaknesses. Interoperable with no deployed implementations. Lots of flexibioity and options to get wrong. Removing the common factors (the crypto portion) and the no-op terms ("interoperable with existing implementations") we're left with: Old: - New: Non-interoperable. Complex -> Likely to exhibit security flaws (from the maxim that complexity is the enemy of security). That's a rather high cost to pay just for the ability to make a crypto fashion statement. Even if the ability to negotiate hash algorithms had been built in from the start, this only removes the non-interoperability but doesn't remove the complexity issue. >As I read Ben's comments, they were _advocating_ those kinds of design >mistakes, advocating hard-wiring particular algorithms or their parameter >sizes into protocols, You keep asserting that this is a mistake, but in the absence of any cryptographic argument in support, and with practical arguments against it, it looks like a feature to me. >In fact, it is radically harder to replace an entire protocol, even with a >related one, than to drop a new algorithm into an existing, properly-designed >protocol. A properly-designed security protocol is one that's both cryptographically sound and simple enough that it's hard to get wrong (or at least relatively easy to get right, admittedly not necessarily the same thing). Adding a pile of complexity simply so you can make a crypto fashion statement doesn't seem to be helping here. >If TLS 1.{0,1} had been designed to make the hash functions pluggagle >everywhere ... like that model of security protocol design IKEv1 was [0], then we'd have all kinds of interop problems and quite probably security issues based on exploitation of the unnecessary complexity of the protocol, for a net loss in security and interoperability, and nothing gained. Peter. [0] Apologies to the IPsec folks on the list, just trying to illustrate the point. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From DaveHowe at gmx.co.uk Mon Sep 7 10:26:58 2009 From: DaveHowe at gmx.co.uk (Dave Howe) Date: Mon, 07 Sep 2009 15:26:58 +0100 Subject: Source for Skype Trojan released In-Reply-To: <50AF764C-F6B3-47E5-BE84-5F4216F0907F@st.cs.uni-sb.de> References: <50AF764C-F6B3-47E5-BE84-5F4216F0907F@st.cs.uni-sb.de> Message-ID: <4AA51832.70903@gmx.co.uk> Stephan Neuhaus wrote: > > On Aug 31, 2009, at 13:20, Jerry Leichter wrote: > >> It can ?...intercept all audio data coming and going to the Skype >> process.? > > Interesting, but is this a novel idea? As far as I can see, the process > intercepts the audio before it reaches Skype and after it has left > Skype. Isn't that the same as calling a keylogger a "PGP Trojan"? Not really. more generically, you could call it a "VoIP trojan" or even "Audio monitoring trojan" - presumably a more advanced version could listen to the mic stream even when the VoIP application is not in use, in order to obtain information. However, in context, this was designed to be used for law enforcement to "bug" a skype VoIP session, so the name reflects the design goal; yes, it is a more generalized attack than that, but not in intent or (presumed) usage. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From zooko at zooko.com Tue Sep 8 11:53:44 2009 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Tue, 8 Sep 2009 09:53:44 -0600 Subject: so how do *you* manage your keys, then? part 3 In-Reply-To: <20090908215405.20392dvo5z903fls@cheesypoof.guarana.org> References: <20090908215405.20392dvo5z903fls@cheesypoof.guarana.org> Message-ID: <80AF17F5-0CA6-410E-A018-7D3FDB122A1A@zooko.com> [added Cc: tahoe-dev at allmydata.org, and I added kevin at guarana.org on the whitelist so his posts will go through to tahoe-dev even if he isn't subscribed] On Tuesday,2009-09-08, at 5:54 , Kevin Easton wrote: >> Possession of the read-cap to the mutable file gives you two >> things: it gives you the symmetric encryption key with which you >> decrypt the file contents, and it gives you the public key with >> which you check a digital signature in order to be sure that the >> file contents were written by an authorized writer. > > How do you prevent someone possessing the read-cap for a mutable > file from rolling the file back to an earlier version that they > have seen, without the consent of the write-cap possessor(s)? You don't even need a read-cap to perform a roll-back attack -- if you can control the ciphertext that the reader gets, then you can give them a copy of an older ciphertext, even if you yourself are incapable of decrypting it. This is a difficult attack to defend against. In the current version of Tahoe-LAFS we already have one interesting defense -- we the reader is communicating with many different servers, and if *any* of the servers is honest and up-to- date and informs the reader about the existence of a newer version, then the reader knows that the older version that he can read is not the latest. Readers in Tahoe-LAFS always download shares of the file from multiple servers, and all of the servers that it uses would have to agree on the version number. Therefore, to perform a rollback attack you need to control at least that many servers as well as you have to control or deny-access-to any other servers which the reader would query and which would inform him about the newer version number. See section 5 of [1]. Does that answer your question about rollback? It would be interesting to build stronger defenses against rollback attack. For starters, if the same reader reads the same file multiple times and gets new contents each time, he might as well remember the version number so that he will detect whether that file rolled back during his inspection of it. Also, it would be interesting if a file handle to a mutable file included the version number that the mutable file was at when the file handle was created. Building on that, it would be really cool if, in a future version of Tahoe-LAFS, we could make it so that you can take a cheap snapshot of the current contents and then give someone a file-handle which *both* securely identified "the most recent version that you can find of this file" and *also* "the specific (immutable) version of this file that existed when I created this file-handle". > Also, am I correct in assuming that once write-caps have been > distributed, they cannot be revoked, and a new file handle must be > created? Currently, yes. An improvement that I would like to make in the next version of Tahoe-LAFS is to allow the holder of a write-cap to revoke it. While some kinds of revocation are tantamount to DRM ("Digital Restrictions Management") and seem to be sufficiently difficult that we're not even going to try to implement them, the specific kind of revocation that you asked about seems to be quite doable. Also, it happens to be the kind of revocation that I have already wanted for my own personal use of Tahoe-LAFS (to host my blog). :-) Here is a letter about that which explains why I needed this and how I envision it working: [2] Stronger defenses against rollback attack, and revocation of write- caps -- these are only a few of the many possible extensions to the Tahoe-LAFS secure storage design. We have a rich library of such designs documented on our issue tracker and our wiki. We are currently having a detailed design discussion on the tahoe-dev list to which several cryptographers are contributing [e.g. 3, 4]. The primary goal for the next version of Tahoe-LAFS caps is to reduce the size of the caps and improve performance, but we're also cataloguing new features such as these to see if we can work them in. Here is the wiki page where we're keeping our notes: [5]. If any smart cryptographer or hacker reading this wants to create secure, decentralized storage, please join us! We could use the help! :-) Regards, Zooko [1] http://allmydata.org/~zooko/lafs.pdf [2] http://allmydata.org/pipermail/tahoe-dev/2009-June/001995.html [3] http://allmydata.org/pipermail/tahoe-dev/2009-July/002345.html [4] http://allmydata.org/pipermail/tahoe-dev/2009-September/002808.html [5] http://allmydata.org/trac/tahoe/wiki/NewCapDesign --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Mon Sep 7 09:06:59 2009 From: leichter at lrw.com (Jerry Leichter) Date: Mon, 7 Sep 2009 09:06:59 -0400 Subject: Client Certificate UI for Chrome? In-Reply-To: References: Message-ID: On Sep 7, 2009, at 8:58 AM, Jerry Leichter wrote: > ...standard Mac OS GUI element to prompt for passwords ... I should expand on that a bit: This GUI element is used for all kinds of things tied to a window, not just passwords. For example, if you try to close a window that contains stuff you haven't saved, the same element is used to ask you to confirm, save now, or cancel. So it's a pretty familiar thing to Mac users.... -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Tue Sep 8 22:08:59 2009 From: leichter at lrw.com (Jerry Leichter) Date: Tue, 8 Sep 2009 22:08:59 -0400 Subject: "Fed's RFIDiocy pwnd at DefCon" In-Reply-To: <2DBB37B5-033A-4E8E-BB9B-71F1D2225464@fnal.gov> References: <8C436C24-A2FA-4BAC-B843-F572133A7ECD@lrw.com> <2DBB37B5-033A-4E8E-BB9B-71F1D2225464@fnal.gov> Message-ID: <5EEAE483-8629-42D8-8636-3619FA722B8E@lrw.com> On Sep 4, 2009, at 4:24 PM, Matt Crawford wrote: >> ". . . federal agents at the conference got a scare on Friday when >> they were told they might have been caught in the sights of an RFID >> reader. >> >> The reader, connected to a web camera, sniffed data from RFID- >> enabled ID cards and other documents carried by attendees in >> pockets and backpacks as they passed a table where the equipment >> was stationed in full view...." > > > I told them so... > > http://csrc.nist.gov/groups/SNS/piv/documents/FIPS201-Public-Comments/Fermilab-Computer-Security.pdf Remember: Before it's actually happened, any discussion is just reckless speculation, rumor-mongering, or worse. After it's actually happened, it's either (a) not a real issue; (b) a major new attack that could not have been foreseen but that will be dealt with immediately by top people. Top people. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Wed Sep 9 02:43:38 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Wed, 09 Sep 2009 18:43:38 +1200 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: <4AA1E1AA.8060006@deadhat.com> Message-ID: David Johnston writes: >Convincing yourself that you have implemented AES-CTR correctly usually >involves first checking that your AES-ECB is correct, then putting the output >of you counter construction into some other known good AES-CTR implementation >and comparing the results with your implementation. I was just going to reply with a variation of this, if you're implementing a full protocol that uses AES-CTR (or any algorithm/mode for that matter), find other implementations that do it too and make sure that you can talk to them. In theory everyone could end up implementing it wrong, but that's somewhat unlikely. (This has already caught AES-CTR implementation bugs in the past, for example one particular version of OpenSSL 0.9.8 got AES-CTR keying wrong and it was noticed when SSH users couldn't connect to OpenSSH servers using this mode). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jamesd at echeque.com Wed Sep 9 01:42:34 2009 From: jamesd at echeque.com (James A. Donald) Date: Wed, 09 Sep 2009 15:42:34 +1000 Subject: Client Certificate UI for Chrome? In-Reply-To: <960F77F7-29AD-4855-A670-DBFF170CC06D@cs.columbia.edu> References: <960F77F7-29AD-4855-A670-DBFF170CC06D@cs.columbia.edu> Message-ID: <4AA7404A.8010205@echeque.com> Steven Bellovin wrote: > Several other people made similar suggestions. They all boil down to > the same thing, IMO -- assume that the user will recognize something > distinctive or know to do something special for special sites like > banks. Not if he only does it for special sites like banks, but if "something special" is pretty widely used, he will notice when things are different. > Peter, I'm not sure what you mean by "good enough to satisfy security > geeks" vs. "good enough for most purposes". I'm not looking for > theoretically good enough, for any value of "theory"; my metric -- as a > card-carrying security geek -- is precisely "good enough for most > purposes". A review of user studies of many different distinctive > markers, from yellow URL bars to green partial-URL bars to special > pictures to you-name-it shows that users either never notice the > *absence* of the distinctive feature I never thought that funny colored url bars for banks would help, and ridiculed that suggestion when it was first made, and said it was merely an effort to get more money for CAs, and not a serious security proposal The fact that obviously stupid and ineffectual methods have failed is not evidence that better methods would also fail. Seems to me that you are making the argument "We have tried everything that might increase CA revenues, and none of it has improved user security, so obviously user security cannot be improved." --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Wed Sep 9 08:10:45 2009 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Wed, 9 Sep 2009 08:10:45 -0400 Subject: Client Certificate UI for Chrome? In-Reply-To: <4AA7404A.8010205@echeque.com> References: <960F77F7-29AD-4855-A670-DBFF170CC06D@cs.columbia.edu> <4AA7404A.8010205@echeque.com> Message-ID: <20090909081045.210249da@cs.columbia.edu> On Wed, 09 Sep 2009 15:42:34 +1000 "James A. Donald" wrote: > Steven Bellovin wrote: > > Several other people made similar suggestions. They all boil down > > to the same thing, IMO -- assume that the user will recognize > > something distinctive or know to do something special for special > > sites like banks. > > Not if he only does it for special sites like banks, but if > "something special" is pretty widely used, he will notice when things > are different. We conducted a small-scale controlled user study -- it didn't work. > > > Peter, I'm not sure what you mean by "good enough to satisfy > > security geeks" vs. "good enough for most purposes". I'm not > > looking for theoretically good enough, for any value of "theory"; > > my metric -- as a card-carrying security geek -- is precisely "good > > enough for most purposes". A review of user studies of many > > different distinctive markers, from yellow URL bars to green > > partial-URL bars to special pictures to you-name-it shows that > > users either never notice the *absence* of the distinctive feature > > I never thought that funny colored url bars for banks would help, and > ridiculed that suggestion when it was first made, and said it was > merely an effort to get more money for CAs, and not a serious > security proposal > > The fact that obviously stupid and ineffectual methods have failed is > not evidence that better methods would also fail. > > Seems to me that you are making the argument "We have tried > everything that might increase CA revenues, and none of it has > improved user security, so obviously user security cannot be > improved." > Not quite. I'm not saying it "cannot be improved". I'm saying that controlled studies thus far have demonstrated none of the proposed methods have worked, against fairly straight-forward new attacks. And if we've learned one thing over the last ten years, it's that the attackers are as good as we are at what they do. There's money to be made and the market has worked its wonders: there is a demand for capable hackers, and they're making enough money to attract good people. What I am saying is twofold. First -- when you invent a new scheme, do a scientific test: does it actually help? Don't assume that because pure reason tells you it's a good idea, it actually is in the real world. Second -- you may very well be right that tinkering with the password entry mechanisms cannot succeed, because users are habituated to many different mechanisms and to login screens that regularly change because some VP in charge of publicity has decided that the site's web presence looks old-fashioned and needs to be freshened. In that case, we have to look at entirely different approaches. (How many different experiments will it take to convince people that you can't make gold by mixing chemicals together?) --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From matthew.v.ball at gmail.com Wed Sep 9 09:38:00 2009 From: matthew.v.ball at gmail.com (Matt Ball) Date: Wed, 9 Sep 2009 07:38:00 -0600 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: <890362.773.qm@web95316.mail.in2.yahoo.com> References: <890362.773.qm@web95316.mail.in2.yahoo.com> Message-ID: On Tue, Sep 1, 2009 at 11:28 PM, priya yelgar wrote: > I have implemented RNG using AES algorithm in CTR mode. > > To test my implementation I needed some test vectors. > > How ever I searched on the CSRC site, but found the test vectors for AES_CBC not for AES CTR. > > Please? can any one tell me where to look for the test vectors to test RNG using? AES CTR. The first thing that jumps out at me is that you're looking for a nebulous "Randon Number Generator" based on AES CTR mode (defined by SP 800-38A), and this is cast in the context of NIST's CSRC website (http://csrc.nist.gov/). Referencing NIST implies that you're looking for some kind Algorithm Certificate or FIPS 140-2 certification for a cryptographic module. If this is true, then you cannot just use 'AES CTR' to generate FIPS-approved random numbers. Instead, you need to use one of the approved RNG methods listed in FIPS 140-2 Annex C "Approved Random Number Generators". This includes several RNGs, including AES and 3DES variants based on ANSI X9.31, and SP 800-90. The closest thing to AES CTR is the CTR_DRBG defined in SP 800-90, which uses AES CTR for the random number generation, but also handles important things like distilling the initial entropy pool and periodic re-keying. Even if you're not intending to get FIPS 140-2 certification, I still highly recommend finding a good standard describing a 'recipe' for generating pseudo-random numbers, and follow the requirements for that. 'RNG using AES in CTR mode' is much different than 'Encryption using AES in CTR mode', and needs to be carefully handled accordingly. It's really easy to get things wrong outside of the AES CTR portion of the problem. You need to worry about justifying a particular entropy content of your true random source, which is then distilled down to create your key and nonce for the AES CTR portion of the RNG. This is not a task that is taken lightly. My personal recommendation is to go with the CTR_DRBG as defined in SP 800-90. You can easily find open source implementations of this algorithm, so I'm not even sure if you need to spend time implementing it. To test it, I recommend going through the process of getting an algorithm certificate from NIST. Cheers! Matt Ball, Chair, IEEE P1619 Security in Storage Working Group Staff Engineer, Sun Microsystems, Inc. 500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021 Work: 303-272-7580, Cell: 303-717-2717 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Wed Sep 9 11:01:51 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 9 Sep 2009 11:01:51 -0400 Subject: NSA intercepts led to a terrorist conviction Message-ID: <17E6F034-6798-4649-9F21-2EF26CE4C0BD@cs.columbia.edu> "Threat Level Privacy, Crime and Security Online NSA-Intercepted E-Mails Helped Convict Would-Be Bombers The three men convicted in the United Kingdom on Monday of a plot to bomb several transcontinental flights were prosecuted in part using crucial e-mail correspondences intercepted by the U.S. National Security Agency, according to Britain?s Channel 4. The e-mails, several of which have been reprinted by the BBC and other publications, contained coded messages, according to prosecutors. They were intercepted by the NSA in 2006 but were not included in evidence introduced in a first trial against the three last year. http://www.wired.com/threatlevel/2009/09/nsa-email/ has more. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From zooko at zooko.com Wed Sep 9 13:53:40 2009 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Wed, 9 Sep 2009 11:53:40 -0600 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: References: Message-ID: And while you are at it, please implement these test vectors and report to Niels Ferguson: http://blogs.msdn.com/si_team/archive/2006/05/19/aes-test-vectors.aspx Regards, Zooko --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From eugen at leitl.org Thu Sep 10 04:49:01 2009 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 10 Sep 2009 10:49:01 +0200 Subject: Serpent close to AES speed thanks to SSE2 Message-ID: <20090910084901.GP9828@leitl.org> http://www.randombit.net/bitbashing/programming/serpent_in_simd.html Wed, 09 Sep 2009 Speeding up Serpent: SIMD Edition The Serpent block cipher was one of the 5 finalists in the AES competition, and is widely thought to be the most secure of them due to its conservative design. It was also considered the slowest candidate, which is one major reason it did not win the AES contest. However, it turns out that on modern machines one can use SIMD operations to implement Serpent at speeds quite close to AES. Serpent uses an interesting bitsliced design with eight 4 bit sboxes which are computed in parallel using boolean operations on registers. Rather than splitting up the 32 bit words into nibbles and passing them through table lookups, a special instruction sequence is used which performs the same operation using only instructions like AND, OR, XOR, and NOT. Typically these are done using 32 bit register operations, but it was recently suggested that SIMD operations such as those available in SSE2 or AltiVec could be used to encrypt 4 blocks in parallel. Most cipher modes, such as CBC and OFB, are iterative; after splitting the plaintext into blocks, the input to the second block depends on the previously computed ciphertexts. This data dependency means it is impossible to use a block-parallel implementation in these modes. However some other modes, including CTR, EAX, and XTS, do not exhibit this data dependency, and allow for many blocks to be encrypted in parallel. So being able to compute many encryptions in parallel is only useful for these modes. Fortunately, CTR, EAX, and XTS are very useful, unpatented, and (in the case of CTR and XTS) widely standardized modes. Recently I implemented Serpent using SSE2 intrinsics in the botan cryptography library. While not quite as fast as AES, it easily boosts Serpents performance by a factor of over 2.5 on an Intel Core2 processor. Up until now, botan has used a rather conventional block cipher interface where only a single block of data (typically 64 or 128 bits) would be encrypted at a time; processing multiple blocks required calling the function multiple times, one for each block. However this completely hides any parallelism from the block cipher implementation. So in the upcoming development release (1.9.0), botan offers two new interfaces for block ciphers: void encrypt_n(const byte in[], byte out[], u32bit blocks) const; void decrypt_n(const byte in[], byte out[], u32bit blocks) const; which will process many blocks in a single call. In addition some mode implementations (at this time, ECB and CTR) will batch their inputs into larger groups. This will not only allow for parallel encryption using SIMD techniques, it also improves instruction and data cache utilization for all ciphers. Right now, the modes will batch 8 blocks of data together; it is unclear if this is sufficient for the best performance, but in any case is easy to modify by changing a macro value in build.h. On a 2.4 GHz Intel Core2 with GNU C++ 4.3.3, I got these results: Algorithm 1.8.6 (MiB/s) 1.9.0 (MiB/s) Speedup Serpent/ECB 42.1 113.5 2.7 Serpent/CTR 39.7 100.8 2.5 AES-128/ECB 112.7 134.4 1.2 AES-128/CTR 99.1 114.1 1.15 The AES speedups nicely demonstrate that even without any explicit SIMD operations, the improved cache utilization can make a pretty big difference. I also experimented with performing 8 Serpent block operations in parallel, by interleaving two 4-wide SIMD encryptions. This reduced the number of key variable loads, as well as offering the processor much more in the way of independent computations for hot hot superscalar action. On my Core2, this pushed Serpent's performance north of 160 MiB/s in CTR mode, which is pretty impressive considering that is right about the speed of OpenSSL's AES-128 implementation on the same platform. However this variant seems slower on anything but a Core2; tests on an Opteron showed it to be somewhat slower than 4-way SIMD, and it is highly likely that it would also be much slower on 32-bit x86 processors due to excessive register pressure. AltiVec looks to be an even more promising platform for multiblock Serpent encryption, as it includes native rotation instructions, which in SSE2 must be emulated using two shifts and an OR. It is very likely the Cell processors SIMD units could also implement Serpent in a SIMD mode. Considering the Cell SPE contains 128 SIMD registers, it might even be feasible to implement a variant suggested by Wei Dai of encrypting 128 blocks in parallel without suffering an excessive number of register spills. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From rah at shipwright.com Thu Sep 10 07:33:31 2009 From: rah at shipwright.com (R.A. Hettinga) Date: Thu, 10 Sep 2009 07:33:31 -0400 Subject: Privacy Plug-In Fakes out Facebook References: <20090910094920.GQ9828@leitl.org> Message-ID: Begin forwarded message: From: Eugen Leitl Date: September 10, 2009 5:49:20 AM GMT-04:00 To: cypherpunks at al-qaeda.net, info at postbiota.org Subject: Privacy Plug-In Fakes out Facebook http://www.technologyreview.com/printer_friendly_article.aspx?id=23405&channel=web§ion= Wednesday, September 09, 2009 Privacy Plug-In Fakes out Facebook FaceCloak lets users hide sensitive updates from prying eyes, including Facebook's. By Robert Lemos Social networks are rife with examples of users failing to understand the privacy implications of posting sensitive information online. In February, for example, school officials in Wisconsin suspended a teacher who posted on Facebook a picture of herself pointing a gun at the camera. In April, the Swiss insurance company Nationale Suisse fired an employee after she called in sick and then posted updates on the same site. Others have raised concerns about users handing so much personal information to social-networking companies themselves. Now, researchers at the University of Waterloo in Ontario have developed a browser plug-in to help users keep their information private from prying eyes and from social-network providers as well. Urs Hengartner, an assistant professor of computer science, and his colleagues say the plug-in replaces sensitive information in a user's profile and news feed with meaningless text that can only be unscrambled by trusted friends or contacts. Dubbed FaceCloak, the tool assures its users that sensitive data stays private, Hengartner says. "If you have a particular illness, you might want to allow only your friends to see that," he says. "This leaves it up to the user to decide what information to keep away from Facebook." The tool is the latest shot in a battle between social networks and privacy-conscious users. Most users of Facebook, MySpace, and other social networks remain unaware of the privacy implications of posting personal information to such sites, says Alessandro Acquisti, an associate professor of information systems and public policy at Carnegie Mellon University. In 2005, Acquisti and fellow CMU researcher Ralph Gross showed that nearly 80 percent of Facebook users revealed their birthday publicly and the majority provided public access to their real-world addresses--information that could be used to commit identity theft. "You feel like you are talking to a friend casually in a conversation, but in reality you are publicizing information in a forum where it will stay for a long time," Acquisti says. "Privacy is not the first thing you think of when you use a social network." Nowadays more people appear to be privacy conscious. In a more recent study, Acquisti's group found that 30 to 40 percent of users change the default privacy settings to take greater control of their information. But social networks themselves have not been good protectors of privacy, Acquisti says, because monetizing personal information is a potential gold mine. This is demonstrated by Facebook's Beacon advertising service, which allows affiliates to tailor advertising according to users' activities on Facebook and beyond. FaceCloak, implemented as a plug-in for Mozilla's Firefox browser, allows a user to designate--using two "at" signs ("@@"), by default--what information should be encrypted and only made available to friends. A FaceCloak user holds a secret access key but also sends two other keys to her friends. Those keys are then used to access the real information, which is held on a separate server. While the same concept could be used on other social networks--such as Twitter and MySpace--Hengartner and his colleagues focused on the largest provider. Similar tools are being developed by other academic teams to address the privacy issues plaguing social networks. A group of researchers from Cornell University created another Firefox plug-in, called None of Your Business (NOYB), that encrypts profile information so that it can only be read by a small group of friends. And two researchers from the University of Illinois at Urbana-Champaign have developed a Facebook application called flyByNight that encrypts users' data. Unlike those projects, however, FaceCloak works with any number of contacts and does not rely on the cooperation of the social-network provider. The University of Waterloo researchers attempt to hide which users are encrypting their data with FaceCloak by replacing the hidden data with arbitrary text taken from sources on the Internet. "Users who submit encrypted information stand out, both to Facebook and to other users who can see the profiles, and therefore might raise suspicion," Hengartner says. "By using fake information, we can avoid this problem." There are still some major issues, however. Images are not yet supported by FaceCloak and the third-party hosting server used could potentially be compromised. Moreover, a FaceCloak user still has to be careful, Hengartner says. "The same problem arises in real life," he says. "When you tell a friend some personal information about you, you need to trust your friend to deal with this information responsibly. If she misbehaves, you can't erase the information from her brain." --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From rah at shipwright.com Thu Sep 10 07:52:25 2009 From: rah at shipwright.com (R.A. Hettinga) Date: Thu, 10 Sep 2009 07:52:25 -0400 Subject: Google Plans Tools to Help News Media Charge for Content Message-ID: <040C1D7F-89A8-48BB-A359-C176C7ACBB63@shipwright.com> Stands to reason. Google's in the advertisement microbilling business already. Turn it upside down and you get book-entry micropayments. Cheers, RAH ------- - Bits Blog - NYTimes.com SEPTEMBER 9, 2009, 8:51 PM Google Plans Tools to Help News Media Charge for Content By MIGUEL HELFT Update | 11:19 p.m. Added link to Nieman Journalism Lab, which first publicized the Google filing. Google is planning to roll out a system of micropayments within the next year and hopes that newspapers will use it as they look for new ways to charge users for their content. The revelation was made in a document that Google sent to the Newspaper Association of America in response to a request for paid- content proposals that the association sent to several technology companies. The Google document, which was first publicized by the Nieman Journalism Lab, indicates that the micropayment system will be an extension of Google Checkout, a payment system that Google rolled out in 2006 and positioned as a competitor to eBay?s PayPal service, the leading system for online payments. ?While currently in the early planning stages, micropayments will be a payment vehicle available to both Google and non-Google properties within the next year,? Google wrote. ?The idea is to allow viable payments of a penny to several dollars by aggregating purchases across merchants and over time.? Ten other companies responded to the association?s request, including Microsoft, I.B.M. and Oracle. But Google?s plans are particularly interesting because of the delicate relationship between the newspaper industry and the company. In the document, Google said that newspapers could also use Checkout to charge for subscriptions, but it described the system for managing the subscriptions as ?fairly rudimentary.? Newspapers have been grappling with an industrywide financial crisis that has devastated many dailies. The industry is trying to find new ways to earn revenue, and several publishers are evaluating ways to charge for content. Randy Bennett, senior vice president of business development for the industry association, said the request for proposals was made following a meeting of its members in May. He said it is now up to individual newspapers to decide whether to pursue relationships with any of the companies that submitted proposals. Google, which has long relied on advertising for the overwhelming majority of its revenue, said that it believed that paid content could be a good complement to advertising. ?While we believe that advertising will likely remain the main source of revenue for most news content, a paid model can serve as an important source of additional revenue. In addition, a successful paid content model can enhance advertising opportunities, rather than replace them,? the company wrote. The Google proposal, if it goes forward, could put the company in competition with Journalism Online, a venture backed by Steven Brill and L. Gordon Crovitz, which has recently said that it had tentatively signed more than 500 newspapers for its services. Those services include ?hybrid models for paid content.? Journalism Online is one of the companies that presented a proposal to the association. In a statement, Google said: The Newspaper Association of America asked Google to submit some ideas for how its members could use technology to generate more revenue from their digital content, and we shared some of those ideas in this proposal. It?s consistent with Google?s effort to help publishers reach bigger audiences, better engage their readers and make more money. We have always said that publishers have full control over their content. If they decide to charge for it, we?ll work with them to ensure that their content can be easily discovered if they want it to be. As for Checkout, we don?t have any specific new services to announce but we?re always looking for ways to make payments online more efficient and user-friendly. Google has been experimenting with new ways to highlight news content and new ways to display it. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From docbook.xml at gmail.com Thu Sep 10 11:55:03 2009 From: docbook.xml at gmail.com (Ali, Saqib) Date: Thu, 10 Sep 2009 08:55:03 -0700 Subject: Privacy Plug-In Fakes out Facebook In-Reply-To: References: <20090910094920.GQ9828@leitl.org> Message-ID: [Moderator's note: I don't want an extended discussion on this topic, but I'll allow this one message through. --Perry] Another fine example of throwing cryptography at a behavioral problem. And why should I trust a 3rd party server to protect the encryption keys???? I know that Facebook privacy settings were convoluted in the past. But they have improved a lot. And there are nice tutorials on privacy settings for facebook. Spend 10 mins, and properly configure these settings. Just my $0.02 saqib http://bit.ly/NISTCloudComputing --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Thu Sep 10 21:33:04 2009 From: perry at piermont.com (Perry E. Metzger) Date: Thu, 10 Sep 2009 21:33:04 -0400 Subject: UK Prime Minister apologizes for Alan Turing's mistreatment. Message-ID: <8763bq8dv3.fsf@snark.cb.piermont.com> Not strictly about crypto, but certainly about a very famous cryptanalyst. http://news.bbc.co.uk/2/hi/technology/8249792.stm Perry -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From cryptography at lt.gross.net Thu Sep 10 23:50:49 2009 From: cryptography at lt.gross.net (Stephan Somogyi) Date: Thu, 10 Sep 2009 20:50:49 -0700 Subject: UK Prime Minister apologizes for Alan Turing's mistreatment. In-Reply-To: <8763bq8dv3.fsf@snark.cb.piermont.com> References: <8763bq8dv3.fsf@snark.cb.piermont.com> Message-ID: At 21:33 -0400 10.09.2009, Perry E. Metzger wrote: >Not strictly about crypto, but certainly about a very famous cryptanalyst. > >http://news.bbc.co.uk/2/hi/technology/8249792.stm The actual statement is here: s. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From adam at homeport.org Thu Sep 10 22:17:26 2009 From: adam at homeport.org (Adam Shostack) Date: Thu, 10 Sep 2009 22:17:26 -0400 Subject: Privacy Plug-In Fakes out Facebook In-Reply-To: References: <20090910094920.GQ9828@leitl.org> Message-ID: <20090911021726.GE29525@homeport.org> Perry, If you'll let one more through, there's a related tool under development. See Enforcing Access Control in Social Network Sites Filipe Beato, Markulf Kohlweiss and Karel Wouters, HOTPETS 2009, http://www.cosic.esat.kuleuven.be/publications/article-1240.pdf No 3rd party, but you have to manage your keys. Adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From djm at mindrot.org Sun Sep 13 05:47:27 2009 From: djm at mindrot.org (Damien Miller) Date: Sun, 13 Sep 2009 19:47:27 +1000 (EST) Subject: RNG using AES CTR as encryption algorithm In-Reply-To: References: Message-ID: On Wed, 9 Sep 2009, Peter Gutmann wrote: > I was just going to reply with a variation of this, if you're implementing a > full protocol that uses AES-CTR (or any algorithm/mode for that matter), find > other implementations that do it too and make sure that you can talk to them. > In theory everyone could end up implementing it wrong, but that's somewhat > unlikely. > > (This has already caught AES-CTR implementation bugs in the past, for example > one particular version of OpenSSL 0.9.8 got AES-CTR keying wrong and it was > noticed when SSH users couldn't connect to OpenSSH servers using this mode). The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I don't think OpenSSL even supports a CTR mode through its EVP API. Any mistakes in implementing CTR mode in OpenSSH are therefore our own. -d --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Mon Sep 14 01:34:03 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Mon, 14 Sep 2009 17:34:03 +1200 Subject: RNG using AES CTR as encryption algorithm In-Reply-To: Message-ID: Damien Miller writes: >The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I >don't think OpenSSL even supports a CTR mode through its EVP API. I first saw it reported on the Putty bugs list [0], a good place to track interop problems with implementations since it's so widely used, which in turn points to https://bugzilla.mindrot.org/show_bug.cgi?id=1291: Connections from "OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006" to "OpenSSH_4.5p1, OpenSSL 0.9.8e 23 Feb 2007" using "aes256-ctr" fail with "Bad packet length". The same problem occurs when using PuTTY 0.59 against the newer server. PuTTY users have reported this problem too, with servers on both FreeBSD and Linux, and with OpenSSH versions back to 4.0. In fact it was listed as closed and resolved by, uh, one Damien Miller :-). Peter. [0] Meaing "bugs encountered while using Putty", not necessarily "bugs in Putty". --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From djm at mindrot.org Mon Sep 14 03:56:15 2009 From: djm at mindrot.org (Damien Miller) Date: Mon, 14 Sep 2009 17:56:15 +1000 (EST) Subject: RNG using AES CTR as encryption algorithm In-Reply-To: References: Message-ID: On Mon, 14 Sep 2009, Peter Gutmann wrote: > Damien Miller writes: > > >The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I > >don't think OpenSSL even supports a CTR mode through its EVP API. > > I first saw it reported on the Putty bugs list [0], a good place to track > interop problems with implementations since it's so widely used, which in turn > points to https://bugzilla.mindrot.org/show_bug.cgi?id=1291: Actually, I'm half-wrong (or half-right) - there was a bug in OpenSSL, just not in AES-CTR specifically. It was a mildly obscure bug in the EVP interface that showed up when plugging in one's own ciphers. We now have automated interop regression tests againt PuTTY to catch this sort of thing... -d --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From zooko at zooko.com Mon Sep 14 12:22:16 2009 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Mon, 14 Sep 2009 10:22:16 -0600 Subject: how to encrypt and integrity-check with only one key References: Message-ID: <93D8E0CD-C6B0-448B-A09C-9500590D2106@zooko.com> Folks: I had an idea about how to use a single key to accomplish both encryption and integrity checking on an immutable file. I posted it to the tahoe-dev list [1], and David-Sarah Hopwood followed up with an interesting new crypto cap design [2]. Here is the basic crypto trick, which may be useful in other contexts than Tahoe-LAFS. Suppose you have some data and you want to control who gets to see it, and you also want anyone who sees it to be able to verify its integrity. So far, these requirements are familiar to cryptographers. The obvious answer is to encrypt the data and then to MAC (Message Authentication Code) the ciphertext. There would be one key for the encryption and one key for the MAC. However, this has the wrong semantics for our purposes -- anyone who is given the ability to check the integrity (by being given the MAC key) is also given the ability to create new texts which would verify. Likewise, whoever creates the initial MAC tag can also create other MAC tags which would cause others files to also verify. Instead, we want a single file that can pass the integrity check, and nobody -- not a reader who is able to verify integrity nor even the writer who initially created the file -- is able to make a different file which would also pass the integrity check. Therefore, we want the integrity check value to be the secure hash of the file itself. That's what we currently have in Tahoe-LAFS. The immutable file read cap is a concatenation of two values: the decryption key and the secure hash. The latter is solely for integrity-checking. Actually in Tahoe-LAFS, the integrity check value is not just a flat hash of the plaintext, but instead it is the hash of the roots of a pair of Merkle Trees, one for verifying the correctness of the shares and the other for verifying the correctness of the ciphertext (see [3]). Now, convergent encryption could do both jobs with one value! If you let the symmetric key be the secure hash of the plaintext, then the reader could use the symmetric key to decrypt, then verify that the key was the hash of the plaintext. However, you can't always use convergent encryption. Not only because of the security issues [4], and not only because it requires two passes over the file which prevents "on-line" processing, but also because you might need to generate the symmetric key and/or the integrity check value in a different way. For example, the Tahoe-LAFS integrity-check value isn't just a secure hash of the plaintext. It would be inefficient to generate the full Tahoe-LAFS integrity check value before beginning to encrypt, and we want to be able to give someone the integrity check value (in a verify cap) without thus giving them the decryption key (i.e. the read cap). So here is my idea to use a single value to accomplish both decryption and integrity checking even when you can't set the symmetric key to be the secure hash of the plaintext. You use the encryption key K1 to encrypt the plaintext to produce the ciphertext, and in the same pass you compute the integrity-check value V. Then you compute the secure hash of the combination of K1 and V, let's call the result R = H(K1, V). Then you encrypt K1 using R and store the encrypted K1_enc with the ciphertext. Now R is the real key -- the read cap. If someone gives you R, the ciphertext, and the encrypted K1_enc, then you first use R to decrypt K1, check that R = H (K1, V), then perform the decryption and integrity-checking of the ciphertext. Here is a diagram: [5] (also attached). David-Sarah Hopwood suggested the improvement that the integrity- check value "V" could be computed as an integrity check (i.e. a secure hash) on the K1_enc in addition to the file contents. Regards, Zooko [1] http://allmydata.org/pipermail/tahoe-dev/2009-September/002796.html [2] http://allmydata.org/pipermail/tahoe-dev/2009-September/002848.html [3] http://allmydata.org/~zooko/lafs.pdf [4] http://hacktahoe.org/drew_perttula.html [5] http://zooko.com/imm-short-readcap-simple-drawing.svg -------------- next part -------------- A non-text attachment was scrubbed... Name: imm-short-readcap-simple-drawing.svg Type: application/octet-stream Size: 24312 bytes Desc: not available URL: From zooko at zooko.com Mon Sep 14 21:18:25 2009 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Mon, 14 Sep 2009 19:18:25 -0600 Subject: how to encrypt and integrity-check with only one key In-Reply-To: <93D8E0CD-C6B0-448B-A09C-9500590D2106@zooko.com> References: <93D8E0CD-C6B0-448B-A09C-9500590D2106@zooko.com> Message-ID: <96AF2A0D-CB1A-42B4-838B-A1DBB1147F43@zooko.com> following-up to my own post: On Monday,2009-09-14, at 10:22 , Zooko Wilcox-O'Hearn wrote: > David-Sarah Hopwood suggested the improvement that the integrity- > check value "V" could be computed as an integrity check (i.e. a > secure hash) on the K1_enc in addition to the file contents. Oops, that's impossible. What David-Sarah Hopwood actually said was that this would be nice if it were possible, but since it isn't then people should pass around the tuple of (v, K1_enc) whenever they want to verify the integrity of the ciphertext. http://allmydata.org/pipermail/tahoe-dev/2009-September/002798.html Regards, Zooko --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From david-sarah at jacaranda.org Tue Sep 15 00:03:59 2009 From: david-sarah at jacaranda.org (David-Sarah Hopwood) Date: Tue, 15 Sep 2009 05:03:59 +0100 Subject: how to encrypt and integrity-check with only one key In-Reply-To: <96AF2A0D-CB1A-42B4-838B-A1DBB1147F43@zooko.com> References: <93D8E0CD-C6B0-448B-A09C-9500590D2106@zooko.com> <96AF2A0D-CB1A-42B4-838B-A1DBB1147F43@zooko.com> Message-ID: <4AAF122F.2080000@jacaranda.org> Zooko Wilcox-O'Hearn wrote: > following-up to my own post: > > On Monday,2009-09-14, at 10:22 , Zooko Wilcox-O'Hearn wrote: > >> David-Sarah Hopwood suggested the improvement that the integrity-check >> value "V" could be computed as an integrity check (i.e. a secure hash) >> on the K1_enc in addition to the file contents. > > Oops, that's impossible. What David-Sarah Hopwood actually said was > that this would be nice if it were possible, but since it isn't then > people should pass around the tuple of (v, K1_enc) whenever they want to > verify the integrity of the ciphertext. > > http://allmydata.org/pipermail/tahoe-dev/2009-September/002798.html Zooko is referring to the argument after the first '-' in that post. Note that the argument after the second '-' was wrong; see the correction in . -- David-Sarah Hopwood ? http://davidsarah.livejournal.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Tue Sep 15 02:57:49 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Mon, 14 Sep 2009 23:57:49 -0700 Subject: Bringing Tahoe ideas to HTTP In-Reply-To: <4A970144.8020709@lothar.com> References: <4A970144.8020709@lothar.com> Message-ID: <27968C75-D2C5-43A8-B191-4AB1AFEBBF2C@solarsail.hcs.harvard.edu> On Aug 27, 2009, at 2:57 PM, Brian Warner wrote: > I've no idea how hard it would be to write this sort of plugin. But > I'm > pretty sure it's feasible, as would be the site-building tools. If > firefox had this built-in, and web authors used it, what sorts of > vulnerabilities would go away? What sorts of new applications could we > build that would take advantage of this kind of security? What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases. In the meantime, mobile device makers would track you down for the express purpose of breaking into your house at night to pee in your Cheerios, as retaliation for making them explain to their customers why their mobile web browsing is either half the speed it used to be, or not as secure as on the desktop, with no particularly explicable upside. It bugs the hell out of me when smart, technical people spend time and effort devising solutions in search of problems. You need to *start* with the sorts of vulnerabilities you want to do away with, or the kinds of new applications you can build that current security systems don't address, and *then* work your way to solutions that enable those use cases. It's okay to do it in reverse order in the academia, but you seem to be talking about real-world systems. And in real-world systems, you don't get to play Jeopardy with cryptography. Cheers, -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jamesd at echeque.com Tue Sep 15 19:12:37 2009 From: jamesd at echeque.com (James A. Donald) Date: Wed, 16 Sep 2009 09:12:37 +1000 Subject: Bringing Tahoe ideas to HTTP In-Reply-To: <27968C75-D2C5-43A8-B191-4AB1AFEBBF2C@solarsail.hcs.harvard.edu> References: <4A970144.8020709@lothar.com> <27968C75-D2C5-43A8-B191-4AB1AFEBBF2C@solarsail.hcs.harvard.edu> Message-ID: <4AB01F65.9010601@echeque.com> Ivan Krsti wrote: > What you're proposing amounts to a great deal of complex and complicated > cryptography. If it were implemented tomorrow, it would take years for > the most serious of implementation errors to get weeded out, and some > years thereafter for proper interoperability in corner cases. In the > meantime, mobile device makers would track you down for the express > purpose of breaking into your house at night to pee in your Cheerios, as > retaliation for making them explain to their customers why their mobile > web browsing is either half the speed it used to be, or not as secure as > on the desktop, with no particularly explicable upside. The ideas used in Tahoe are useful tools that can be used to solve important problems. It is true that just dumping them on end users and hoping that end users will use them correctly to solve important problems will fail It is our job to apply these tools, not the end user's job, the hard part being user interface architecture, rather than cryptography protocols. Yurls are one example of an idea for a user interface wrapping Tahoe like methods to solve useful problems. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From kevin.w.wall at gmail.com Tue Sep 15 20:27:22 2009 From: kevin.w.wall at gmail.com (Kevin W. Wall) Date: Tue, 15 Sep 2009 20:27:22 -0400 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI Message-ID: <4AB030EA.3080809@gmail.com> Hi all, I was referred to this site by a former colleague who thought this is something that someone with professional cryptanalysis experience should comment on. Also, I apologize in advance for the length of this post (especially since it's my first one). Just trying to be thorough. I have been working with Jeff Williams, Jim Manico and others on the OWASP ESAPI Java implementation (http://www.esapi.org). Work is underway for the 2.0 release. I am re-implementing the somewhat "broken" symmetric encryption / decryption mechanisms implemented in the earlier 1.x versions that only supported ECB cipher mode, restricted encryption and decryption operations to the use of a single encryption key, and used whatever the default padding scheme was for whatever JCE provider that happened to be used. As such, this is still very much a work in progress, but rather than risk fouling up encryption in the 2.0 release as well, I wanted to gather some input that we are on the right track. Since this work is for a free open source project (developed under the BSD license), I'm hoping that one of you on this list will take some time to address my questions. In OWASP ESAPI Java 2.0, I started out by deprecating the older methods that only supported ECB mode and used the provider's default padding scheme (which can vary, depending on JCE provider). The new default for the new encryption / decryption methods is to be 128-bit AES/CBC/PKCS5Padding and use of a random IV. (There is some thought on my part to not allow different cipher modes or padding schemes, but I go back and forth on this. (Certainly if someone tries to use something like OFB we'll at least probably long a warning that there's some chance that the same IV could be reused even though it is chosen randomly.) But for the remainder of this discussion, you can assume some suitably strong cipher algorithm and key size >= 128 bits with encryption using CBC cipher mode and PKCS5Padding. (Eventually we may allow others, but for now, that is probably sufficient and certainly a big improvement over only supporting ECB mode.) Based on experience at my day job, what I have found is when you try to decrypt something using PKCS5Padding using the wrong secret key, about 99.9% of the time you will get a BadPaddingException in Java and about the other .1% of the time you just get random garbage back for the plaintext. This is bad because if one is performing _manual_ key change operations (which many small IT shops using OWASP ESAPI will likely do for PCI DSS compliance reasons), then one could end up storing the resulting (incorrect) plaintext value and not discovering the error until much further downstream making and/or at a much later time. This makes the error very hard to troubleshoot as it typically will a long ways away in both code space and timeline away from the true root cause of the problem. I would like to be able to support such key change operations for ESAPI in a way that one has a much higher probability of detecting that decryptions using the incorrect secret key that do NOT result in a BadPaddingException have a much higher probability of being detected. Unfortunately, since this is generally reusable class library I can make no assumptions about the original plaintext. Specifically, it might not be text in the conventional sense at all, but rather it could be something like another random secret key that someone encrypted, etc. (key wrapping notwithstanding, but it is not currently supported in ESAPI 2.0). For ESAPI Java 2.0, I've created a serializable CipherText class that contains everything one generally needs to know to perform the decryption operation. That is, the CipherText object contains things like the the specification cipher transformation used to encrypt it, the IV used (unless ECB mode), and the raw ciphertext value as a byte array. My first thought was to also include a digital signature that was created along the lines one of these (note: here 'DSig(msg)' includes both the hashing and private key signature operations and probably would use DSA since it is not subject to any US export regulations): DSig( IV + secretKey ) // I explain below why IV is included or DSig( IV + plaintext ) // '+' is just the usual byte concatenation signed by the encrypter's private key. The decrypting side would then validate the digital signature using the encrypter's public key and only use the plaintext value if the digital signature was valid. If I were to do this, I might also add the encrypter's identity or alias as part of the CipherText class, although in most of the simple cases, it should be obvious based on from whom one is receiving the encrypted data. However, the main problem with using digital signatures is the performance hit. In my day job, I have made two observations involving encryption: 1) If you wish to ensure that application developers use solid algorithms such as AES, you must ensure that the encryption and decryption operations are sufficiently fast not to cause a bottleneck even when millions of encryptions are done. 2) Approximately 90+% of the encryption that occurs deals with the plaintext being very short (usually ASCII, occasionally EBCDIC) string data such as SSNs, CC#s, bank account information, etc. (This is driven by regulatory and compliance issues.) Because of these two observations I am concerned that the digital signature operation and its corresponding validation will had significant processing overhead relative to the actual encryption / decryption operations. Thus I'd prefer something lighter weight than digital signatures to accomplish more or less the same thing. I have considered using an HMAC-SHA1 as a keyless MIC to do this, using something like: MIC = HMAC-SHA1( nonce, IV + secretKey ) or MIC = HMAC-SHA1( nonce, IV + plaintext ) and then also include the random nonce and the MIC itself in the CipherText class so it can be validated later by the decrypter, with the understanding that the plaintext resulting from the decryption operation should only be used if the MIC can be properly validated. (Probably an exception would be thrown if the dsig was not valid so there would be no choice.) However, I am not a cryptanalyst so I am not sure how secure this is (if at all). My intuition tells me that it's not as good as using a DSig, but it should be significantly faster (or if not, rather than using an HMAC, alternatively just using something like SHA-256 and prepending the nonce to the rest). Note that I am now writing this ESAPI Java crypto code so that one has the choice of not doing these MIC calculations at all simply by setting a property in ESAPI.properties, but I have made to made the default to have it enabled to do this calculation in the encryption and validate it during the decryption. On why I included the IV in the MIC (or DSig) calculations... ============================================================= The ESAPI default will be to use a random IV appropriate for the cipher whenever that cipher mode requires an IV. Thus in the minimalist case, someone who needs to persist the ciphertext (say in a DB) will need to store the IV+ciphertext. There is a method on CipherText to return the base64-encoded IV+ciphertext byte array, like it is done in W3C's XML Encrypt specification. I added the random IV into the MIC (or DSig) calculation in part to add to the entropy and in part to be able to detect attempts of an adversary to change the IV to something of their liking. In the DSig case, it serves more or less as a nonce (with the assumption that because it's a ciphertext block size of random bytes it is unlikely to be repeated). It probably isn't as useful for a MIC calculation, but figured it couldn't hurt since byte concatenation is cheap. I had considered using something without the nonce like MIC = HMAC-SHA1( IV, plaintext ) but since I was already uneasy about using a MIC in the first place, I decided to do it the way shown above with an additional random nonce thinking I can ensure that the nonce is randomly chosen and sufficiently large (e.g., say 160-bits or longer, independent of the cipher algorithm's block size). The second reason I added the IV into the mix is because I figured that this would make it possible to detect an adversary tampering with the IV. (Well, it would for the DSig for sure; perhaps less so for the plaintext version of the MIC if it is possible for the adversary to do any type of chosen plaintext attack.) The reason that I want to be able to detect this is because I read somewhere in a paper by some cryptographer (maybe David Wagner, but am not sure) that there were some esoteric cryptographic attacks that could leak a few bits of the secret key or something if an adversary could get someone to attempt to decrypt some ciphertext using IVs that the adversary could manipulate. (I think maybe this had to do with IPSec but don't recall exactly as it's been several years ago.) But in a nutshell, I was hoping that including the IV would have the secondary benefit of preventing these types of attacks. [Note: Any references to papers referencing something like this would be appreciated.] So, having provided all of that background, in summary, here are my three questions: 1) Is using either of these MIC calculations cryptographically secure? 2) If answer to #1, is 'yes', which one is "safer" / more secure? 3) If answer to #1 is 'no', do you have any suggestions less computationally expensive then digital signatures that would allow us to detect attempts to decrypt with the incorrect secret key and/or an adversary attempting to alter the IV prior to the decryption. Thanks in advance to all who respond, -kevin-- Kevin W. Wall "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From daw at cs.berkeley.edu Wed Sep 16 12:52:46 2009 From: daw at cs.berkeley.edu (David Wagner) Date: Wed, 16 Sep 2009 09:52:46 -0700 (PDT) Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI Message-ID: <200909161652.n8GGqkn0016678@taverner.cs.berkeley.edu> Advice: if you're creating something for general-purpose use, at a minimum make sure it provides authentication, integrity, *and* confidentiality. A reasonable choice might be Encrypt-then-Authenticate where you first encrypt with AES-CBC, then append a AES-CMAC message authentication code on the ciphertext (including the IV). As a bonus, this will detect decrypting with the wrong key. Use key separation -- with a pseudorandom function -- to derive the encryption key and authentication key from the master crypto key supplied by the user: e.g., Encryptkey = AES(K, all-zeros), Authkey = AES(K, all-ones). (You could replace AES-CMAC with SHA1-HMAC, but why would you want to?) (From a cryptotheory point of view, what you want is a mode of operation that meets IND-CCA2 /\ INT-CTXT, or at least IND-CCA2 /\ INT-PTXT.) Advice: Provide one mode, and make it secure. Try to avoid configurability, because then someone will choose a poor configuration. Suggestion: Provide documentation to warn the programmer against using a password (or something based on a password) as the crypto key. Provide support for PBKDF2, with a reasonable default choice of parameters and appropriate warnings in the documentation, for those who absolutely must use a password-derived crypto key. Recommendation: Read the book Practical Cryptography by Ferguson and Schneier, or at least the chapters on message security. It's the best source I know to teach you some of the crypto-engineering practicum. Kevin W. Wall wrote: >I have considered using an HMAC-SHA1 as a keyless MIC to do this, >using something like: > > MIC = HMAC-SHA1( nonce, IV + secretKey ) >or > MIC = HMAC-SHA1( nonce, IV + plaintext ) > >and then also include the random nonce and the MIC itself in the CipherText >class so it can be validated later by the decrypter, with the understanding >that the plaintext resulting from the decryption operation should only be >used if the MIC can be properly validated. (Probably an exception would >be thrown if the dsig was not valid so there would be no choice.) I would not recommend either of these. It's better to use a MAC as I suggest at the top of this email. Whatever you do, don't choose your second MIC option: if the plaintext comes from a low-entropy space, it leaks the value of the plaintext (the plaintext can be recovered by brute-force search over all possible plaintexts). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Wed Sep 16 16:44:55 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Wed, 16 Sep 2009 13:44:55 -0700 Subject: Bringing Tahoe ideas to HTTP In-Reply-To: <4AB01F65.9010601@echeque.com> References: <4A970144.8020709@lothar.com> <27968C75-D2C5-43A8-B191-4AB1AFEBBF2C@solarsail.hcs.harvard.edu> <4AB01F65.9010601@echeque.com> Message-ID: On Sep 15, 2009, at 4:12 PM, James A. Donald wrote: > The ideas used in Tahoe are useful tools that can be used to solve > important problems. Yes, and I'd be happy to opine on that as soon as someone told me what those important problems are. -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From zooko at zooko.com Wed Sep 16 16:54:07 2009 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: Wed, 16 Sep 2009 14:54:07 -0600 Subject: [tahoe-dev] Bringing Tahoe ideas to HTTP In-Reply-To: References: <4A970144.8020709@lothar.com> <27968C75-D2C5-43A8-B191-4AB1AFEBBF2C@solarsail.hcs.harvard.edu> <4AB01F65.9010601@echeque.com> Message-ID: <74F062C2-FDC6-4077-BA47-310299DA6344@zooko.com> On Wednesday,2009-09-16, at 14:44 , Ivan Krsti? wrote: > Yes, and I'd be happy to opine on that as soon as someone told me > what those important problems are. The message that you quoted from Brian Warner, which ended with him wondering aloud what new applications could be enabled by such features, began with him mentioning a specific use case that he cares about and sees how to improve: authentication of Mozilla plugins. Brian has an admirable habit of documenting the use cases that motivate his engineering decisions. I think in this case he omitted some explanation of why he finds the current solution unsatisfactory, perhaps because he assumed the audience already shared his view. (I think he mentioned something in his letter like "the well-known failures of the SSL/CA approach to this problem".) Regards, Zooko --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ashwood at msn.com Wed Sep 16 19:11:22 2009 From: ashwood at msn.com (Joseph Ashwood) Date: Wed, 16 Sep 2009 16:11:22 -0700 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: <4AB030EA.3080809@gmail.com> References: <4AB030EA.3080809@gmail.com> Message-ID: -------------------------------------------------- From: "Kevin W. Wall" Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI > The new default for the new encryption / decryption methods is to be > 128-bit AES/CBC/PKCS5Padding and use of a random IV. That's a good solution, except for the missing MAC, considering the environment I would suggest hard coding it, there's really no reason to offer options. > MIC = HMAC-SHA1( nonce, IV + secretKey ) > or > MIC = HMAC-SHA1( nonce, IV + plaintext ) > MIC = HMAC-SHA1( IV, plaintext ) > So, having provided all of that background, in summary, here are my > three questions: > 1) Is using either of these MIC calculations cryptographically secure? > 2) If answer to #1, is 'yes', which one is "safer" / more secure? > 3) If answer to #1 is 'no', do you have any suggestions less > computationally expensive then digital signatures that would > allow us to detect attempts to decrypt with the incorrect secret > key and/or an adversary attempting to alter the IV prior to the > decryption. You are looking at the correct type of construct, the solution for your problem is known as a Message Authentication Code or MAC. The biggest concerns are what are you MACing, and that it must use a second key. There are a number of solutions. The first part of the solution is to store an additional key, you're storing 128-bits hopefully securely store 256, and split it, trust me you'll thank yourself when the security issues are investigated. The second key is for the MAC algorithm. Since you already have CBC available, my first suggestion would be CBC-MAC (IV = 0x0000000, okcs5 padding works fine, MAC = final block of ciphertext), it has good strong security proofs behind it, and is fast. Apply the MAC algorithm, prepend the MAC value to the plaintext (just because indexing is easier this way), then encrypt to ciphertext, store. To decrypt, retrieve, decrypt the ciphertext, parse out the MAC value and the plaintext, run MAC algorithm on plaintext to find MAC2, check MAC == MAC2 . This will give you a failure rate of 1/2^128 or something on the order of 0.0000000000000000000000000000000000003%, you are more likely to have the system burst into flame than see a false positive on this. Overall, this will reduce your speed to 50% of the current. You might also want to take a look at Poly1305, it is faster. As you noted HMAC is also available, but I would recommend against using SHA-1 for anything, it simply raises too many questions that will take too long to answer. The secure hashes available are simply not as fast unless you have bare-metal coding ability which Java really doesn't like. The other, and arguably better, option would be a combined mode. The good combined modes are a legal minefield, so using them for an open project is difficult. It is claimed that GCM and EAX are public domain, but I'm more inclined to recommend the conservative approach and avoid them. While there has been no concern raised by cryptanalysts about CBC with CBC-MAC, to many laypeople it doesn't look good. So, for purely politic reasons, I'm recommending the shift to CCM mode. At the same time I recommend moving to an IV counter instead of random IV, in CTR mode it is necessary to make sure an IV is never reused and randomness is irrelevant. This will give you a thoroughly analyzed standard mode of operation. Joe --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From daw at cs.berkeley.edu Wed Sep 16 20:19:53 2009 From: daw at cs.berkeley.edu (David Wagner) Date: Wed, 16 Sep 2009 17:19:53 -0700 (PDT) Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI Message-ID: <200909170019.n8H0JrGH022110@taverner.cs.berkeley.edu> I don't exactly follow the argument for using CCM mode instead AES-CBC encryption followed by AES-CMAC, and I'm not familiar with the political/perception arguments (who complains about the latter?), but whatever. It's hardly worth arguing over. The cryptographic mode of operation is unlikely to be the weakest link in your system, and the security differences between CCM mode vs AES-CBC + AES-CMAC seem minor, so it doesn't seem worth worrying too much about it: CCM mode seems good enough. I'm not sure I'm familiar with the arguments against EAX mode (full disclosure: I'm a co-author on the EAX paper and hence probably biased), but again, whatever. These three choices are all good enough and the security differences between them seem minor. In my view, choosing any of the three would be a reasonable choice. Just my personal opinion. ObNitpick: Joseph Ashwood wrote: > Since you already have CBC available, my first suggestion would be CBC-MAC > (IV = 0x0000000, okcs5 padding works fine, MAC = final block of ciphertext), > it has good strong security proofs behind it, and is fast. [...] Are you sure? For vanilla CBC-MAC, the security proofs don't apply to variable-length messages, and I recall that there are known attacks on vanilla CBC-MAC when message lengths can vary (I'm not claiming those attacks are necessarily realistic in all applications, but they may be). AES-CMAC is a nice design that addresses this problem. CMAC is based upon CBC-MAC, but addresses the imperfections of vanilla CBC-MAC. Personally, I wouldn't recommend vanilla CBC-MAC as a choice of message authentication primitive; CMAC seems better in every dimension. CMAC is basically a CBC-MAC, but with all the details done right. CMAC also has the benefit that it has been standardized by NIST. http://en.wikipedia.org/wiki/CMAC http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf Bottom line: If you're going to use a standalone CBC-based MAC together with a standalone encryption algorithm, I'd recommend using CMAC as your message authentication code, not AES-CBC. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ashwood at msn.com Wed Sep 16 21:13:29 2009 From: ashwood at msn.com (Joseph Ashwood) Date: Wed, 16 Sep 2009 18:13:29 -0700 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: <200909170019.n8H0JrGH022110@taverner.cs.berkeley.edu> References: <200909170019.n8H0JrGH022110@taverner.cs.berkeley.edu> Message-ID: -------------------------------------------------- From: "David Wagner" Sent: Wednesday, September 16, 2009 5:19 PM To: Subject: Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI > I don't exactly follow the argument for using CCM mode instead > AES-CBC encryption followed by AES-CMAC, and I'm not familiar with > the political/perception arguments (who complains about the latter?), > but whatever. I've actually had a few clients ask for a more detailed explaination of why it is ok, so there are people who are confused. Some people get confused. > It's hardly worth arguing over. The cryptographic mode > of operation is unlikely to be the weakest link in your system, and the > security differences between CCM mode vs AES-CBC + AES-CMAC seem minor, > so it doesn't seem worth worrying too much about it: CCM mode seems good > enough. I'm not sure I'm familiar with the arguments against EAX mode > (full disclosure: I'm a co-author on the EAX paper and hence probably > biased), but again, whatever. Actually I think EAX great, and if I had known you were replying while I was writing mine I wouldn't have replied at all. My problem is that I haven't taken the time to look over the patents on bordering technologies to see if I believe it is patent safe. Lately, I've been dealing with a lot of patent weirdness, so I'm more aware of patent issues. > ObNitpick: > > Joseph Ashwood wrote: >> Since you already have CBC available, my first suggestion would be >> CBC-MAC >> (IV = 0x0000000, okcs5 padding works fine, MAC = final block of >> ciphertext), >> it has good strong security proofs behind it, and is fast. [...] > > Are you sure? For vanilla CBC-MAC, the security proofs don't apply to > variable-length messages, and I recall that there are known attacks on > vanilla CBC-MAC when message lengths can vary (I'm not claiming those > attacks are necessarily realistic in all applications, but they may be). > AES-CMAC is a nice design that addresses this problem. CMAC is based > upon CBC-MAC, but addresses the imperfections of vanilla CBC-MAC. I could try and justify my position, but honestly, CMAC really doesn't any real downsides, and the proof is tighter. (I moved this down here) > These three choices are all good enough and > the security differences between them seem minor. In my view, choosing > any of the three would be a reasonable choice. Just my personal opinion. As opinions go, its hard to find a better source than David Wagner. Joe BTW: Anyone looking to make a venture capital investment? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Wed Sep 16 21:20:45 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 17 Sep 2009 13:20:45 +1200 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: <200909161652.n8GGqkn0016678@taverner.cs.berkeley.edu> Message-ID: David Wagner writes: >(You could replace AES-CMAC with SHA1-HMAC, but why would you want to?) The answer to that depends on whether you need to support an existing base of crypto software and hardware. Even though (in this case) it's a new standard, it still requires support from the underlying crypto libraries. If little or none of those do AES-CMAC yet (I don't think Windows CryptoAPI does, only very recent versions of OpenSSL do... it's not looking good) then you'd want to stick with HMAC-SHA1. (Forestalling the inevitable "but developers can implement AES-CMAC themselves from raw AES" that I'm sure someone will follow up with, the target audience for this is web application developers, not cryptographers, so you need to give them something that works as required out of the box). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From kevin.w.wall at gmail.com Wed Sep 16 19:29:11 2009 From: kevin.w.wall at gmail.com (Kevin W. Wall) Date: Wed, 16 Sep 2009 19:29:11 -0400 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: References: Message-ID: <4AB174C7.7060901@gmail.com> Peter Gutmann wrote: > David Wagner writes: > >> (You could replace AES-CMAC with SHA1-HMAC, but why would you want to?) > > The answer to that depends on whether you need to support an existing base of > crypto software and hardware. Even though (in this case) it's a new standard, > it still requires support from the underlying crypto libraries. If little or > none of those do AES-CMAC yet (I don't think Windows CryptoAPI does, only very > recent versions of OpenSSL do... it's not looking good) then you'd want to > stick with HMAC-SHA1. > > (Forestalling the inevitable "but developers can implement AES-CMAC themselves > from raw AES" that I'm sure someone will follow up with, the target audience > for this is web application developers, not cryptographers, so you need to > give them something that works as required out of the box). Peter has hit the proverbial nail right on the head. I apologize if I did not make this clear in my original post, but but one goal of OWASP ESAPI is to not require a whole lot of dependencies. In the context of Java crypto, this means that we *ideally* would like to have no other dependency other than the SunJCE, that is, the Sun reference implementation for JCE. Recently we decided to required Java 6, but even with that, our choices for cipher algorithms, cipher modes, and padding schemes are limited. For SunJCE, this is what we have available to choose from: Supported symmetric cipher algorithms: AES, DES, DESede, Blowfish, RC2, ARCFOUR Supported cipher modes: CBC, CFB, CTR, CTS, ECB, OFB, PCBC Supported padding schemes: NoPadding, PKCS5Padding ISO10126Padding OAEPPadding, OAEPWithAndPadding PKCS1Padding, SSL3Padding (Obviously some of these padding schemes such as OAEP are not suitable with symmetric ciphers. Or at least I don't think they are.) So given these limited choices, what are the best options to the questions I posed in my original post yesterday? As Peter mentioned, we want to give web app developers something that will work out-of-the-box. For that reason we don't even want to require that developers use some other JCE provider like Bouncy Castle, Cryptix, IAIK, etc. even though they may have more suitable cipher modes or padding schemes. Lastly, I wanted to respond to one other point that David Wagner brought up in an earlier reply: > Advice: Provide one mode, and make it secure. Try to avoid > configurability, because then someone will choose a poor configuration. There's a few reasons for supporting different configurations here. One is the backward compatibility with previous ESAPI versions, and the second is to support legacy cases. My experience at my day job is that no one really changes the crypto defaults anyway if you make it easy enough for them to use. The main exception is if they have to be compatible with something else such as some 3rd party vendor software that uses a different mode, etc. What we can try to do is provide adequate warning in documentation or in logged warnings if one tries to use anything other then the default. BTW, thanks to all who replied. I've learned quite a bit from all your responses, but it looks like I have a lot of research to do before I understand everything that all of you said. Regards, -kevin -- Kevin W. Wall "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Thu Sep 17 01:20:33 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 17 Sep 2009 17:20:33 +1200 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: <4AB174C7.7060901@gmail.com> Message-ID: "Kevin W. Wall" writes: >(Obviously some of these padding schemes such as OAEP are not suitable with >symmetric ciphers. Or at least I don't think they are.) You'd be surprised at what JCE developers will implement just because they can, and what therefore gets used by application developers. I've seen RSA-CBC used on more than one occasion. (No, that's not a typo, RSA in CBC mode. The app developers wondered why it was so slow). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From adulau at gmail.com Thu Sep 17 01:45:06 2009 From: adulau at gmail.com (Alexandre Dulaunoy) Date: Thu, 17 Sep 2009 07:45:06 +0200 Subject: Bringing Tahoe ideas to HTTP In-Reply-To: <1baa801f0909162239u68d458c0s8529d5f8f9d02afa@mail.gmail.com> References: <4A970144.8020709@lothar.com> <1baa801f0909162239u68d458c0s8529d5f8f9d02afa@mail.gmail.com> Message-ID: <1baa801f0909162245g291f5cdaia828823e6cf49df1@mail.gmail.com> On Thu, Aug 27, 2009 at 11:57 PM, Brian Warner wrote: > == Integrity == > > To start with integrity-checking, we could imagine a firefox plugin that > validated a PyPI-style #md5= annotation on everything it loads. The rule > would be that no action would be taken on the downloaded content until > the hash was verified, and that a hash failure would be treated like a > 404. Or maybe a slightly different error code, to indicate that the > correct resource is unavailable and that it's a server-side problem, but > it's because you got the wrong version of the document, rather than the > document being missing altogether. On the same idea, there is an expired Internet-Draft called "Link Fingerprints" : http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/ I made some experiments around while used as Machine Tag/Triple Tag[1] : http://www.foo.be/cgi-bin/wiki.pl/MachineTagLinkFingerprint to have an extension with OpenPGP detached signature. Another potential use, it's to benefit from the number of users checking the integrity and contribute back the computed value into a "tagging" system like del.icio.us or any other collaborative bookmarking. I especially like the Firefox (or wget,curl) extension that could compute the hash value and check it against various contributed hashes. That could give a kind of confidence level regarding the integrity of the file and its corresponding URL/URI. Just some ideas, adulau [1] http://www.foo.be/cgi-bin/wiki.pl/MachineTag -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From warner at lothar.com Thu Sep 17 04:23:11 2009 From: warner at lothar.com (Brian Warner) Date: Thu, 17 Sep 2009 01:23:11 -0700 Subject: [tahoe-dev] Bringing Tahoe ideas to HTTP In-Reply-To: <74F062C2-FDC6-4077-BA47-310299DA6344@zooko.com> References: <4A970144.8020709@lothar.com> <27968C75-D2C5-43A8-B191-4AB1AFEBBF2C@solarsail.hcs.harvard.edu> <4AB01F65.9010601@echeque.com> <74F062C2-FDC6-4077-BA47-310299DA6344@zooko.com> Message-ID: <4AB1F1EF.5010909@lothar.com> Zooko Wilcox-O'Hearn wrote: > began with him mentioning a specific use case that he cares about and > sees how to improve: authentication of Mozilla plugins. To be specific, the itch that I was looking to scratch was the authentication of Firefox updates. In some slides from the last BlackHat, I was dismayed to learn that the firefox update process depends utterly upon SSL and the assorted Certificate Authorities to validate https URLs that land on a mozilla.org server. The actual update bundles that are fetched from those https URLs are not validated at all. This causes two problems. The first is that any failure of the SSL or CA path will allow an attacker to subvert the update process and take over the browser. The slides I looked through showed one easy attack (the ASN.1 pascal-vs-C-string bug) which has since been fixed. But we've seen lots of failures at this level, and there are dozens of CAs in the TCB: a compromise of any one of them would break everything (some are still using MD5). Since firefox checks in daily to find out about new updates, there are lots of opportunities to mount this attack. The second is that it limits Mozilla's mirroring possibilities. I think that they currently have to hand out private keys to their mirrors, something like a cert that designates the server as mirror1.mozilla.org, so they must be very cautious about who runs each mirror. Their mirrors must all be running SSL, and a compromise of any of those mirrors could jeopardize the whole update path. I think that they could have far more mirrors (and be better able to accomodate the tens of millions of firefox users) if they didn't have this limitation. Having an end-to-end method to validate the update bundles would fix both of these problems. Updates could even be acquired via other means (sneakernet, local mirror, etc) and validated by the browser individually before unpacking+installation. Plugins could conceivably used something similar, but I think the basic browser update path is a valuable one that's easier to reason about. >From what I can tell, the Sparkle update framework (for OS-X)[1] is doing something like what I want for firefox: the Sparkle-enabled application will only accept update bundles which are signed by a DSA privkey that matches a pubkey embedded in the app. It'd be nice if Firefox could do the same. And if Firefox were to establish a quietly-backwards-compatible convention (i.e. the hash-mark trick) for strong URL-based authentication of HTTP resources, then other applications could start using it too, and a significant class of current web security problems (like the mixed-content one where an HTTPS page loads a javascript library via HTTP) could be fixed. cheers, -Brian [1]: http://sparkle.andymatuschak.org/documentation/pmwiki.php/Documentation/BasicSetup --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jim.windle at gmail.com Thu Sep 17 09:31:41 2009 From: jim.windle at gmail.com (Jim Windle) Date: Thu, 17 Sep 2009 09:31:41 -0400 Subject: Biotech Based "Cryptogram Challenge" Message-ID: <1932e3120909170631v52eba03dkb640d681026499d@mail.gmail.com> http://www.genengnews.com/cryptogramchallenge/ This is contest to decode the message encrypted in the colors of a 96 well microtiter plate used for an enzyme-linked immunosorbent assay test in which the color indicate the amount of antigen present. The first to decode it gets a $1500 prize. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From daw at cs.berkeley.edu Thu Sep 17 15:42:26 2009 From: daw at cs.berkeley.edu (David Wagner) Date: Thu, 17 Sep 2009 12:42:26 -0700 (PDT) Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI Message-ID: <200909171942.n8HJgQxX001614@taverner.cs.berkeley.edu> Kevin W. Wall wrote: > So given these limited choices, what are the best options to the > questions I posed in my original post yesterday? Given these choices, I'd suggest that you first encrypt with AES-CBC mode. Then apply a message authentication code (MAC) to the whole ciphertext (including the IV). You then send the ciphertext followed the MAC digest. SHA1-HMAC would be a reasonable choice of algorithm for message authentication. Sun's JCA appears to support SHA1-HMAC. http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#Mac http://java.sun.com/javase/6/docs/technotes/guides/security/StandardNames.html#Mac You'll want to use key separation to derive two separate keys. So if the key K is the master key, you could use Kenc = SHA1-HMAC(K, "encrypt") Kauth = SHA1-HMAC(K, "authenticate") or you could use Kenc = AES-ECB(K, all-zeros) Kauth = AES-ECB(K, all-ones) (Either is fine.) Then use Kenc as the crypto key for AES-CBC encryption and Kauth as the crypto key for SHA1-HMAC authentication. If you are encrypting messages that will be sent over a two-way channel, you'll probably want to either use a different crypto key for each direction or include a direction bit in the inputs to the key separation step. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jon at callas.org Thu Sep 17 18:14:35 2009 From: jon at callas.org (Jon Callas) Date: Thu, 17 Sep 2009 15:14:35 -0700 Subject: Biotech Based "Cryptogram Challenge" In-Reply-To: <1932e3120909170631v52eba03dkb640d681026499d@mail.gmail.com> References: <1932e3120909170631v52eba03dkb640d681026499d@mail.gmail.com> Message-ID: <26EBA483-B701-48C6-AC8C-4FB8D55FEF90@callas.org> On Sep 17, 2009, at 6:31 AM, Jim Windle wrote: > http://www.genengnews.com/cryptogramchallenge/ > > This is contest to decode the message encrypted in the colors of a > 96 well > microtiter plate used for an enzyme-linked immunosorbent assay test > in which > the color indicate the amount of antigen present. The first to > decode it > gets a $1500 prize. Yes, but it has nothing to do with biotech at all, except in the presentation. The instructions say that the plaintext is represented in the RGB values of each cell, along with the transparency (alpha) of each color blob. So each character is represented (wolog, since we don't know how deep the alpha channel is) by an integer value of ABGR of each color blob. Cute, but not biotech. Jon --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Thu Sep 17 20:35:45 2009 From: leichter at lrw.com (Jerry Leichter) Date: Thu, 17 Sep 2009 20:35:45 -0400 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: References: Message-ID: On Sep 17, 2009, at 1:20 AM, Peter Gutmann wrote: > "Kevin W. Wall" writes: > >> (Obviously some of these padding schemes such as OAEP are not >> suitable with >> symmetric ciphers. Or at least I don't think they are.) > > You'd be surprised at what JCE developers will implement just > because they > can, and what therefore gets used by application developers. I've > seen > RSA-CBC used on more than one occasion. > > (No, that's not a typo, RSA in CBC mode. The app developers > wondered why it > was so slow). Interesting. It sounds as if the JCE developers have gone from one extreme to another. I no longer remember the details, but a number of years back, in a project I was involved with, we needed to implement some particular (sane) combination of a cipher and a mode. JCE at the time had a fixed list of combinations it was willing to let you use; ours wasn't on that list. "ECB" wasn't an accepted mode, so it wasn't easy to build your own mode out of what the API provided. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Fri Sep 18 00:27:04 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 18 Sep 2009 16:27:04 +1200 Subject: Bringing Tahoe ideas to HTTP In-Reply-To: <1baa801f0909162245g291f5cdaia828823e6cf49df1@mail.gmail.com> Message-ID: Alexandre Dulaunoy writes: >On the same idea, there is an expired Internet-Draft called "Link >Fingerprints" : >http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/ Although the draft has expired, the concept lives on in various tools. For example DownThemAll for Firefox supports this. There was some discussion about including it into FF3, but then the draft was dropped and the FF support never appeared, does anyone know what happened? (The cynic in me would say "it's such a simple, straightforward, easy-to- implement idea, of course it'll never be adopted when there are things like EV certs to be pushed instead", but who knows...). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Fri Sep 18 00:36:41 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Fri, 18 Sep 2009 16:36:41 +1200 Subject: [tahoe-dev] Bringing Tahoe ideas to HTTP In-Reply-To: <4AB1F1EF.5010909@lothar.com> Message-ID: Brian Warner writes: >From what I can tell, the Sparkle update framework (for OS-X)[1] is doing >something like what I want for firefox: the Sparkle-enabled application will >only accept update bundles which are signed by a DSA privkey that matches a >pubkey embedded in the app. You can extend this further to make it tolerant of key loss by embedding multiple public keys and allowing a quorum of them to replace an existing key. So say you have five keys, you can decide that any three of them can vote out an existing key, allowing compromised keys to be replaced and existing keys to be rolled over. This creates a kind of fault-tolerant PKI which does away with the need to have a CA vouch for key replacements, once you've got the initial keys established (for example on first install) you can recover from anything short of a total compromise, upgrade to larger keys sizes and hashes, and so on. >It'd be nice if Firefox could do the same. And if Firefox were to establish a >quietly-backwards-compatible convention (i.e. the hash-mark trick) for strong >URL-based authentication of HTTP resources, then other applications could >start using it too, and a significant class of current web security problems >(like the mixed-content one where an HTTPS page loads a javascript library via >HTTP) could be fixed. See my previous post, there was an attempt made to do this in the past but it never got anywhere. It'd be interesting to hear the reasons why. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From ashwood at msn.com Fri Sep 18 03:17:33 2009 From: ashwood at msn.com (Joseph Ashwood) Date: Fri, 18 Sep 2009 00:17:33 -0700 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: <4AB174C7.7060901@gmail.com> References: <4AB174C7.7060901@gmail.com> Message-ID: -------------------------------------------------- From: "Kevin W. Wall" Subject: Re: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI > So given these limited choices, what are the best options to the > questions I posed in my original post yesterday? As Peter mentioned, we > want to give web app developers something that will work out-of-the-box. It isn't difficult to implement CMAC and CTR modes in pure Java. The NIST specs for CMAC and CTR are plenty clear. You'll be looking for the AES/ECB/NoPadding option. From there use update it returns a byte []. I've used the standard JCE implementation in this way to implement unsupported modes before, it works. Joe --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From adulau at gmail.com Fri Sep 18 03:35:58 2009 From: adulau at gmail.com (Alexandre Dulaunoy) Date: Fri, 18 Sep 2009 09:35:58 +0200 Subject: Bringing Tahoe ideas to HTTP In-Reply-To: References: <1baa801f0909162245g291f5cdaia828823e6cf49df1@mail.gmail.com> Message-ID: <1baa801f0909180035t4936fd8br35ef55e0503e1e29@mail.gmail.com> On Fri, Sep 18, 2009 at 6:27 AM, Peter Gutmann wrote: > Although the draft has expired, the concept lives on in various tools. ?For > example DownThemAll for Firefox supports this. ?There was some discussion > about including it into FF3, but then the draft was dropped and the FF support > never appeared, does anyone know what happened? It was a SoC project within Mozilla but seeing the following discussion : https://bugzilla.mozilla.org/show_bug.cgi?id=377245 The state looks a bit unclear to me... > (The cynic in me would say "it's such a simple, straightforward, easy-to- > implement idea, of course it'll never be adopted when there are things like EV > certs to be pushed instead", but who knows...). Right... When I see the EV audit process[1], it looks to me like PCI DSS without the technical aspect... [1] http://cabforum.org/WebTrustAuditGuidelines.pdf -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- "Knowledge can create problems, it is not through ignorance -- that we can solve them" Isaac Asimov --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From alec.muffett at gmail.com Fri Sep 18 05:32:20 2009 From: alec.muffett at gmail.com (Alec Muffett) Date: Fri, 18 Sep 2009 10:32:20 +0100 Subject: From Ivory Tower to Iron Bars: Scientists Risk Jail Time for Violating Export Laws Message-ID: <336B0ECE-6EA6-431E-9A61-FD24B200921C@gmail.com> Perry: plasma physics is wildly OT but I believe the relevance will be obvious to those who remember the crypto wars, especially when they hit the fifth paragraph: > It?s a difficult subject: many people I interviewed felt Roth showed > blatant disregard for the law ? he was warned his work fell under > the State Department?s munitions list ? but they expressed deep > frustration with the ambiguity of the laws. > http://www.wired.com/dangerroom/2009/09/from-ivory-tower-to-iron-bars-academics-risk-jail-time-for-violating-export-laws/ short: http://is.gd/3pd0d "There but for the grace of Bernstein?" Or something like that... :-) -a --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From iang at systemics.com Fri Sep 18 08:36:32 2009 From: iang at systemics.com (Ian G) Date: Fri, 18 Sep 2009 14:36:32 +0200 Subject: Detecting attempts to decrypt with incorrect secret key in OWASP ESAPI In-Reply-To: <200909171942.n8HJgQxX001614@taverner.cs.berkeley.edu> References: <200909171942.n8HJgQxX001614@taverner.cs.berkeley.edu> Message-ID: <4AB37ED0.8030008@systemics.com> On 17/09/2009 21:42, David Wagner wrote: > Kevin W. Wall wrote: >> So given these limited choices, what are the best options to the >> questions I posed in my original post yesterday? > > Given these choices, I'd suggest that you first encrypt with AES-CBC mode. > Then apply a message authentication code (MAC) to the whole ciphertext > (including the IV). You then send the ciphertext followed the MAC digest. > > SHA1-HMAC would be a reasonable choice of algorithm for message > authentication. I have to add vote+1 on this selection. For various reasons, today's safe choice seems to be: * CBC * AES-128 * HMAC-SHA-1 on the outside of the ciphertext What is left is padding so that the message is clearly deliminated. I suggest you treat this as a software engineering thing, not a crypto thing, and make sure that you have a length in your packet layout so that it is totally clear what is the packet and what is not. If you want to see such a design exercise, following Dave's prescription, have a look at SDP1 which Zooko and I did a few years back. http://www.webfunds.org/guide/sdp/sdp1.html http://www.webfunds.org/guide/sdp/ It's a straight forward secret-key encrypted packet layout. It has one novelty in it, which is how it solves the padding / IV issues. Other than that it should be boring. iang PS: you are on the right track in trying to avoid any sensitivity to JCE. As long as you can design your layout without any dependency on JCE it should work. JCE is basically a slock design that was put in place for market- and crypto-control reasons, it has no place in software engineering. I speak from experience, I managed the Cryptix project, which was the first Java crypto engine. PPS: you haven't said enough about the application (or I missed it) to be able to comment on keys. Generally, try to separate the protocol around the key: every good protocol divides into two parts, the first of which says to the second, "trust this key completely". Software engineering ... http://iang.org/ssl/h2_divide_and_conquer.html --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From demonfighter at gmail.com Fri Sep 18 11:56:44 2009 From: demonfighter at gmail.com (Steve Furlong) Date: Fri, 18 Sep 2009 10:56:44 -0500 Subject: From Ivory Tower to Iron Bars: Scientists Risk Jail Time for Violating Export Laws In-Reply-To: <336B0ECE-6EA6-431E-9A61-FD24B200921C@gmail.com> References: <336B0ECE-6EA6-431E-9A61-FD24B200921C@gmail.com> Message-ID: <7d752ae30909180856v6eee6f51l60c012e4c65a814c@mail.gmail.com> On Fri, Sep 18, 2009 at 4:32 AM, Alec Muffett wrote: > Perry: plasma physics is wildly OT but I believe the relevance will be > obvious to those who remember the crypto wars, especially when they hit the > fifth paragraph: >> >> It?s a difficult subject: many people I interviewed felt Roth showed >> blatant disregard for the law ? he was warned his work fell under the State >> Department?s munitions list ? but they expressed deep frustration with the >> ambiguity of the laws. Hypothetically, if I were to write an open source library or application involving crypto, I'd send the source and docn through an anonymizing remailer to someone overseas who could then put it on appropriate websites. Or I'd go through a web anonymizer and post on appropriate sites myself. Time was, hypothetically, that I'd anonymously put source on alt.* Usenet groups, but they're dead in the US. Even with relaxed interpretation of the crypto export laws, anyone in the US would be a fool to rely on that interpretation. Never never never put your name on publicly available crypto unless you've jumped through all the hoops written into the law. (And I wouldn't do so even then.) Regards, SRF -- Neca eos omnes. Deus suos agnoscet. -- Arnaud-Amaury, 1209 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Mon Sep 21 16:57:56 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 21 Sep 2009 16:57:56 -0400 Subject: FileVault on other than home directories on MacOS? Message-ID: Is there any way to use FileVault on MacOS except on home directories? I don't much want to use it on my home directory; it doesn't play well with Time Machine (remember that availability is also a security property); besides, different directories of mine have different sensitivity levels. I suppose I could install TrueCrypt (other suggestions or comments on TrueVault?), but I prefer to minimize the amount of extra software I have to maintain. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From crypto at ashish.neomailbox.com Mon Sep 21 20:14:49 2009 From: crypto at ashish.neomailbox.com (Ashish Gulhati) Date: Tue, 22 Sep 2009 10:14:49 +1000 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: Message-ID: <20090922001501.309F2E9826@green.metzdowd.com> On Sep 22, 2009, at 6:57 AM, Steven Bellovin wrote: > Is there any way to use FileVault on MacOS except on home > directories? I don't much want to use it on my home directory; it > doesn't play well with Time Machine (remember that availability is > also a security property); besides, different directories of mine > have different sensitivity levels. > > I suppose I could install TrueCrypt (other suggestions or comments > on TrueVault?), but I prefer to minimize the amount of extra > software I have to maintain. Hi Steven You can just use encrypted disk images, which is IIRC what FileVault uses. In Disk Utility -> New Image, select size, properties and encryption type (AES 128 or 256) and Create. Then mount and use your encrypted disks as needed. Cheers --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From cryptography23094893 at aquick.org Mon Sep 21 20:29:18 2009 From: cryptography23094893 at aquick.org (Adam Fields) Date: Mon, 21 Sep 2009 20:29:18 -0400 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: Message-ID: <20090922002918.GU25273@lola.aquick.org> On Mon, Sep 21, 2009 at 04:57:56PM -0400, Steven Bellovin wrote: > Is there any way to use FileVault on MacOS except on home > directories? I don't much want to use it on my home directory; it > doesn't play well with Time Machine (remember that availability is > also a security property); besides, different directories of mine have > different sensitivity levels. > > I suppose I could install TrueCrypt (other suggestions or comments on > TrueVault?), but I prefer to minimize the amount of extra software I > have to maintain. You can just create a regular encrypted disk image using Disk Utility (and set it to auto-mount using Finder if you want). - Adam -- ** I design intricate-yet-elegant processes for user and machine problems. ** Custom development project broken? Contact me, I can help. ** Some of what I do: http://workstuff.tumblr.com/post/70505118/aboutworkstuff [ http://workstuff.tumblr.com ] ........... Technology Blog [ http://www.aquick.org/blog ] ............ Personal Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.twitter.com/fields ].......... Twitter [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Tue Sep 22 03:18:30 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Tue, 22 Sep 2009 00:18:30 -0700 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: Message-ID: Steve, On Sep 21, 2009, at 1:57 PM, Steven Bellovin wrote: > Is there any way to use FileVault on MacOS except on home directories? FileVault is essentially just the name for a plain encrypted disk image which happens to have some voodoo associated with it to get pivoted in as your homedir at login. This to say, you can make arbitrarily many encrypted disk images with Disk Utility and use them as individual encrypted (non-homedir) folders. If you're asking whether you can turn on encryption for existing system folders, the answer is no; HFS+ itself offers no encryption facilities. > I suppose I could install TrueCrypt (other suggestions or comments > on TrueVault?), but I prefer to minimize the amount of extra > software I have to maintain. TrueCrypt is a fine solution and indeed very helpful if you need cross- platform encrypted volumes; it lets you trivially make an encrypted USB key you can use on Linux, Windows and OS X. If you're *just* talking about OS X, I don't believe TrueCrypt offers any advantages over encrypted disk images unless you're big on conspiracy theories. Cheers, -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Darren.Moffat at Sun.COM Tue Sep 22 08:57:36 2009 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Tue, 22 Sep 2009 13:57:36 +0100 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: Message-ID: <4AB8C9C0.1060408@Sun.COM> Ivan Krsti wrote: > TrueCrypt is a fine solution and indeed very helpful if you need > cross-platform encrypted volumes; it lets you trivially make an > encrypted USB key you can use on Linux, Windows and OS X. If you're > *just* talking about OS X, I don't believe TrueCrypt offers any > advantages over encrypted disk images unless you're big on conspiracy > theories. Note my information may be out of date. I believe that MacOS native encrypted disk images (and thus FileVault) uses AES in CBC mode without any integrity protection, the Wikipedia article seems to confirm that is (or at least was) the case http://en.wikipedia.org/wiki/FileVault There is also a sleep mode issue identified by the NSA: http://crypto.nsa.org/vilefault/23C3-VileFault.pdf TrueCrypt on the other hand uses AES in XTS mode so you get confidentiality and integrity. -- Darren J Moffat --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From alec.muffett at gmail.com Tue Sep 22 10:06:01 2009 From: alec.muffett at gmail.com (Alec Muffett) Date: Tue, 22 Sep 2009 15:06:01 +0100 Subject: FileVault on other than home directories on MacOS? In-Reply-To: <20090922001501.309F2E9826@green.metzdowd.com> References: <20090922001501.309F2E9826@green.metzdowd.com> Message-ID: > In Disk Utility -> New Image, select size, properties and encryption > type (AES 128 or 256) and Create. > > Then mount and use your encrypted disks as needed. Just as an aside: on 10.5 and upwards I have taken to using encrypted sparse bundles rather than simple images; the advantage of doing this is that if you are creating a encrypted filesystem on (say) a 16Gb FAT-32 USB stick, then: a) you are not constrained to a 4Gb encrypted image (otherwise to FAT32) b) when using the sparse image, your files can be >4Gb c) you do not eat the entire stick all at once d) there can be (is?) a degree of garbage collection e) the stick is still usable as FAT32 - alec -- alec.muffett at gmail.com http://www.crypticide.com/dropsafe/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From crawdad at fnal.gov Tue Sep 22 11:27:50 2009 From: crawdad at fnal.gov (Matt Crawford) Date: Tue, 22 Sep 2009 10:27:50 -0500 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: Message-ID: On Sep 21, 2009, at 3:57 PM, Steven Bellovin wrote: > Is there any way to use FileVault on MacOS except on home > directories? I don't much want to use it on my home directory; it > doesn't play well with Time Machine (remember that availability is > also a security property); besides, different directories of mine > have different sensitivity levels. According to an Apple security person who spoke here about a year ago, you can use the underlying CLI to do everything FileVault does, but at some other point(s) in the directory tree than home directories. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From alserkli at inbox.ru Wed Sep 23 05:41:50 2009 From: alserkli at inbox.ru (Alexander Klimov) Date: Wed, 23 Sep 2009 12:41:50 +0300 (IDT) Subject: QNAP backdoor Message-ID: Overview: The premium and new line of QNAP network storage solutions allow for full hard disk encryption. When rebooting, the user has to unlock the hard disk by supplying the encryption passphrase via the web GUI. However, when the hard disk is encrypted, a secondary key is created, added to the keyring, and stored in the flash with minor obfuscation. Additional Weaknesses: The backdoor key is generated by rand() calls. As the rand() function produces random numbers unsuitable for cryptographic keys. The cryptographic strength of this generated key is approx 2^32, hence feasible for breaking. This would make access to the flash unnecessary. Original Vendor FUD: "The functionality for encryption the hard disk does not include a crypto backdoor." (in response to a user question why two keyslots are allocated, and if this is because of a backdoor) -- Regards, ASK --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From iang at systemics.com Wed Sep 23 19:57:56 2009 From: iang at systemics.com (Ian G) Date: Thu, 24 Sep 2009 01:57:56 +0200 Subject: FileVault on other than home directories on MacOS? In-Reply-To: <4AB8C9C0.1060408@Sun.COM> References: <4AB8C9C0.1060408@Sun.COM> Message-ID: <4ABAB604.1000803@systemics.com> On 22/09/2009 14:57, Darren J Moffat wrote: > There is also a sleep mode issue identified by the NSA: An extremely minor point, that looks like Jacob and Ralf-Philipp perhaps "aka nsa.org", rather than the NSA.gov. Still useful. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From krstic at solarsail.hcs.harvard.edu Wed Sep 23 22:30:15 2009 From: krstic at solarsail.hcs.harvard.edu (=?UTF-8?Q?Ivan_Krsti=C4=87?=) Date: Wed, 23 Sep 2009 19:30:15 -0700 Subject: FileVault on other than home directories on MacOS? In-Reply-To: <4AB8C9C0.1060408@Sun.COM> References: <4AB8C9C0.1060408@Sun.COM> Message-ID: On Sep 22, 2009, at 5:57 AM, Darren J Moffat wrote: > There is also a sleep mode issue identified by the NSA Unlike FileVault whose keys (have to) persist in memory for the duration of the login session, individual encrypted disk images are mounted on demand and their keys destroyed from memory on unmount. > TrueCrypt on the other hand uses AES in XTS mode so you get > confidentiality and integrity. XTS certainly doesn't provide cryptographic integrity. It provides different ciphertext malleability characteristics than CBC, in that you can only randomize an arbitrary 16-byte block of plaintext instead of being able to flip an arbitrary bit (and screw up the previous block). However, this comes with other costs inherent to seekable narrow-block encryption, so I think it's hard to argue XTS provides "more" integrity than CBC. Or were you referring to something else? -- Ivan Krsti? | http://radian.org --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Thu Sep 24 11:27:16 2009 From: perry at piermont.com (Perry E. Metzger) Date: Thu, 24 Sep 2009 11:27:16 -0400 Subject: Nominum says it has secret advantages over Bind Message-ID: <87bpl01hyj.fsf@snark.cb.piermont.com> More security and security politics than crypto, but I thought this was rather interesting to this community: Nominum's Jon Shalowitz is interviewed on why you should buy Nominum's stuff over using open source, oh, pardon, "freeware[sic]" software: Q: What characterises that open-source, freeware legacy DNS that you think makes it weaker? A: Number one is in terms of security controls. If I have a secret way of blocking a hacker from attacking my software, if it's freeware or open source, the hacker can look at the code. By virtue of something being open source, it has to be open to everybody to look into. I can't keep secrets in there. But if I have a commercial-grade software product, then all of that is closed off, and so things are not visible to the hacker. http://news.zdnet.co.uk/itmanagement/0,1000000308,39760362,00.htm?s_cid=260 I guess Mr. Shalowitz is unaware of the existence of disassemblers. Either that, or perhaps all those people attacking Windows successfully have the source code, I'm not sure which. Perry -- Perry E. Metzger perry at piermont.com --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From mheyman at gmail.com Thu Sep 24 13:02:53 2009 From: mheyman at gmail.com (mheyman at gmail.com) Date: Thu, 24 Sep 2009 13:02:53 -0400 Subject: AES in stick figures Message-ID: <5c8fcb9c0909241002i5688cb02kb063c58ed32ebf7e@mail.gmail.com> A Stick Figure Guide to the Advanced Encryption Standard (AES) (A play in 4 acts) -Michael Heyman --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From hughejp at mac.com Thu Sep 24 21:22:44 2009 From: hughejp at mac.com (james hughes) Date: Thu, 24 Sep 2009 18:22:44 -0700 Subject: FileVault on other than home directories on MacOS? In-Reply-To: <4AB8C9C0.1060408@Sun.COM> References: <4AB8C9C0.1060408@Sun.COM> Message-ID: On Sep 22, 2009, at 5:57 AM, Darren J Moffat wrote: > Ivan Krsti wrote: >> TrueCrypt is a fine solution and indeed very helpful if you need >> cross-platform encrypted volumes; it lets you trivially make an >> encrypted USB key you can use on Linux, Windows and OS X. If you're >> *just* talking about OS X, I don't believe TrueCrypt offers any >> advantages over encrypted disk images unless you're big on >> conspiracy theories. > > Note my information may be out of date. I believe that MacOS native > encrypted disk images (and thus FileVault) uses AES in CBC mode > without any integrity protection, the Wikipedia article seems to > confirm that is (or at least was) the case http://en.wikipedia.org/wiki/FileVault Unauthenticated CBC is indeed a problem http://tinyurl.com/ycoaruo > There is also a sleep mode issue identified by the NSA: > http://crypto.nsa.org/vilefault/23C3-VileFault.pdf I don't think that Jacob Appelbaum or Ralf-Philipp Weinmann work for the NSA (but having "crypto.nsa.org" is cool :-) > TrueCrypt on the other hand uses AES in XTS mode so you get > confidentiality and integrity. Technically, you do not get integrity. With XTS (P1619, narrow block tweaked cipher) you are not notified of data integrity failures, but these data integrity failures have a much reduced usability than CBC. With XTS: 1) You can return 16 byte chunks to previous values (ciphertext replay) as long as it is to the same place (offset) as it was before. 2) If you change a bit, you will randomize a 16 byte chunk of information. With the P1619.2 mode, I believe, is called TET (IEEE 1619.2, wide block tweaked cipher) there are different characteristics. Usually the wide block is a sector so it can be 512 or some other value. In this case, you do not get complete integrity either. In this case 1) You can return a sector to a previous value (sector reply) as long as it is to the same place (offset) as it was before. 2) If you change a bit, you will randomize a complete sector of information. If you change this to ZFS Crypto http://opensolaris.org/os/project/zfs-crypto/ You get complete integrity detection with the only remaining vulnerability that 1) you can return the entire disk to a previous state. While I may have put you all asleep, the basic premise holds... XTS is better than unauthenticated CBC. http://www.cpni.gov.uk/docs/re-20050509-00385.pdf http://jvn.jp/niscc/NISCC-004033/index.html http://www.kb.cert.org/vuls/id/302220 > -- > Darren J Moffat > > --------------------------------------------------------------------- > 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 jacob at appelbaum.net Fri Sep 25 04:26:22 2009 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Fri, 25 Sep 2009 01:26:22 -0700 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: <4AB8C9C0.1060408@Sun.COM> Message-ID: <4ABC7EAE.4030809@appelbaum.net> Ivan Krsti? wrote: > On Sep 22, 2009, at 5:57 AM, Darren J Moffat wrote: >> There is also a sleep mode issue identified by the NSA > > Unlike FileVault whose keys (have to) persist in memory for the duration > of the login session, individual encrypted disk images are mounted on > demand and their keys destroyed from memory on unmount. The devil is in the details. If you use your default keychain to unlock a disk, I believe the _passphrase_ is still stored by LoginWindow.app in plain text... So even if they destroyed keying material properly (do they? Is there source we can review for how FV works?) when the disk isn't in use, I somehow doubt that it's really safe to use FileVault in some circumstances against some attackers. Especially if you have a laptop and especially if you didn't turn on encrypted swap. Also especially if you happened to use the encrypted swap feature when it wasn't working. The list of hilarious bugs goes on and on. (The LoginWindow.app bug is as old as the hills and I'm one of a dozen people to have reported it, I bet. Apple still hasn't fixed it because they rely on a users password being in memory to escalate privileges without interacting with the user! I hear they're working on a fix but that it's difficult because many systems rely on this "feature.") I haven't been working on or thinking about VileFault much but I suppose that we probably could add support for sparse bundles if someone wanted. I've been bugging Apple for some specifications and so far, it's been years without a real response. Most of what we know is in VileFault: http://code.google.com/p/vilefault/ It would be really awesome if Apple would open up all of this code or at least publish a specification for how it works. With either we could have a Fuse file system module to support these disk images on other platforms... Best, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 155 bytes Desc: OpenPGP digital signature URL: From Darren.Moffat at Sun.COM Fri Sep 25 05:13:33 2009 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Fri, 25 Sep 2009 10:13:33 +0100 Subject: FileVault on other than home directories on MacOS? In-Reply-To: References: <4AB8C9C0.1060408@Sun.COM> Message-ID: <4ABC89BD.1010500@Sun.COM> james hughes wrote: >> TrueCrypt on the other hand uses AES in XTS mode so you get >> confidentiality and integrity. > > Technically, you do not get integrity. With XTS (P1619, narrow block > tweaked cipher) you are not notified of data integrity failures, but > these data integrity failures have a much reduced usability than CBC. > With XTS: [snip] > If you change this to ZFS Crypto > http://opensolaris.org/os/project/zfs-crypto/ > You get complete integrity detection with the only remaining > vulnerability that For those not familiar this is because Jim and I choose to use CCM/GCM with AES. ZFS is already using a copy-on-write validated merkle tree. The 16 byte tag/MAC from CCM/GCM is stored in the block pointer above forming a merkle tree. Each encrypted block in ZFS has its own IV. ZFS "disk" blocks are variable size from 512 bytes to (currently) 128k. > 1) you can return the entire disk to a previous state. > > While I may have put you all asleep, the basic premise holds... XTS is > better than unauthenticated CBC. Which is really what I was trying to say and over stated that XTS provides integrity. When really what it does is as you said, provides a better protection for certain classes of ciphertext modification than just using CBC. -- Darren J Moffat --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Sat Sep 26 12:31:14 2009 From: perry at piermont.com (Perry E. Metzger) Date: Sat, 26 Sep 2009 12:31:14 -0400 Subject: [Barker, Elaine B.] NIST Publication Announcements Message-ID: <87r5ttoegd.fsf@snark.cb.piermont.com> Forwarded: From: "Barker, Elaine B." To: "Barker, Elaine B." Date: Thu, 24 Sep 2009 15:54:18 -0400 Subject: NIST Publication Announcements NIST announces the completion of two NIST Special Publications (SPs): SP 800-56B, Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography, and SP 800-102, Recommendation for Digital Signature Timeliness. Both publications are available at http://csrc.nist.gov/publications/PubsSPs.html. SP 800-56B provides specifications of key establishment schemes that are appropriate for use by the U.S. Federal Government, based on a standard developed by the Accredited Standards Committee (ASC) X9, Inc.: ANS X9.44, Key Establishment using Integer Factorization Cryptography. A key establishment scheme can be characterized as either a key agreement scheme or a key transport scheme. This Recommendation provides asymmetric-based key agreement and key transport schemes that are based on the Rivest Shamir Adleman (RSA) algorithm. SP 800-102 is intended to address the timeliness of the digital signatures generated using the techniques specified in Federal Information Processing Standard (FIPS) 186-3. Establishing the time when a digital signature was generated is often a critical consideration. A signed message that includes the (purported) signing time provides no assurance that the private key was used to sign the message at that time unless the accuracy of the time can be trusted. SP 800-102 provides methods of obtaining assurance of the time of digital signature generation using a trusted timestamp authority that is trusted by both the signatory and the verifier. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From pgut001 at cs.auckland.ac.nz Sat Sep 26 22:03:00 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sun, 27 Sep 2009 15:03:00 +1300 Subject: Interesting way of protecting credit card data on untrusted hosts Message-ID: A Canadian company called SmartSwipe has come up with an interesting way to protect credit card numbers from most man-in-the-browser attacks. What they do is install a Windows CSP (cryptographic service provider) that acts as a proxy to an external mag-stripe reader with built-in crypto processing, so the CSP on the host PC does nothing more than forward data to be encrypted out to the external device. There's also a browser plug-in that pre-populates the credit-card field in web forms with a cookie. When the page is sent to the CSP for encryption for SSL, the software running on the reader recognises the cookie in the web-form content, reads the card data via the mag-stripe reader, inserts it into the web-form field, and returns the encrypted result to the host PC to forward to the remote server. As a result, the CC data is never present on the host PC. The downsides are obvious: not secure against phishing (which is a killer), only works with MSIE because of the requirement for use of a CSP (although you could do it with Firefox as well by creating a PKCS #11 soft-token), and not secure against page-rewrite trojans which have the web page show one thing and do another, but it's an interesting concept. You can find a description of the technology under the name Dynamic SSL(tm)(c)(p), a start point is: http://www.smartswipe.ca/en/dynamic-ssl/600-dynamic-ssl-a-practical-solution-for-endpoint-to-endpoint-encryption Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From mr.monkey at gmail.com Sun Sep 27 17:23:16 2009 From: mr.monkey at gmail.com (Fuzzy Hoodie-Monster) Date: Sun, 27 Sep 2009 14:23:16 -0700 Subject: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git) In-Reply-To: References: <20090827152340.GA1172@rek.tjls.com> Message-ID: <7abc832d0909271423q2dd65041v5fffd111fd9347b6@mail.gmail.com> On Mon, Sep 7, 2009 at 6:02 AM, Peter Gutmann wrote: > That's a rather high cost to pay just for the ability to make a crypto fashion > statement. ?Even if the ability to negotiate hash algorithms had been built in > from the start, this only removes the non-interoperability but doesn't remove > the complexity issue. As usual, I tend to agree with Peter. Consider the time scale and severity of problems with cryptographic algorithms vs. the time scale of protocol development vs. the time scale of bug creation attributable to complex designs. Let's make up some fake numbers, shall we? (After all, we're software engineers. Real numbers are for real engineers! Bah!) cryptographic algorithm weakness discovery rate: several per decade cryptographic algorithm weakness severity: 5 badness points per decade the weakness has been known; 7 badness points is considered fatal. Let's say MD5's badness is 8 and SHA-1's is 3. AES-256's is 1, because even after the attack it is still strong enough for most real uses. protocol development rate: 1 per year bug creation rate (baseline): tens per day per project bug creation rate for bugs due to complex designs: half of baseline (the other half is due to just regular mistakes) Although the numbers are fake, perhaps the orders of magnitude are close enough to make the point. Which is: your software will fail for reasons unrelated to cryptographic algorithm problems long before SHA-256 is broken enough to matter. Perhaps pluggability is a source of frequent failures, designed to solve for infrequent and low-severity algorithm failures. I would worry about an overfull \hbox (badness 10000!) long before I worried about AES-128 in CBC mode with a unique IV made from /dev/urandom. Between now and the time our ciphers and hashes and signatures are broken, we'll have a decade to design and implement the next simple system to replace our current system. Most software developers would be overjoyed to have a full decade. Why are we whining? What if TLS v1.1 (2006) specified that the only ciphersuite was RSA with >= 1024-bit keys, HMAC_SHA256, and AES-128 in CBC mode. How likely is it that attackers will be able to reliably and economically attack those algorithms in 2016? Meanwhile, the comically complex X.509 is already a punching bag (http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf and http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf, including the remote exploit in the certificate handling code itself). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From alec.muffett at gmail.com Sun Sep 27 17:40:14 2009 From: alec.muffett at gmail.com (Alec Muffett) Date: Sun, 27 Sep 2009 22:40:14 +0100 Subject: OTR splicer for Skype ? Message-ID: <2FB0B627-3144-46C5-9EBF-3D9D51833EA8@gmail.com> I found the following Adium-based solution for layering OTR atop Skype IM: http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2008-06/msg00224.html ...and was wondering whether anyone has generalised this by creating some open-source, standalone, simple application which talks to the Skype client API and splices OTR into the channel? Just wondering. -a -- alec.muffett at gmail.com http://www.crypticide.com/dropsafe/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From neuhaus at st.cs.uni-sb.de Tue Sep 29 03:40:00 2009 From: neuhaus at st.cs.uni-sb.de (Stephan Neuhaus) Date: Tue, 29 Sep 2009 09:40:00 +0200 Subject: [Barker, Elaine B.] NIST Publication Announcements In-Reply-To: <87r5ttoegd.fsf@snark.cb.piermont.com> References: <87r5ttoegd.fsf@snark.cb.piermont.com> Message-ID: On Sep 26, 2009, at 18:31, Perry E. Metzger wrote: > SP 800-102 is intended to address the timeliness of the digital > signatures generated using the techniques specified in Federal > Information Processing Standard (FIPS) 186-3. [...] SP 800-102 > provides > methods of obtaining assurance of the time of digital signature > generation using a trusted timestamp authority that is trusted by both > the signatory and the verifier. In the project in which I am involved we have just this problem, but we also have the problem that we can't require the participating parties to use a TTA. I have been attacking this problem from several angles but have not come to a solution. The setup is this: Alice advertises that she wants a job done. One of the constraints is that she wants it done by tomorrow, 10am. A number of Bobs apply for the job. Alice trusts none of the Bobs and the Bobs do not trust Alice. Alice doesn't even know the Bobs beforehand. Based on some criterion, Alice chooses a particular Bob. For business reasons, Alice can't force Bob to use a particular TTA, and it's also impossible to stipulate a particular TTA as part of the job description (the reason is that Alice and the Bobs----great band name BTW---won't agree to trust any particular TTA and also don't want to operate their own). Is there something that could be done that would *not* require a TTA? (I have almost given up on this, but it doesn't hurt to ask.) Fun, Stephan --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Tue Sep 29 10:31:01 2009 From: perry at piermont.com (Perry E. Metzger) Date: Tue, 29 Sep 2009 10:31:01 -0400 Subject: [Barker, Elaine B.] NIST Publication Announcements In-Reply-To: (Stephan Neuhaus's message of "Tue, 29 Sep 2009 09:40:00 +0200") References: <87r5ttoegd.fsf@snark.cb.piermont.com> Message-ID: <87tyylq0uy.fsf@snark.cb.piermont.com> Stephan Neuhaus writes: > For business reasons, > Alice can't force Bob to use a particular TTA, and it's also > impossible to stipulate a particular TTA as part of the job > description (the reason is that Alice and the Bobs----great band name > BTW---won't agree to trust any particular TTA and also don't want to > operate their own). You don't need such a complicated description -- you're just asking "can I do secure timestamping without requiring significant trust in the timestamping authority." The Haber & Stornetta scheme provides a timestamping service that doesn't require terribly much trust, since hard to forge widely witnessed events delimit particular sets of timestamps. The only issue is getting sufficient granularity. Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From leichter at lrw.com Tue Sep 29 10:40:27 2009 From: leichter at lrw.com (Jerry Leichter) Date: Tue, 29 Sep 2009 10:40:27 -0400 Subject: Unexpected side-effects Message-ID: <2C046234-C73C-40FA-905E-E6C351AE9480@lrw.com> Well, here I'll expect one. :-) As there is increasing pressure to keep records of Internet use, there will be a counter-move to use VPN's which promise to keep no records. Which will lead to legal orders that records be kept, with no notification to those being tracked. Enter secure remote attestation - rendering it impossible for an appropriately defined non-logging implementation to start logging without giving this fact away. Maybe it'll be the pirates who make the first large-scale use of those TPM's! -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From smb at cs.columbia.edu Tue Sep 29 23:07:57 2009 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 29 Sep 2009 23:07:57 -0400 Subject: [Barker, Elaine B.] NIST Publication Announcements In-Reply-To: <87tyylq0uy.fsf@snark.cb.piermont.com> References: <87r5ttoegd.fsf@snark.cb.piermont.com> <87tyylq0uy.fsf@snark.cb.piermont.com> Message-ID: <34ABC68C-A6DC-460B-8D6C-955F98F986E3@cs.columbia.edu> On Sep 29, 2009, at 10:31 AM, Perry E. Metzger wrote: > > Stephan Neuhaus writes: >> For business reasons, >> Alice can't force Bob to use a particular TTA, and it's also >> impossible to stipulate a particular TTA as part of the job >> description (the reason is that Alice and the Bobs----great band name >> BTW---won't agree to trust any particular TTA and also don't want to >> operate their own). > > You don't need such a complicated description -- you're just asking > "can > I do secure timestamping without requiring significant trust in the > timestamping authority." > > The Haber & Stornetta scheme provides a timestamping service that > doesn't require terribly much trust, since hard to forge widely > witnessed events delimit particular sets of timestamps. The only issue > is getting sufficient granularity. I don't know if their scheme was patented in Germany. It was in the U.S., though I think that at least some of the patents expire within the year. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jacob at appelbaum.net Wed Sep 30 01:51:33 2009 From: jacob at appelbaum.net (Jacob Appelbaum) Date: Tue, 29 Sep 2009 22:51:33 -0700 Subject: Merry Certmas! CN=*\x00thoughtcrime.noisebridge.net Message-ID: <4AC2F1E5.20004@appelbaum.net> Hello *, In the spirit of giving and sharing, I felt it would be nice to enable other Noisebridgers (and friends of Noisebridge) to play around with bugs in SSL/TLS. Moxie was just over and we'd discussed releasing this certificate for some time. He's already released a few certificates and I thought I'd join him. In celebration of his visit to San Francisco, I wanted to release fun-times-at-moxie-marlinspike-high. This is a text file that contains a fully valid, signed certificate (with private key) that can be used to exploit the NULL certificate prefix bug[0]. The certificate is valid for * on the internet (when exploiting libnss software). The certificate is good for two years. It won't work for exploiting the bug for software written with the WIN32 api, they don't accept (for good reason) *! I suggest the use of Moxie's sslsniff[1] if you're so inclined to try network related testing. It may also be useful for testing code signing software. It's been long enough that everyone should be patched for this awesome class of bugs. This certificate and corresponding private key should help people test fairly obscure software or software they've written themselves. I hope this release will help with confirmation of the bug and with regression testing. Feel free to use this certificate for anything relating to free software too. Consider it released into the public domain of interesting integers. Enjoy! Best, Jacob [0] http://thoughtcrime.org/papers/null-prefix-attacks.pdf [1] http://thoughtcrime.org/software/sslsniff/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fun-times-at-moxie-marlinspike-high URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 155 bytes Desc: OpenPGP digital signature URL: From perry at piermont.com Wed Sep 30 10:09:18 2009 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 30 Sep 2009 10:09:18 -0400 Subject: [Paul F. Doyle] Timestamping Message-ID: <877hvgv81d.fsf@snark.cb.piermont.com> Forwarded message: From: "Paul F. Doyle" To: , Cc: Subject: Re: [Barker, Elaine B.] NIST Publication Announcements Date: Wed, 30 Sep 2009 09:55:36 -0400 Hello Perry and Stephan (cc: Dan Geer), Dan Geer forwarded a message thread from the crypto mailing list. There is an approach to Trusted Time Stamping you may find interesting, useful and rather different given the circumstances you've described in the thread. It is known as the Transient Key Method and is NOT based on a conventional PKI method for generating cryptographic time stamps, but instead a fully distributed, web-style, self-validating model. I would be happy to describe the Transient Key Method in detail if this would be helpful and can forward along some background documentation if you are interested. BTW, it is one of the methods included in the American National Standard X9.95. Please let me know how I can be of assistance. Thanks, --Paul "A life without integrity is meaningless... ...a record or dataset without integrity is worthless!" Paul F. Doyle Founder & CEO Proofspace P.O. Box 369 Ada, MI 49301 v. 616-458-5733 m. 616-292-8350 f. 866-685-2386/616-458-2271 www.proofspace.com LinkedIn: www.linkedin.com/in/paulfdoyle e. paul at proofspace.com skype. paul_proofspace --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From marcus.brinkmann at ruhr-uni-bochum.de Wed Sep 30 10:58:50 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 30 Sep 2009 16:58:50 +0200 Subject: Unexpected side-effects In-Reply-To: <2C046234-C73C-40FA-905E-E6C351AE9480@lrw.com> References: <2C046234-C73C-40FA-905E-E6C351AE9480@lrw.com> Message-ID: <4AC3722A.1020209@ruhr-uni-bochum.de> Jerry Leichter wrote: > Well, here I'll expect one. :-) Not a new idea, although I don't know where I heard it the first time. > As there is increasing pressure to keep > records of Internet use, there will be a counter-move to use VPN's which > promise to keep no records. Which will lead to legal orders that > records be kept, with no notification to those being tracked. Enter > secure remote attestation - rendering it impossible for an appropriately > defined non-logging implementation to start logging without giving this > fact away. Probably off-topic for this list, but this doesn't make much sense to me, as such non-logging implementations likely will be just as illegal as notifying the client of the change, which seems an overall better solution if you are willing to break the law (provided you can hide the notification from authorities). [In Germany, means of surveillance are required by law, as is record keeping]. Getting back on topic, cryptographically speaking, it's also quite possible to just monitor all ingoing and outcoming traffic and correlate one with the other. Preventing this is not easy, even if encryption is used. > Maybe it'll be the pirates who make the first large-scale use of those > TPM's! Maybe, and this would be a major confirmation that TPM actually works at any non-trivial scale. I can't see it, though. Thanks, Marcus --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Nicolas.Williams at sun.com Wed Sep 30 12:42:40 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 30 Sep 2009 11:42:40 -0500 Subject: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git) In-Reply-To: <7abc832d0909271423q2dd65041v5fffd111fd9347b6@mail.gmail.com> References: <20090827152340.GA1172@rek.tjls.com> <7abc832d0909271423q2dd65041v5fffd111fd9347b6@mail.gmail.com> Message-ID: <20090930164240.GL887@Sun.COM> On Sun, Sep 27, 2009 at 02:23:16PM -0700, Fuzzy Hoodie-Monster wrote: > As usual, I tend to agree with Peter. Consider the time scale and > severity of problems with cryptographic algorithms vs. the time scale > of protocol development vs. the time scale of bug creation > attributable to complex designs. Let's make up some fake numbers, > shall we? (After all, we're software engineers. Real numbers are for > real engineers! Bah!) > > [snip] > > Although the numbers are fake, perhaps the orders of magnitude are > close enough to make the point. Which is: your software will fail for > reasons unrelated to cryptographic algorithm problems long before > SHA-256 is broken enough to matter. Perhaps pluggability is a source > of frequent failures, designed to solve for infrequent and > low-severity algorithm failures. I would worry about an overfull \hbox > (badness 10000!) long before I worried about AES-128 in CBC mode with > a unique IV made from /dev/urandom. Between now and the time our "AES-128 in CBC mode with a unique IV made from /dev/urandom" is manifestly not the issue of the day. The issue is hash function strength. So when would you worry about MD5? SHA-1? By your own admission MD5 has already been fatally wounded and SHA-1 is headed that way. > ciphers and hashes and signatures are broken, we'll have a decade to > design and implement the next simple system to replace our current > system. Most software developers would be overjoyed to have a full > decade. Why are we whining? We don't have a decade to replace MD5. We've had a long time to replace MD5, and even SHA-1 already, but we haven't done it yet. The reason is simple: there's more to it than you've stated. Specifically, for example, you ignored protocol update development (you assumed 1 new protocol per-year, but this says nothing about how long it takes to, say, update TLS) and deployment issues completely, and you supposed that software development happens at a consistent, fast clip throughout. Software development and deployment are usually constrained by legacy and customer behavior, as well as resource availability, all of which varies enormously. Protocol upgrade development, for example, is harder than you might think (I'm guessing though, since you didn't address that issue). Complexity exists outside protocol. This is why we must plan ahead and make reasonable trade-offs. Devising protocols that make upgrade easier is important, supposing that they actually help with the deployment issues (cue your argument that they do not). I'm OK with making up numbers for the sake of argument. But you have to make up all the relevent numbers. Then we can plug in real data where we have it, argue about the other numbers, ... > What if TLS v1.1 (2006) specified that the only ciphersuite was RSA > with >= 1024-bit keys, HMAC_SHA256, and AES-128 in CBC mode. How > likely is it that attackers will be able to reliably and economically > attack those algorithms in 2016? Meanwhile, the comically complex > X.509 is already a punching bag > (http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf > and http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf, > including the remote exploit in the certificate handling code itself). We don't have crystal balls. We don't really know what's in store for AES, for example. Conservative design says we should have a way to deploy alternatives in a reasonably short period of time. You and Peter are clearly biased against TLS 1.2 specifically, and algorithm negotiation generally. It's also clear that you're outside the IETF consensus on both matters _for now_. IMO you'll need to make better arguments, or wait enough time to be proven right by events, in order to change that consensus. Nico -- --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From Victor.Duchovni at morganstanley.com Wed Sep 30 15:57:40 2009 From: Victor.Duchovni at morganstanley.com (Victor Duchovni) Date: Wed, 30 Sep 2009 15:57:40 -0400 Subject: Merry Certmas! CN=*\x00thoughtcrime.noisebridge.net In-Reply-To: <4AC2F1E5.20004@appelbaum.net> References: <4AC2F1E5.20004@appelbaum.net> Message-ID: <20090930195740.GD15863@np305c2n2.ms.com> On Tue, Sep 29, 2009 at 10:51:33PM -0700, Jacob Appelbaum wrote: > It's been long enough that everyone should be patched for this awesome > class of bugs. This certificate and corresponding private key should > help people test fairly obscure software or software they've written > themselves. I hope this release will help with confirmation of the bug > and with regression testing. Feel free to use this certificate for > anything relating to free software too. Consider it released into the > public domain of interesting integers. If anyone is curious about the impact of this on the Postfix TLS engine (March 2006, version 2.3.0 and later releases): 1. Postfix checks subject domains obtained from either subjectAltName or CN to ensure that the ASN.1 string object length is equal to the C string length. Certificates that fail this test are considered anonymous. These checks were added in the Spring of 2005 when the contributed TLS patch adopted in the 2.2 release was significantly extended and revised. 2. Postfix only matches *.example.com certificates against single-label sub-domains of example.com. Thus for example, the Postini wild-card certificate for: *.psmtp.com does not match (say Verisign's), MX records of the form: verisign.com. IN MX 100 verisign.com.s6a1.psmtp.com. verisign.com. IN MX 200 verisign.com.s6a2.psmtp.com. verisign.com. IN MX 300 verisign.com.s6b1.psmtp.com. verisign.com. IN MX 400 verisign.com.s6b2.psmtp.com. (Postfix also does not, for "secure-channel" destinations, trust DNS enough to let MX records influence the name expected in a peer certificate. So Postini's wildcard certificate is perhaps only useful with other sending systems). So a "*" certificate will never match any peer domain. Bottom line, this issue does not impact the Postfix secure-channel TLS use case. -- Viktor. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From jamesd at echeque.com Wed Sep 30 16:38:03 2009 From: jamesd at echeque.com (James A. Donald) Date: Thu, 01 Oct 2009 06:38:03 +1000 Subject: [Barker, Elaine B.] NIST Publication Announcements In-Reply-To: <34ABC68C-A6DC-460B-8D6C-955F98F986E3@cs.columbia.edu> References: <87r5ttoegd.fsf@snark.cb.piermont.com> <87tyylq0uy.fsf@snark.cb.piermont.com> <34ABC68C-A6DC-460B-8D6C-955F98F986E3@cs.columbia.edu> Message-ID: <4AC3C1AB.2080807@echeque.com> >> The Haber & Stornetta scheme provides a timestamping >> service that doesn't require terribly much trust, >> since hard to forge widely witnessed events delimit >> particular sets of timestamps. The only issue is >> getting sufficient granularity. > I don't know if their scheme was patented in Germany. > It was in the U.S., though I think that at least some > of the patents expire within the year. In looking this up, I have noticed a pile of patents that patent something equivalent or near equivalent to a patricia hash tree, or elaborately disguised patricia trees, or something suspiciously similar to a patricia hash tree, and various special cases of it, and applications of it, without using the name "patricia hash tree" Since they seem reluctant to use the name "patricia hash tree" I suspect that there is already a pile of prior art, but I could not find any, though I am fairly sure the method is widely known. Also, wherever there is a pile of patents, there is usually a pile of prior art. Lest even more patents of the patricia hash tree be published, I would like to describe the method here, though it surely must be described somewhere else, probably long ago. Suppose we have a lot of records, each with a key that makes collision improbable or impossible, We assemble them in a patricia tree, with each node of the patricia tree containing a hash of its child nodes. The root of the patricia tree then, like a tiger hash, uniquely identifies the complete data set. If we have multiple copies of the data set, this data structure allows us to not only ensure that both copies are identical, but if there are small differences between them, such as recently added records, it allows us to efficiently find the differences, and thus efficiently bring the two data sets into agreement. It also allows us to prove that a given record was part of a particular data set at a particular time. Suppose the high order part of the key identifies the high order part of the time, followed by the id of the particular organization holding those records. The upper parts of the patricia hash tree are partially shared, peer to peer, similarly to file sharing with a tiger hash. Each participating organization keeps the nodes that relate to it. The lower parts are not shared except as needed. In this case, there will be a small set of top nodes of the tree that cease to change, because they only rely on keys earlier than a certain date, and this small and very slowly growing set of top nodes proves the complete state of the tree at all earlier dates. Then each organization can prove to all or any of the others that it had a particular record, or particular set of records, at a particular time, to the granularity of the time that is the high order part of the key. Where some or all of the data needs to be shared by some or all of the organizations, organizations can rapidly and efficiently identify any disagreements, and when they are in agreement, rapidly and efficiently prove to themselves, and to everyone else, and record for all time, that they are in agreement, since a small number of the topmost nodes of the tree proves the state of the tree at each and all times that contributed to those nodes. The structure serves for attestation and sharing, and since attestation usually involves sharing, and sharing attestation, the scope for patenting this structure over and over again in one disguise or another to be applied to one task or another that involves sharing and or attestation is limited only by the boundless imagination of patent lawyers. One can also add horizontal and backwards hash relationships between nodes that serve little practical purpose other than allowing one to have a single rapidly changing node node attesting instead of a small set of nodes, and allowing it to be nominally something other than a patricia hash tree. Thus, for example, instead of using forty or so nodes to attest for the state of million organizations over a billion time periods, one can use a hash of those forty nodes, and there are no end of different ways one can hash those forty or so nodes together. But under that hash, it is still a patricia hash tree doing the actual work of gluing the data together. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com From perry at piermont.com Wed Sep 30 20:56:05 2009 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 30 Sep 2009 20:56:05 -0400 Subject: [Barker, Elaine B.] NIST Publication Announcements In-Reply-To: <4AC3C1AB.2080807@echeque.com> (James A. Donald's message of "Thu, 01 Oct 2009 06:38:03 +1000") References: <87r5ttoegd.fsf@snark.cb.piermont.com> <87tyylq0uy.fsf@snark.cb.piermont.com> <34ABC68C-A6DC-460B-8D6C-955F98F986E3@cs.columbia.edu> <4AC3C1AB.2080807@echeque.com> Message-ID: <87ske4vsnu.fsf@snark.cb.piermont.com> "James A. Donald" writes: >>> The Haber & Stornetta scheme provides a timestamping >>> service that doesn't require terribly much trust, >>> since hard to forge widely witnessed events delimit >>> particular sets of timestamps. The only issue is >>> getting sufficient granularity. > >> I don't know if their scheme was patented in Germany. >> It was in the U.S., though I think that at least some >> of the patents expire within the year. > > In looking this up, I have noticed a pile of patents > that patent something equivalent or near equivalent to a > patricia hash tree, or elaborately disguised patricia > trees, or something suspiciously similar to a patricia > hash tree, and various special cases of it, and > applications of it, without using the name "patricia > hash tree" Perhaps that's because this is a Merkle tree, not a patricia tree. Patricia trees are radix trees -- they're used for optimizing routing tables, not in cryptography. Perry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com