[fc-announce] Financial Crypto and Data Security 2010: speakers and workshops [submission deadline: September 15, 2009]
Begin forwarded message: From: Radu Sion Date: September 4, 2009 12:14:45 PM GMT-04:00 To: fc-annou...@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
Re: Client Certificate UI for Chrome?
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 majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
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 loginurl="/customers/loginpage.script>login A not quite rectangular login form which is not an html page rolls out of the url, with a motion like a blind or toilet paper unrolling, and partially covers the browser chrome, thus associating the form with the browser and the url, rather than the web page. The form will be decorated and prominently watermarked in manner that is customizable by the end user, and if the end user does not customize it, which he probably will not, a customization was randomly selected at install time. A phisher could do a flash animation that looks almost like the form rolling out, but the flash animation will not roll out of the url, and will not partially cover the browser chrome, and is unlikely to match the customization. If the url is http://exampledomain.com/somedirectory/somepage.html Then the content of the login form is controlled by script at login://exampledomain.com//customers/loginpage.script The login form will be associated with a public key. If the user has logged in before using this browser, there will be an entry in his bookmarks list for the url *and* public key If the login form is the browser's bookmark list, the title on the login form will be the petname, that is to say, the name under which it appears in the bookmark list. If the login form is *not* in the browser's bookmark list, the title on the login form will be "No Previous Login at this site using this browser by this user", with script supplied title and or certificate supplied title somewhere else in smaller print. The loginpage.script will tell the browser what fields and fieldnames to request from the user - typically username and password, but this needs to be scriptable - for example it could be credit card number, etc. The script will tell the server what database table and what database fields to associate these user supplied fields with when the client responds. Peter Gutmann has, he believes, a much simpler solution. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
so how do *you* manage your keys, then? part 3
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 majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
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 majord...@metzdowd.com
RNG using AES CTR as encryption algorithm
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 majord...@metzdowd.com
"Fed's RFIDiocy pwnd at DefCon"
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 majord...@metzdowd.com
Re: AES-GMAC as a hash
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 majord...@metzdowd.com
Re: AES-GMAC as a hash
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 majord...@metzdowd.com
Re: [Macgpg-users] GPGMail & Snow Leopard
On Aug 28, 2009, at 8:25 PM, R.A. Hettinga wrote: ...and now GPG. So, Snow Leopard is crypto-less? To be strictly accurate, the problem is with GPGMail, the plugin that integrates GPG with Apple's Mail application (as Mail internals changed significantly between Leopard and Snow Leopard). GPG itself seems to work just fine under Snow Leopard, albeit on the command line. David - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: AES-GMAC as a hash
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. Hal Finney - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Source for Skype Trojan released
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"? Stephan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: [tahoe-dev] a crypto puzzle about digital signatures and future compatibility
On Thursday,2009-08-27, at 19:14 , James A. Donald wrote: Zooko Wilcox-O'Hearn wrote: Right, and if we add algorithm agility then this attack is possible even if both SHA-2 and SHA-3 are perfectly secure! Consider this variation of the scenario: Alice generates a filecap and gives it to Bob. Bob uses it to fetch a file, reads the file and sends the filecap to Carol along with a note saying that he approves this file. Carol uses the filecap to fetch the file. The Bob-and- Carol team loses if she gets a different file than the one he got. ... So the leading bits of the capability have to be an algorithm identifier. If Bob's tool does not recognize the algorithm, it fails, and he has to upgrade to a tool that recognizes more algorithms. If the protocol allows multiple hash types, then the hash has to start with a number that identifies the algorithm. Yet we want that number to comprise of very, very few bits. Jim, I'm not sure you understood the specific problem I meant -- I'm concerned (for starters) with the problems that arise if we support more than one secure hash algorithm *even* when none of the supported secure hash algorithms ever becomes crackable! So much so that I currently intend to avoid having a notion of algorithm agility inside the current Tahoe-LAFS code base, and instead plan for an algorithm upgrade to require a code base upgrade and a separate, syntactically distinct, type of file capability. This is almost precisely the example problem I discuss in jim.com/security/prefix_free_number_encoding.html> Hey, that's interesting. I'll study your prefix-free encoding format some time. Regards, Zooko - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
