Re: Outreach Volunteers Needed - Content Control is a Dead End
On Wed, Aug 29, 2001 at 11:19:31PM -0400, Dan Geer wrote: | > Content control is a dead end. | You only get an even number of {privacy, copyright} -- either the | owner of information controls how it is used or he does not. Either | you embrace copyright-and-privacy, or you embrace neither. | | It really is time to be careful what you ask for. Hi Dan, I really don't follow this argument. If you have a 'strong' system of copyright control with data being tied to users, it becomes very difficult to have privacy. If you have a strong privacy system (I'm using privacy in the anonymity sense), then it becomes hard to prevent me from sending you Metallica songs anonymously. I agree its time to be careful what you ask for, but I don't see how to build strong copyright controls in a society with privacy. 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]
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]
Privacy Enhancing Technologies 2002
Privacy Enhancing Technologies 2002 April 14-15, 2002 San Francisco, CA Call for Participation Registration for Privacy Enhancing Technologies 2002 is now open. Details and online registration can be found at http://www.pet2002.org/ along with the program and hotel information. 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 (LNCS 2009, held in Berkeley in July 2000), PET2002 addresses the design and realization of such anonymity and anti-censorship services for the Internet and other communication networks. The program consists of peer reviewed papers, an invited talk, and a panel discussion on policy. The proceedings will be published in the Springer-Verlag Lecture Notes in Computer Science series. Preliminary PET2002 program: David Chaum: Invited Talk "Privacy-enhancing technologies for the Internet, II: Five years later" Ian Goldberg "Detecting Web Bugs With Bugnosis: Privacy Advocacy Through Education" Adil Alsaid, David Martin "Private authentication" Martin Abadi "Towards an Information Theoretic Metric for Anonymity" Andrei Serjantov, George Danezis "Towards Measuring Anonymity" Claudia Diaz, Stefaan Seys, Joris Claessens, Bart Preneel "The Platform for Enterprise Privacy Practices -- Privacy-enabled Management of Customer Data" G{\"u}nter Karjoth, Matthias Schunter, Michael Waidner "Privacy Enhancing Profile Disclosure" Peter Dornbach, Zoltan Nemeth "Privacy Enhancing Service Architectures" Tero Alamaki, Margareta Bjorksten, Peter Dornbach, Casper Gripenberg, Norbert Gyorbiro, Gabor Marton, Zoltan Nemeth, Timo Skytta, Mikko Tarkiainen Policy Panel, moderated by John Borking "Dummy Traffic Against Long Term Intersection Attacks" Oliver Berthold, Heinrich Langos "Protecting Privacy during On-line Trust Negotiation" Kent E. Seamons, Marianne Winslett, Ting Yu, Lina Yu, Ryan Jarvis "Prototyping an Armored Data Vault: Rights Management on Big Brother's Computer" Alex Iliev, Sean Smith "Preventing Interval-based Inference by Random Data Perturbation" Yingjiu Li, Lingyu Wang, and Sushil Jajodia "Fingerprinting Websites Using Traffic Analysis" Andrew Hintz "A Passive Attack on the Privacy of Web Users Using Standard Log Information" Thomas Demuth "Covert Messaging Through TCP Timestamps" John Giffin, Rachel Greenstadt, Peter Litwack, Richard Tibbetts "Almost Optimal Private Information Retrieval" Dmitri Asonov, Johann-Christoph Freytag "Unobservable Surfing on the World Wide Web: Is Private Information Retrieval an alternative to the MIX based Approach?" Dogan Kesdogan, Mark Borning, Michael Schmeink (please distribute widely) - 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: 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]
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, AT&T 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 th
Re: dangers of TCPA/palladium
On Mon, Aug 12, 2002 at 12:38:42AM -0700, Brian A. LaMacchia wrote: | | > I don't know for sure whether Microsoft is going to do this, or is | > even capable of doing this. It would be a cool idea. It also isn't | > sufficient to address all questions about deliberate malfeasance. | > Back in the Clipper days, one question about Clipper's security was | > "how do we know the Clipper spec is secure?" (and the answer actually | > turned out to be "it's not"). But a different question was "how do | > we know that this tamper-resistant chip produced by Mykotronix even | > implements the Clipper spec correctly?". | > | > The corresponding questions in Palladium are "how do we know that the | > Palladium specs (and Microsoft's nub implementation) are secure?" and | > "how do we know that this tamper-resistant chip produced by a | > Microsoft contractor even implements the Palladium specs correctly?". | | There are two parts to answering the first question: | | 1) People (many people, the more the merrier) need to understand the code | and what it does, and thus be in a position to be able to make an informed | decision about whether or not they trust it. | 2) People reviewing the code, finding security flaws, and then reporting | them so that we can fix them | | These are two very different things. I don't think that anyone should count | on the goodwill of the general populace to make their code proveably secure. | I think that paying people who are experts at securing code to find exploits | in it must be part of the development process. How are these different? If I'm understanding the code to decide if I trust it (item 1), it seems to me that I must do at least 2A and 2B: 2C is optional :) Or are you saying that (2) is done by internal folks, and thus is a smaller set than (1)? 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: dangers of TCPA/palladium
On Tue, Aug 13, 2002 at 11:55:24PM -0700, Brian A. LaMacchia wrote: | Adam Shostack <[EMAIL PROTECTED]> wrote: | > On Mon, Aug 12, 2002 at 12:38:42AM -0700, Brian A. LaMacchia wrote: | >> There are two parts to answering the first question: | >> | >> 1) People (many people, the more the merrier) need to understand the | >> code and what it does, and thus be in a position to be able to make | >> an informed decision about whether or not they trust it. | >> 2) People reviewing the code, finding security flaws, and then | >> reporting them so that we can fix them | >> | >> These are two very different things. I don't think that anyone | >> should count on the goodwill of the general populace to make their | >> code proveably secure. I think that paying people who are experts at | >> securing code to find exploits in it must be part of the development | >> process. | > | > How are these different? If I'm understanding the code to decide if I | > trust it (item 1), it seems to me that I must do at least 2A and 2B: | > 2C is optional :) | > | > Or are you saying that (2) is done by internal folks, and thus is a | > smaller set than (1)? | | Yeah, I wasn't very clear here, was I? What I was trying to say was that | there's a difference between understanding how a system behaves technically | (and deciding whether that behavior is correct from a technical perspective) | and understanding how a system behaves from a policy perspective (e.g. | social process & impact). Those are two completely different questions. 2) | is all about verifying that Palladium hardware and software components | technically operates as it is spec'd to. 1) is about the larger issue of | how Palladium systems interact with service providers (CAs, TTPs), what | processes one goes through to secure PII, etc. The two groups of people | looking at 1) and 2) have non-zero intersection but are not equal. And, | just to be clear, 2) is *not* done only by internal folks, but I expect that | the size of the set of people competent to do 2) is significantly smaller | than the size of the set of people who need to think about 1). :-) Hmm. Lessig would argue that they are not two different questions, but tightly coupled ones. Have you read his books? I found them worth the time, and a fun read to boot. I had at least one deep aha moment per book. 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]
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: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
On Mon, Sep 16, 2002 at 09:57:13PM -0500, Ted Lemon wrote: | >Relevence to the Pd debate is that banks may in future insist on remote | >attestation of users' software (however practically possible that is) | >so | >that they can attempt to dump yet more liability on their users | >("Ladies and | >gentlemen of the jury, Mr Doe's claim that he did not authorise this | >transfer to a Caribbean account is obviously fraudulent as his Fritz | >chip | >proved to us that his system had not been compromised"...) | | Banks typically aren't that sophisticated. Demand for this capability | probably will not materialize in time to save Pd, although there are | probably people working for banks who will claim that they want it. As soon as you start doing this, it becomes clear what a nightmare it is for the bank to try to learn anything about its customers. Firstly, its customers are diverse, and the breadth of information you get is large. Second, what you learn falls into three categories "known good," "unknown," and "known bad." Smart security people want to say what is not explicitly ok is bad. That means most of your customers have bad software, and lots of it. Do you deny them access? Ask that they upgrade? Are you responsible if their upgrade breaks things? Now, lets say you don't tell the customer with known bad software to go away, because you value their business. Are you now culpable in some way? After all, you *knew* that client was comprimised... PS: Hi Ashish! :) -- "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: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
On Tue, Sep 17, 2002 at 01:07:43PM -0700, [EMAIL PROTECTED] wrote: | >Now, lets say you don't tell the customer with known bad | >software to go away, because you value their business. Are you now | >culpable in some way? After all, you *knew* that client was | >comprimised... | | As far as I know, banks assume that a certain percentage of their | transactions will be bad and build that cost into their business | model. Credit and ATM cards and numbers are as far from secure as | could be, far less secure than somebody doing online transactions | from a Wintel machine on an unencrypted connection, let alone an | encrypted one. Until somebody takes full advantage of the current | system and steals a few trillion dollars in one day, the problems are | easier to deal with than a solution. Until that happens, there's no | reason for banks to go through the pain of dealing with or requiring | Pd. And after that happens, and the Fed declares a roll-back of a day, there still won't be a reason. Here's a fun thought experiment: How much money could you steal and launder before you cause a catastophic melt-down of the financial privacy system, a la the way civil liberties have been set aside in the wake of 9/11? 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: Real-world steganography
On Mon, Sep 30, 2002 at 07:31:19PM -0700, Paul Krumviede wrote: | --On Tuesday, 01 October, 2002 13:54 +1200 Peter Gutmann | <[EMAIL PROTECTED]> wrote: | | >I recently came across a real-world use of steganography which hides extra | >data in the LSB of CD audio tracks to allow (according to the vendor) the | >equivalent of 20-bit samples instead of 16-bit and assorted other | >features. According to the vendors, "HDCD has been used in the recording | >of more than 5,000 CD titles, which include more than 250 Billboard Top | >200 recordings and more than 175 GRAMMY nominations", so it's already | >fairly widely deployed. ... | i've seen comments in reviews of professional CD mastering | gear that there are other, seemingly preferred, technologies, | although i've never found details of them. The two that spring to mind are HDCD and XRCD. I'd never dug into how they're recorded, being much more interested in playing with things closer to the output stage, like speaker resonance control and electrical hum elimination... 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
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: 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
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: 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]
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: Workshop on HCI and Security at CHI2003
Since posting, I got a better web page: http://www.iit.nrc.ca/~patricka/CHI2003/HCISEC/index.html Adam On Mon, Nov 11, 2002 at 09:54:51AM -0500, Adam Shostack wrote: | 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] -- "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]
Implementation guides for DH?
I'm looking for a list of common implementation flaws in DH. Things like: How to check the key the other side sends, what are acceptable values for p, etc? Any pointers? 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: text/reference on computer security?
Security Engineering, Ross Anderson. I think Rob Slade put it best in his review: RS> "I have often been asked, in regard to these reviews, whether RS> there are, in fact, any books that I like. Well, I like this one. RS> If you are involved with security and you haven't read it, you RS> should." http://victoria.tc.ca/int-grps/books/techrev/bkseceng.rvw Adam On Thu, Jan 02, 2003 at 01:09:41PM -0500, John R Levine wrote: | A friend asks if there's any good books on security for programmers. Two | years ago Michael Johnson was working on one, and it's even in Macmillan's | catalog, but it doesn't look like it actually came out. Any other | suggestions? | | Regards, | John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies", | Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner | "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web | | -- Forwarded message -- | | Can any of you recommend a good text or reference on computer security? | I'm looking for something targeted at the system/application developer | more than the network administrator, the kind of book you wish more people | at Microsoft had read. | | | | - | 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: 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: Keep it secret, stupid!
On Mon, Jan 27, 2003 at 07:42:25PM -0600, Neil Johnson wrote: | | My favorite lock is the electronic lock I saw in a data center. To make it | easier to leave the room, they installed a motion detector near the door to | unlock the door when you walked toward the door. That way you didn't need to | badge out (why they considered this a bad thing, I don't know). Probably fire or safety codes, it seems pretty standard. | Which is all well and good until you notice that there is a 1/2" gap along the | bottom of the door. Take a dowel rod, tape a piece of cardboard to the edge | (like a flag), stick it under the door, rotate the dowel a couple of times to | trigger the motion sensor, and ta-da! you are in. This is also standard. Best way is paper under the door, and the best cheap fix I've seen involves weather striping bottom of the door so you can't get the paper through easily. (the frame needs to be staggered, so that paper doesn't go through at all, but that would lead to a risk of tripping people at the floor.) 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: A talk on Intellectual Property and National Defense
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. To expand a little: By authorized boot sequence, I mean that I can say only software signed by one of these keys may load. Without that, I, or an attacker, can load arbitrary software. By secure remote attestation I mean that the reference monitor has a key, which can't be exported, which can sign attestations as to what software keys are allowed to load sw on my system. Without this, the copyright contoller can't decide if they can rely on your system to act as their agent. Without software versioning attestation, I can just keep my vulnerable copy of the OS around, root it, and run the software of my choice on it. These are not requirements for me to control my own system, but they are needed to prevent me from tinkering. Adam On Tue, Feb 04, 2003 at 09:29:34AM -0500, Dave Farber wrote: | | I sent this to my IP list. One of the major points I made here is that | secure systems (and I am not calling Palladium a secure system) can host DRM | software. So one can have secure systems in which case it will tape either | law or strong market pressure to not have DRM else we can not have secure | systems in which case DRM will most likely be broken endlessly. | | Comments? | | Dave | | Ps please excuse the inability to hear the questions from the floor, I | recorded it will a small digital recorder on the podium. | | From: Dave Farber <[EMAIL PROTECTED]> | Subject: [IP] Streaming REAL Audio now available of my HCSS speech with | To: ip <[EMAIL PROTECTED]> | Date: Wed, 29 Jan 2003 03:27:06 -0500 | Reply-To: [EMAIL PROTECTED] | introduction by John Seely Brown | | There is Real audio version of my Distinguished Lecture | given at the Hawaii International Conference on System Sciences | this Jan in Kona, Hawaii. | | The introduction was given by John Seely Brown | (great intro). The title is Intellectual Property and National Security. | | http://www.vortex.com/rmf/djf-hicss-2003.ram | | PowerPoint available on request. | | Enjoy, | | Dave | | | -- | | | | - | 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: 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]
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: 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]
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: 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: MPAA's drive for state laws hits bump in Massachusetts
On Wed, Apr 02, 2003 at 11:33:44PM -0500, R. A. Hettinga wrote: | Last paragraph says it all, I think... | | Cheers, | RAH | --- | That sentiment, along with those expressed at the Wednesday hearing, does | not bode well for the future of the MPAA legislation in Massachusetts, | according to one software industry expert in attendance. | | "When you've got Verizon, the American Electronics Association, Harvard Law | School and the ponytail gang all against you, then you've got a problem," | he said. | -- Someone should get ponytailgang.org :) 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]