Re: Protection mail at rest
A more recent version, which appeared at ACSAC in December 2007 can be found at: http://www1.cs.columbia.edu/~angelos/Papers/2007/SSARES_ACSAC.pdf Since then, the student primarily working on this(*) has improved performance to the point of being able to search a couple of email messages per minute or so, with further scope for improvement. The very large storage overhead remains, but can probably be reduced by half or so. (*) Adam Aviv; he was an undergrad at Columbia, now pursuing his Phd with Matt Blaze at UPenn... -Angelos On Jun 1, 2008, at 8:53 AM, Perry E. Metzger wrote: Leichter, Jerry [EMAIL PROTECTED] writes: Does anyone know of existing work in this area? SSARES: Secure Searchable Automated Remote Email Storage by Keromytis et al, http://www1.cs.columbia.edu/~angelos/Papers/2006/SSARES_short.pdf There is probably other work out there. In some small part, this also looks like the problem that Matt Blaze's CFS addressed, though in that case it was to deal with untrusted remote file servers rather than email servers. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unpatented PAKE!
Scott G. Kelly wrote: Here's another approach to password authenticated key exchange with similar security claims. The underlying mechanism is under consideration for inclusion in by the 802.11s group in IEEE: http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-01.txt Hmmm. I don't see any IPR statements for that draft. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection mail at rest
At 11:36 AM -0400 6/1/08, Ivan Krstiç wrote: The easiest thing for people who _do_ care is still running their own mail server. Fully agree. You're in control, all the way to root of the box. The emergence of reasonably priced VM hosting providers (e.g. slicehost.com) makes it fairly uncomplicated, modulo initial setup. And, if you want to host on FreeBSD instead of Linux, see http://www.rootbsd.net/. Same price, good service. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unpatented PAKE!
Scott G. Kelly wrote: Ben Laurie wrote: Scott G. Kelly wrote: Here's another approach to password authenticated key exchange with similar security claims. The underlying mechanism is under consideration for inclusion in by the 802.11s group in IEEE: http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-01.txt Hmmm. I don't see any IPR statements for that draft. My understanding is that there are no IPR claims on this method. I am not a lawyer, though. Given the stupidity of the US patent system, at least the authors need to state that they make no claims, AIUI. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protection mail at rest
| There's an option 2b that might be even more practical: an S/MIME or | PGP/MIME forwarder. That is, have a trusted party receive your mail, | but rather than forwarding it intact encrypt it and then forward it to | your favorite IMAP provider. Excellent idea! I like it. Of course, it's another piece of a distributed solution that you need to keep running. It would make for an interesting third-party service. (On the surface, letting a third party run this for you seems hazardous, but as always your stuff is exposed on the way to the forwarder whatever you do A forwarded like this as a pre-packaged EC2 VM, perhaps? -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Can we copy trust?
In the essay Better Than Free, Kevin Kelly debates which concepts hold value online, and how to monetize those values. See www.kk.org/thetechnium/archives/2008/01/better_than_fre.php Kelly's point can be very useful: *When copies are free, you need to sell things which can not be copied.* The problem that I see and present to this list is when he discusses qualities that can't be copied and considers trust as something that cannot be copied. Well, in the digital economy we had to learn how to copy trust and we did. For example, SSL would not work if trust could not be copied. How do we copy trust? By recognizing that because trust cannot be communicated by self-assertions (*), trust cannot be copied by self-assertions either. To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. To copy trust, all you do is copy the information from those channels in a verifiable way and add that to the original channel information. We do this all the time in scientific work: we provide our findings, we provide the way to reproduce the findings, and we provide the published references that anyone can verify. To copy trust in the digital economy, we provide digital signatures from one or more third-parties that most people will trust. This is how SSL works. The site provides a digital certificate signed by a CA that most browsers trust, providing an independent channel to verify that the web address is correct -- in addition to what the browser's location line says. Cheers, Ed Gerck (*) Trust as qualified reliance on information in http://nma.com/papers/it-trust-part1.pdf and Digital Certificates: Applied Internet Security by J. Feghhi, J. Feghhi and P. Williams, Addison-Wesley, ISBN 0-20-130980-7, 1998. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unpatented PAKE!
Ben Laurie wrote: Scott G. Kelly wrote: Here's another approach to password authenticated key exchange with similar security claims. The underlying mechanism is under consideration for inclusion in by the 802.11s group in IEEE: http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-01.txt Hmmm. I don't see any IPR statements for that draft. My understanding is that there are no IPR claims on this method. I am not a lawyer, though. --Scott - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Video of physical attack on smart card
[EMAIL PROTECTED] wrote: In a video, Christopher Tarnovsky, shows a physical attack on a smart card: http://blog.wired.com/27bstroke6/2008/05/hacker-at-cente.html I couldn't tell from the video how long it takes but it doesn't appear to take more than an hour or so. I had written up some analysis here: http://rdist.root.org/2008/05/30/chris-tarnovsky-demos-smart-card-hacking/ -- Nate - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ed Gerck wrote: In the essay Better Than Free, Kevin Kelly debates which concepts hold value online, and how to monetize those values. See www.kk.org/thetechnium/archives/2008/01/better_than_fre.php Kelly's point can be very useful: *When copies are free, you need to sell things which can not be copied.* The problem that I see and present to this list is when he discusses qualities that can't be copied and considers trust as something that cannot be copied. Well, in the digital economy we had to learn how to copy trust and we did. For example, SSL would not work if trust could not be copied. How do we copy trust? By recognizing that because trust cannot be communicated by self-assertions (*), trust cannot be copied by self-assertions either. To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. To copy trust, all you do is copy the information from those channels in a verifiable way and add that to the original channel information. We do this all the time in scientific work: we provide our findings, we provide the way to reproduce the findings, and we provide the published references that anyone can verify. To copy trust in the digital economy, we provide digital signatures from one or more third-parties that most people will trust. This is how SSL works. The site provides a digital certificate signed by a CA that most browsers trust, providing an independent channel to verify that the web address is correct -- in addition to what the browser's location line says. But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
Victor Duchovni wrote: On Tue, May 27, 2008 at 08:08:11PM +0100, Dave Korn wrote: Well spotted. Yes, I guess that's what Jim Youll was asking. And I should have said seemingly-contradictory. This is, of course, what I meant by marketeering: when someone asks if your service is insecure and interceptable, you don't say Yes, our ordinary service will give you up to the filth at the drop of a hat, you spin it as No, our enterprise service is completely secure [...other details elided...]. But this is not news. It is well known (at least among the Enterprise Remote Computing wonks) that only the Enterprise RIM service provides end-to-end security, while the consumer service does not. There is nothing new here. It is not even marketing spin, without your IT shop hosting your content, it is hosted by providers subject to CALEA, ... The good news about RIM is that it has been one of the few devices that actually provides end-to-end security for Enterprises. This has been a selling point that helped get them a large share of the Enterprise market. There is now a software product that does about the same for VoIP that may be of interest when used with Magicjack (http://www.magicjack.com/1/index.asp). The software is: http://zfoneproject.com/getstarted.html Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ben Laurie wrote: But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Another point: When we talk about a copy, we're technically talking about a transmission. To copy a web page to your hard disk is to transmit bits from the web server to your disk. To say that we cannot copy trust would, thus, be the same as to say that we cannot transmit trust. But we can and do transmit trust -- we just have to do it right (see refs in previous post). Similarly, we have to do it right when we transmit data (for example, if we don't have enough bandwidth or if there is too much noise, the data will be not be 100% transferred). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fwd: Protection mail at rest
I recently implemented SSARES directly in python and also added parallelism to the searching. We can now search the a large inbox (1000+) messages in about 2-4 minutes. Technically, this could be done on a large scale and be practical, since my implementation is not fully optimized nor free of bugs. The implementation is available on my web site, http://fling.seas.upenn.edu/~aviv/wiki/index.php?n=SSARESApp.SSARESApp as well as some current benchmarks. I am not a cryptographer (so implementation may not be perfect), nor do I guarantee that the code doesn't have bugs. This is grad-ware and for research purposes only. Yet, as a proof of concept, feel free to play around with it and let me know what you think. I can supply more python scripts for searching and what not if anyone wants. thanks, adam On Sun, Jun 1, 2008 at 8:09 PM, Angelos D. Keromytis [EMAIL PROTECTED] wrote: A more recent version, which appeared at ACSAC in December 2007 can be found at: http://www1.cs.columbia.edu/~angelos/Papers/2007/SSARES_ACSAC.pdf Since then, the student primarily working on this(*) has improved performance to the point of being able to search a couple of email messages per minute or so, with further scope for improvement. The very large storage overhead remains, but can probably be reduced by half or so. (*) Adam Aviv; he was an undergrad at Columbia, now pursuing his Phd with Matt Blaze at UPenn... -Angelos On Jun 1, 2008, at 8:53 AM, Perry E. Metzger wrote: Leichter, Jerry [EMAIL PROTECTED] writes: Does anyone know of existing work in this area? SSARES: Secure Searchable Automated Remote Email Storage by Keromytis et al, http://www1.cs.columbia.edu/~angelos/Papers/2006/SSARES_short.pdf There is probably other work out there. In some small part, this also looks like the problem that Matt Blaze's CFS addressed, though in that case it was to deal with untrusted remote file servers rather than email servers. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Adam Aviv Ph. D. Candidate Computer and Information Science University of Pennsylvania -- Adam Aviv Ph. D. Candidate Computer and Information Science University of Pennsylvania - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
[EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Bill Frantz wrote: [EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. Recognition = a channel of information memory = a channel of information When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. The distinguishing aspect between information and trust is this: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. In other words, self-assertions cannot transfer trust. Trust me is, actually, a good indication not to trust. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Yes, where recognition is the OTHER channel that tells you that the value (given in the original channel) is correct. Just the value by itself is not useful for communicating trust -- you also need something else (eg, a digital sig) to provide the OTHER channel of information. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
