Re: Russia Intercepts US Military Communications?
On Sun, Mar 30, 2003 at 07:38:29PM -0500, reusch wrote: | Via the Cryptome, http://www.cryptome.org/, RU sure, look | at http://www.aeronautics.ru/news/news002/news082.htm. | | I'm amazed at their claims of radio interception. One would | expect that all US military communications, even trivial ones, | are strongly encrypted, given the ease of doing this. Someone, | more well informed, please reassure me that this is the case. The ease of doing what? Applying DES with a known key? Key management is hard. Doing key lookups, cert chain management, etc, to NSA level stadards is expensive. Etc. The non-availability of good, cheap, easy to use crypto in a COTS package is the legacy of the ITAR and EAR. That there is a lack of deployed crypto in the US military should be unsuprising. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Russia Intercepts US Military Communications?
On Mon, Mar 31, 2003 at 01:17:43PM -0500, Peter Wayner wrote: | He went on to talk about crypto as if it was something like fuel or | food. He said, They probably loaded up 4 or 5 days of crypto at the | beginning, but then they had to turn it off after the supply lines | got muddled. | | So this would be consistent with some key management structures but | not with others. If you give a unit a good random number source and | diffie-hellman, they should be able to go the entire war without | running out of crypto. But I don't know if the US military embraces | the kind of hierarchy-free key management imagined by cypherpunks. Heh. They certainly tend not to. And really, when you have a hierarchy, you may not even want to. The ease of jumping into an encrypted net with a MITM attack would be pretty scary, or everyone needs copies of a few dozen to thousands of authentication keys, which is going to be tricky. (Of course, if they just put the crypto on smartcards, or key fobs, you could likely carry a month or three worth of crypto with you, but then they wouldn't know what had happened to every key out there. Clearly, its better to have unencrypted comms where you know they're insecure, rather than low assurance secure comms. For some threat models that I disagree with, anyway. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Keysigning @ CFP2003
On Tue, Mar 25, 2003 at 12:36:20AM -0500, Ian Grigg wrote: | So, do we have two completely disjoint communities | here? One group that avoids photo id and another | that requires it? Or is one group or the other so | small that nobody really noticed? Yes. One group thinks that a bad trust chain is worse than no trust chains. This group tends to think that fake ID is easy, and that ID based signatures reduce trust in the web. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scientists question electronic voting
On Thu, Mar 06, 2003 at 10:35:22PM -0500, Barney Wolff wrote: | On Thu, Mar 06, 2003 at 08:38:42PM -0500, Dan Riley wrote: | | But this whole discussion is terribly last century--still pictures are | passe. What's the defense of any of these systems against cell phones | that transmit live video? | | A Faraday cage. | | Seriously, what current or historic voting system would defend against | these risks? We certainly don't want an electronic system that is more | vulnerable than existing systems, but sticking with known-to-be-terrible | systems is not a sensible choice either. Break the trust of the vote buyers and sellers by making confirmation hard. Pictures in the booth of party line ballots that you can draw over the screen would be very hard to distinguish from the real thing over a cell-phone quality video picture. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Stupid security measures, a contest
Human rights watchdog Privacy International has launched a quest to find the World's Most Stupid Security Measure. http://www.theregister.co.uk/content/55/29279.html -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A talk on Intellectual Property and National Defense
Dave, I think Peter was responding to me, not you. And no, I'm not proposing that this be done, but I suspect that the RIAA and MPAA will go as far as saying no off-net viewing of controlled media. Recall that they already supported the DIVX system which required a phone line to work. From their perspective, its their content, and they're going to squeeze it as much from it as they can. Adam On Tue, Feb 04, 2003 at 11:37:20AM -0500, Dave Farber wrote: | Sorry that is not what I said. Where did you get that from the above? | | On 2/4/03 11:28 AM, Trei, Peter [EMAIL PROTECTED] wrote: | | Adam Shostack[SMTP:[EMAIL PROTECTED]] writes: | | I believe that DRM systems will require not just an authorized boot | sequence, but a secure remote attestation that that boot sequence was | followed, and a secure attestation as to the versions of the software | on your system. So, while a secure system is needed for AT/DRM, its | not enough. | | Let me get this straight - in order to make the RIAA and MPAA richer, | we're going to ban off-net computer use? If you're not near a WiFi | hotspot you won't be able to boot your laptop? | | Peter Trei | | | | -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question regarding group management of documents
Groove does this; they have a 30ish page white paper on security of document management. I have a few quibbles with their design (way too many crypto algorithms, and its not clear why, or if they might interact badly, and perhaps cert verification in a corporate environment could be better, but overall it looks very solid.) http://www.groove.net/products/workspace/security.html Now if only they had a Mac client! Adam On Thu, Jan 16, 2003 at 09:38:04AM +0100, Birger Toedtmann wrote: | | Hi, | | can anyone pinpoint me to some papers on this - the Net did not show | up anything useful (and I hope it's not my lacking competence in using | Google). | | | I'd like to use a server to share documents between users. The users | are grouped, i.e. a user of group A should not be able to read the | docs of group B (if not a member of it). There are conceptually two | possible ways to design this: | | * use an out-band-process (an operating system watching over |file permissions, a web service verifying user credentials etc.) | | * use in-band crypto on the document itself, i.e. the permissions |are inherently tied to the bits it consists of | | I wanted to use the latter with a critical constraint: ease of deploy- | ment (at least in a sense) which basically means that we don't want | to write a new client but use freely available ones. So my first | guess was to PGP-encrypt the files on the server using the public | keys of the group-members. The server obviously should not have the | secret keys of them. I further assume that (a) a member-no-more takes | his secret key with him and (b) the server may be hacked but the hacker | should not be able to read the documents (but may corrupt/delete them). | | So far, so good. Now a user leaves a group. As the server is not | able to decrypt files and we don't want someone to decrypt 1000 files | of a group and re-encrypt them again with the members left, it would | be possible to just encrypt the already-crypted file again with the | new group of the remaining members (adding sort of a second armor). | Despite this being quite stressing for users if a file has some-20 | armors, I did not come up with an idea for adding *new* members to a | group | | | Well, maybe I'm already on the wrong track for this issue, so I | appreciate any suggestions or hints to sites/papers discussing these | problems. | | | Regards, | | Birger Tödtmann | | - | The Cryptography Mailing List | Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why we spent a decade+ building strong crypto security
On Sun, Nov 17, 2002 at 11:29:59PM -0800, John Gilmore wrote: | Now's a great time to deploy good working encryption, everywhere you | can. Next month or next year may be too late. And even honest ISPs, | banks, airlines (hah), etc, may be forced by law or by secret pressure | to act as government spies. Make your security work end-to-end. | | Got STARTTLS? | Got IPSEC? | Got SSH? I've done up a very short web page explaining how to use STARTTLS for opportunitistic email encryption between servers running postfix. http://www.homeport.org/~adam/starttls.html If you have STARTTLS enabled for client authentication, it should take less than 5 minutes to set it up for server-server. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Workshop on HCI and Security at CHI2003
I think that the intersection of usability and security is of tremendous import, and wanted to share an under-advertised sort of workshop announcement: http://www.acm.org/sigchi/ The conference home page is http://www.chi2003.org/ The workshop page is http://www.iit.nrc.ca/~patricka/CHI_2003/HCISEC/workshop.html I thought that the workshop info would be accessible from the conference site, but that appears not to be the case (at least not yet). Feel free to forward the URL to anyone else you think might be interested. Since it's at CHI, I expect we'll get plenty of people from that community, but we also really want attendees from the security community as well. - Chris - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: patent free(?) anonymous credential system pre-print
On Tue, Nov 05, 2002 at 05:15:25PM -0800, bear wrote: | I remember having exactly your reaction (plus issues about patenting | math and the USPTO being subject to coercion/collusion from the NSA | and influence-peddling and so on...) when the RSA patent issued - but | RSA is free now, and RSA security has not made that much money on the | cipher itself. And frankly, I don't think that having it be free much | earlier, given the infrastructure and implementation issues, would | really have made that much of a difference. Note that there are | *still* a lot of important court decisions about asymmetric encryption | that haven't happened yet, and it was only profitable (due to | e-commerce) for the last couple years of the patent's run. Actually, I think the RSA patent did make a difference: It caused PGP to 1) hit a wall of possibly justified FUD that delayed deployment and 2) change its public-key cipher suite in a non-interoperable way. As such, the patent did *exactly* what patents are intended to do, namely prevented others from using their system. Ideally, a patent allows the inventor to get people to pay to use their system, but in reality, we all just invent around them, and sometimes pay for them. But if the patented ideas are not so compelling that you can't live without them, you can't expect to make a lot of money. Phillips, the inventor of the CD, makes this decision easy. See http://www.licensing.philips.com/ or http://www.licensing.philips.com/licensees/conditions/cd/ You want to make a cd player? 25k + 2% of the net selling price. Sign this 3 page simple PDF and mail it to us, we'll countersign and send it back. Such a program reduces FUD and especially transaction costs around a patent enourmously. It may also leave a heck of a lot of money on the table. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Windows 2000 declared secure
On Sat, Nov 02, 2002 at 08:14:38PM -0600, Jim Hughes wrote: | One Comment | | On Sat, 2002-11-02 at 16:48, Adam Shostack wrote: | | Actually, I think it is. I don't think that Linux would pass EAL4; as | you've pointed out, that requires a documented and followed QA | process. Would any of the BSDs? (I know NAILabs has done stuff on | FreeBSD, but I'm not sure where it stands.) How does SELinux stack up | here? | | How about Mac OX-X GO APPLE! Yea! Is MacOS X EAL4? -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Windows 2000 declared secure
On Sat, Nov 02, 2002 at 11:54:36AM -0500, Jonathan S. Shapiro wrote: | The word moderate here is very unfortunate. In reading such | statements, one needs to understand a bit of subtext. The Common | Criteria community is very concerned about the possibility that people | will perceive assurance as impossibly difficult. In consequence, there | has been a tendency to a form of grade inflation. The effectiveness of | the levels is modestly exaggerated, and the importance of going for | higher levels is grossly understated. | | One unfortunate consequence is that NSA has seen no need to publish | guidelines on performing higher-level evaluations, because their has | been no demand. Could you define 'importance' here? Given a lack of demand, what are you using as criteria? How can we translate that into something that's important to buyers? Or otherwise convince the buyers of systems to demand better? (Leading to NSA publishing those higher level eval guidelines, etc.) Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Windows 2000 declared secure
On Sat, Nov 02, 2002 at 03:12:51PM -0500, Jonathan S. Shapiro wrote: | On Sat, 2002-11-02 at 13:31, Adam Shostack wrote: | On Sat, Nov 02, 2002 at 11:54:36AM -0500, Jonathan S. Shapiro wrote: | | The effectiveness of | | the levels is modestly exaggerated, and the importance of going for | | higher levels is grossly understated. | | | | One unfortunate consequence is that NSA has seen no need to publish | | guidelines on performing higher-level evaluations, because their has | | been no demand. | | Could you define 'importance' here? Given a lack of demand, what are | you using as criteria? How can we translate that into something | that's important to buyers? Or otherwise convince the buyers of | systems to demand better? (Leading to NSA publishing those higher | level eval guidelines, etc.) | | Apologies once again for the length of my reply. The issues are both | complicated and political. I also need to preface this by saying that I | am an active participant in the dialog around this issue. My usual role | is poking sharp sticks into people's eyes, so please read what I have to | say skeptically. Certainly, I found your long reply quite interesting, and annoyingly thought provoking, as I was all set to start flaming you. ;) | Context: There are international mutual-recognition treaties covering | EAL4 and below, so if you get an EAL4 evaluation in Germany, it's | accepted as binding in the US. Above EAL4 there is no mutual | recognition. From talking to various assurance evaluators (current and | former) and also to people within NSA, the alleged rationale behind this | is in two parts: | | (1) There is a perception that commercial products won't | seek higher evaluation, so there has been no real pressure | to push the treaties beyond this. | (2) There is a perception that products seeking assurance | above EAL4 are likely to be targeted primarily at military | and/or sensitive applications. No country wants to be in the | position of being treaty-obligated to accept assurance from | another country about militarily sensitive materials. | | Given that an EAL4 certification can fairly be characterized as nowhere | near good enough for serious commercial use today, I think it is fair | to harshly criticize these rationales as rather thin rationalizations. Here I'd like to disagree. Unfortunately, EAL4 level stuff is considered good enough for serious deployment today. Witness the US Navy's choice of OS. Perhaps this is because people haven't learned to tally up cost of ownerships properly. Perhaps its because security is not yet a requirement for commercial use. But, as you point out, there is no one agitating in the commercial space to fix the issues that make EAL4 all we get. [...] | There is another subtext. One agenda of the evaluation community is to | get people in the habit of doing evaluations before they raise the | stakes. In order for this strategy to work, products have to pass the | evaluations. The de facto effect is a desire not to set too high a bar. | I personally disagree with this strategy, but even if I did I would | argue that EAL4 is not a barrier to any current commodity operating | system, and the US national interest is not served so long as the best Actually, I think it is. I don't think that Linux would pass EAL4; as you've pointed out, that requires a documented and followed QA process. Would any of the BSDs? (I know NAILabs has done stuff on FreeBSD, but I'm not sure where it stands.) How does SELinux stack up here? | When pressed, Brian Snow says that until somebody wants to actually do a | higher level evaluation, NSA cannot justify the expense of doing the | higher level guidelines, but that they could proceed with a higher | evaluation today using the older guidelines that were applied under | TCSEC. This is probably true, but it is not clear whether such an | evaluation would have any commercial value, because the quality of the | resulting evaluation is not characterized by a published standard of | practice. I am publicly on record as saying that EROS will attempt EAL7 Do you think that the buyers of these higher EALs actually know what they're getting? My reading of the commentary on Win2k getting certified is that most people don't know what an assurance level is, nor do they know that there are other ones.. | So the current state of affairs is that for levels above EAL4 the | evaluation must be performed with participants from the government of | the host country, and has no standing outside of the host country. I | suspect that someone achieving a successful EAL5 evaluation in the US | could claim EAL4 elsewhere under the treaties, but a US-achieved EAL5 | would not qualify a product to be submitted on, say, a German military | solicitation requiring an EAL5 certification. | | Note that the current policies have a curious effect. Companies pursue | evaluation primarily for the marketing benefit
Re: QuizID?
On Thu, Oct 17, 2002 at 02:39:55PM -0400, Rich Salz wrote: | Marc Branchaud wrote: | Any thoughts on this device? At first glance, it doesn't seem | particularly impressive... | | http://www.quizid.com/ | | Looks like hardware S/Key, doesn't it? | | If I could fool the user into entering a quizcode, then it seems like I | could get the device and the admin database out of sync and lock the | user out of the system. Aww, Rich, that trick never works! More seriously, most of the vendors will search forwards and back through the expected codes to make the attack less likely to work. (If authentication is centralized, searching backwards may not be a security risk.) I think the most interesting part of this is the unit looks cool, and its spun slightly differently than other tokens have been. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What email encryption is actually in use?
On Wed, Oct 02, 2002 at 02:56:39PM -0400, Steven M. Bellovin wrote: | While I generally am on board with this, I can see a situation where the | encryption overhead [and complexity] may be excessive [underpowered mail | servers administered by beginners] compared to the gains. | | The primary use of STARTLS for SMTP is for mail *submission*, not | relaying. That is, when clients (like Eudora) generate mail, they | submit it to an ISP or organizational SMTP server. If this server is | accessible from the Internet, it should require some sort of | authentication, to avoid becoming an open spam relay. This is | sometimes done by a password over a TLS-protected session. | | In other words, this isn't opportunistic encryption, and doesn't run | into the problem of random smtp server has a self-signed cert. The | client should be configured to know what cert to expect. Its seemingly easy to configure postfix to opportunisticly encrypt email. That may not be its primary use, and many of the pages describing how to set things up miss this, but In main.cf: smtp_use_tls = yes smtp_tls_note_starttls_offer = yes results in this is my mail headers saying: Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by H203.C220.tor.velocet.net (Postfix) with ESMTP id CC7593008F for adam Opportunisticly. The other guy accepts my cert at random. We're totally vulnerable to MITM. (Lucky points out in another thread that it would be great to have cert persistance, which can maybe be emulated by putting a really big number in the timeout: smtpd_tls_session_cache_timeout = 3600s He's right. But I'm not letting the best be the enemy of the good.) Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: employment market for applied cryptographers?
On Sun, Aug 18, 2002 at 01:46:09AM -0400, dmolnar wrote: | | | On Sat, 17 Aug 2002, John Kelsey wrote: | | Also, designing new crypto protocols, or analyzing old ones used in odd | ways, is mostly useful for companies that are offering some new service on | the net, or doing some wildly new thing. Many of the obvious new things | | I agree with this as far as crypto protocols go. But one thing to keep | in mind is that almost all protocols impact security, whether their | dsigners realize it or not. Especially protocols for file transfer, print | spooling, or reservation of resources. most of these are designed without | people identifying them as crypto protocols. | | Another thing that makes it worse -- composition of protocols. You can do | an authentication protocol and prove you're you. Then what? Does that | confer security properties upon following protocols, and if so what? Why does the CEO care? Is it economic to answer these questions? Do these questions terminate or go on forever? Do good security experts ever say its secure? Or do we keep finding new and better holes that require more engineering work to fix? As Eric used to say, all security is economics. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: employment market for applied cryptographers?
Hey, this is off-topic for DRM-punks! ;) more seriously: I think the fundamental issue is that crypto doesn't really solve many business problems, and it may solve fewer security problems. See Bellovin's work on how many vulnerabilities would be blocked by strong crypto. The buying public can't distinguish between well implemented and poorly implemented crypto; the snake oil faq has helped a lot, but now you need to distinguiish between well and poorly coded AES. Is there a business case for doing so, or should you just ship crap? AdamS On Fri, Aug 16, 2002 at 02:23:05AM +0100, Adam Back wrote: | On the employment situation... it seems that a lot of applied | cryptographers are currently unemployed (Tim Dierks, Joseph, a few | ex-colleagues, and friends who asked if I had any leads, the spate of | recent security consultant .sigs, plus I heard that a straw poll of | attenders at the codecon conference earlier this year showed close to | 50% out of work). | | Are there any more definitive security industry stats? Are applied | crypto people suffering higher rates of unemployment than general | application programmers? (From my statistically too small sample of | acquaintances it might appear so.) | | If this is so, why is it? | | - you might think the physical security push following the world | political instability worries following Sep 11th would be accompanied | by a corresponding information security push -- jittery companies | improving their disaster recovery and to a lesser extent info sec | plans. | | - governments are still harping on the info-war hype, national | information infrastructure protection, and the US Information Security | Czar Clarke making grandiose pronouncements about how industry ought | to do various things (that the USG spent the last 10 years doing it's | best to frustrate industry from doing with it's dumb export laws) | | - even Microsoft has decided to make a play of cleaning up it's | security act (you'd wonder if this was in fact a cover for Palladium | which I think is likely a big play for them in terms of future control | points and (anti-)competitive strategy -- as well as obviously a play | for the home entertainment system space with DRM) | | However these reasons are perhaps more than cancelled by: | | - dot-com bubble (though I saw some news reports earlier that though | there is lots of churn in programmers in general, that long term | unemployment rates were not that elevated in general) | | - perhaps security infrastructure and software upgrades are the first | things to be canned when cash runs short? | | - software security related contract employees laid off ahead of | full-timers? Certainly contracting seems to be flat in general, and | especially in crypto software contracts look few and far between. At | least in the UK some security people are employed in that way (not | familiar with north america). | | - PKI seems to have fizzled compared to earlier exaggerated | expectations, presumably lots of applied crypto jobs went at PKI | companies downsizing. (If you ask me over use of ASN.1 and adoption | of broken over complex and ill-defined ITU standards X.500, X.509 | delayed deployment schedules by order of magnitude over what was | strictly necessary and contributed to interoperability problems and I | think significantly to the flop of PKI -- if it's that hard because of | the broken tech, people will just do something else.) | | - custom crypto and security related software development is perhaps | weighted towards dot-coms that just crashed. | | - big one probably: lack of measurability of security -- developers | with no to limited crypto know-how are probably doing (and bodging) | most of the crypto development that gets done in general, certainly | contributing to the crappy state of crypto in software. So probably | failure to realise this issue or perhaps just not caring, or lack of | financial incentives to care on the part of software developers. | Microsoft is really good at this one. The number of times they | re-used RC4 keys in different protocols is amazing! | | | Other explanations? Statistics? Sample-of-one stories? | | Adam | -- | yes, still employed in sofware security industry; and in addition have | been doing crypto consulting since 97 (http://www.cypherspace.net/) if | you have any interesting applied crypto projects; reference | commissions paid. -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Call for Papers, WORKSHOP ON PRIVACY ENHANCING TECHNOLOGIES 2003
Please re-distribute as appropriate... - Forwarded message from Roger Dingledine [EMAIL PROTECTED] - CALL FOR PAPERS WORKSHOP ON PRIVACY ENHANCING TECHNOLOGIES 2003 Mar 26-28 2003 Dresden, Germany Hotel Elbflorenz Dresden http://www.petworkshop.org/ Privacy and anonymity are increasingly important in the online world. Corporations and governments are starting to realize their power to track users and their behavior, and restrict the ability to publish or retrieve documents. Approaches to protecting individuals, groups, and even companies and governments from such profiling and censorship have included decentralization, encryption, and distributed trust. Building on the success of the first anonymity and unobservability workshop (held in Berkeley in July 2000) and the second workshop (held in San Francisco in April 2002), this third workshop addresses the design and realization of such privacy and anti-censorship services for the Internet and other communication networks. These workshops bring together anonymity and privacy experts from around the world to discuss recent advances and new perspectives. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of privacy technologies, as well as experimental studies of fielded systems. We encourage submissions from other communities such as law and business that present their perspectives on technological issues. As in past years, we will publish proceedings after the workshop. Suggested topics include but are not restricted to: * Efficient (technically or economically) realization of privacy services * Techniques for censorship resistance * Anonymous communication systems (theory or practice) * Anonymous publishing systems (theory or practice) * Attacks on anonymity systems (eg traffic analysis) * New concepts in anonymity systems * Protocols that preserve anonymity/privacy * Models for anonymity and unobservability * Models for threats to privacy * Novel relations of payment mechanisms and anonymity * Privacy-preserving/protecting access control * Privacy-enhanced data authentication/certification * Profiling, data mining, and data protection technologies * Reliability, robustness, and attack resistance in privacy systems * Providing/funding privacy infrastructures (eg volunteer vs business) * Pseudonyms, identity, linkability, and trust * Privacy, anonymity, and peer-to-peer * Usability issues and user interfaces for PETs * Policy, law, and human rights -- anonymous systems in practice * Incentive-compatible solutions to privacy protection * Economics of privacy systems * Fielded systems and techniques for enhancing privacy in existing systems IMPORTANT DATES Submission deadline December 2, 2002 Acceptance notification February 7, 2003 Camera-ready copy for preproceedings March 7, 2003 Camera-ready copy for proceedings April 28, 2003 CHAIRS Roger Dingledine, The Free Haven Project, USA Andreas Pfitzmann, Dresden University of Technology, Germany PROGRAM COMMITTEE Alessandro Acquisti, SIMS, UC Berkeley, USA Stefan Brands, Credentica, Canada Jean Camp, Kennedy School, Harvard University, USA David Chaum, USA Richard Clayton, University of Cambridge, England Lorrie Cranor, ATT Labs - Research, USA Roger Dingledine, The Free Haven Project, USA (program chair) Hannes Federrath, Freie Universitaet Berlin, Germany Ian Goldberg, Zero Knowledge Systems, Canada Marit Hansen, Independent Centre for Privacy Protection Schleswig-Holstein, Germany Markus Jakobsson, RSA Laboratories, USA Brian Levine, University of Massachusetts at Amherst, USA David Martin, University of Massachusetts at Lowell, USA Andreas Pfitzmann, Dresden University of Technology, Germany Matthias Schunter, IBM Zurich Research Lab, Switzerland Andrei Serjantov, University of Cambridge, England Adam Shostack, Zero Knowledge Systems, Canada Paul Syverson, Naval Research Lab, USA PAPER SUBMISSIONS Submitted papers must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font and reasonable margins), and at most 20 pages total. Committee members are not required to read the appendices and the paper should be intelligible without them. The paper should start with the title, names of authors and an abstract. The introduction should give some background and summarize the contributions of the paper at a level appropriate for a non-specialist reader. During the workshop
Re: IP: SSL Certificate Monopoly Bears Financial Fruit
On Fri, Jul 12, 2002 at 11:18:12AM -0400, Trei, Peter wrote: | I'd rather not state the exact figures. A search of SEC filings may or | may not turn up further details. | | And who actually owns these numerous trusted roots? | | I am not sure I understand the question. | | --Lucky | | I think I do. A 'second hand' root key seems to have some | trust issues - the thing you are buying is the private half | of a public key pair but that's just a piece of information. | How can you be sure that, as purchaser, you are the *only* | possessor of the key, and no one else has another copy (the | seller, for example)? Who cares? If I can get a key thats in the main browsers for 90% off, who cares if other people have it? I understand that getting the public half of the 2 main browsers will run you about $250k in fees, plus all the setup work. If I can buy a slightly used Ncipher box whose public key bits are in the browsers for a 10th to a 5th of that, the extra copies of the bits aren't all that worrisome to me. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ross's TCPA paper
On Mon, Jun 24, 2002 at 08:15:29AM -0400, R. A. Hettinga wrote: Status: U Date: Sun, 23 Jun 2002 12:53:42 -0700 From: Paul Harrison [EMAIL PROTECTED] Subject: Re: Ross's TCPA paper To: R. A. Hettinga [EMAIL PROTECTED] The important question is not whether trusted platforms are a good idea, but who will own them. Purchasing a TCP without the keys to the TPM is like buying property without doing a title search. Of course it is possible to _rent_ property from a title holder, and in some cases this is desirable. I would think a TCP _with_ ownership of the TPM would be every paranoid cypherpunk's wet dream. A box which would tell you if it had been tampered with either in hardware or software? Great. Someone else's TCP is more like a rental car: you want the rental company to be completely responsible for the safety of the vehicle. This is the economic achilles heal of using TCPA for DRM. Who is going to take financial responsibility for the proper operation of the platform? It can work for a set top box, but it won't fly for a general purpose computer. In general, I'm very fond of this sort of ownership analysis. If I have a TCPA box running my software, and thinking that its mine, how do I know there isn't one more layer? Leave it off, and my analysis is simpler. I suspect that verifying ownership of the TPM will be like verifying ownership of property in modern Russia: There may be a title that looks clean. But what does the mafia think? What about the security services? There may even be someone with a pre-Bolshevik title floating around. Or a forgery. Hard to tell. It's annoying to have one's transaction costs pushed up that high. I can get very high quality baseline software today. What I need for my cypherpunk wet dreams is ecash, and a nice anonymizing network. What I also need is that the general purpose computing environment stay free of control points, in Lessig sense. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RC4 [was: RE: Passport Passwords Stored in Plaintext]
On Sun, Oct 21, 2001 at 04:11:19PM -0700, Jeff Simmons wrote: | On Sunday 21 October 2001 02:52 pm, you wrote: | | Designing protocols is a hard field, and | there seem to be lots of mistakes made when people use RC4. Is that | because its a bad cipher? No, its because people aren't used to | working with it. Because of that, I tend to look askew at RC4 based | systems. | | Are you referring to RC4 in particular, or streaming cyphers in | general? And if it's just RC4, do you have a streaming cypher that | you prefer to it? Good question; the problems with RC4 have been a mix of not knowing how to use stream ciphers (Don't cross the streams!) and issues with RC4 (needing to discard the first little chunk of stream as it gets up to speed. I've seen people go to RC4 for speed more than for its stream cipher nature. I tend to push towards block ciphers, simply because we in the public world have a lot more experience using them. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RC4 [was: RE: Passport Passwords Stored in Plaintext]
On Thu, Oct 11, 2001 at 01:31:36AM -0700, [EMAIL PROTECTED] wrote: | On 8 Oct 2001, at 11:37, Ray Dillinger wrote: | In which case, what you've got isn't RC4 anymore | | You do not understand encryption. | | RC4 is an encryption method, that needs to be part of a | protocol. The protocol can be designed correctly or | incorrectly, but either way it is still a protocol that uses | RC4. | | In the usual protocols that contain RC4, each session has a | new transient session key. The fact that RC4 leaks a small | amount of information about that session key is unimportant | in such protocols. | | RC4 is like a brick that can be used to build a house. I'd say that RC4 is like one of those cool, semi-opaque glass bricks. Not in the sense that it is weak (you can put quite a bit of load on a wall of those) but in the sense that it is different than your typical dried-mud sort of brick. Designing protocols is a hard field, and there seem to be lots of mistakes made when people use RC4. Is that because its a bad cipher? No, its because people aren't used to working with it. Because of that, I tend to look askew at RC4 based systems. Adam -- It is seldom that liberty of any kind is lost all at once. -Hume - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
