Re: Maybe It's Snake Oil All the Way Down
Eric Murray [EMAIL PROTECTED] writes: Too often people see something like Peter's statement above and say oh, it's that nasty ASN.1 in X.509 that is the problem, so we'll just do it in XML instead and then it'll work fine which is simply not true. The formatting of the certificates is such a minor issue that it is lost in the noise of the real problems. And Peter publishes a fine tool for printing ASN.1, so the human readable argument is moot. Actually, the ASN.1 part is a major factor in the X.509 interoperability problems. Different cert vendors include different extensions, or different encodings. They put different information into different parts of the certificate (or indeed the same information into different parts). Does the FQDN for a server cert belong in the DN or some extension? What about the email address for a user cert? Note that there isn't a real running global PKI using SPKI or PGP either. That's a different problem (namely that the big guys like RSA Security, Microsoft, and Verisign don't sell PGP-enabled software or PGP certificates). PGP's problem is an integration problem, making it easy to use for non-techies. That has been the barrier to entry for PGP. The largest problem with X.509 is that various market/political forces have allowed Verisign to dominate the cert market and charge way too much for them. There is software operable by non-cryptographers that will generate reasonable cert reqs (it's not standard Openssl) but individuals and corporations alike balk at paying $300-700 for each cert. (yes I know about the free individual certs, the failure of S/MIME is a topic for another rant). This is only part of the problem... It is not all of it. Indeed the cost (both in money, time, and headache) has always been a barrier to entry. I don't believe that market or political forces are the largest problem with X.509 I will certainly agree that the cost is a major impediment. The question is: how do we convince M$ and Netscape to include something else in their software? If it's not supported in IE, then it wont be available to the vast majority of users out there. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Maybe It's Snake Oil All the Way Down
Eric Rescorla [EMAIL PROTECTED] writes: This isn't really true in the SSL case: To a first order, everyone ignores any extensions (except sometimes the constraints) and uses the CN for the DNS name of the server. Except some CAs make certs that can only work as an SSL server and not an SSL client, or don't work with certain verifiers, or can't be parsed right, or have the commit-bit set on some extensions. It's been a major pain in a problem that I'm working on -- not all vendor's certs work properly. -Ekr -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Run a remailer, go to jail?
Peter, I'll see if I can get there. I'm not sure I can. But I know a number of other MIT-types who are considering going. If I can go I'll try to keep notes. If I can't go, then hopefully someone else can take some notes. -derek Trei, Peter [EMAIL PROTECTED] writes: Derek, etal If you (or anyone) goes, I'm sure we'd all appreciate some notes on what transpired. I understand 17 different bills are being considered at this hearing, so don't blink or you may miss it. Peter Trei -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Run a remailer, go to jail?
Dave Emery [EMAIL PROTECTED] writes: For those on this list in the Boston area there is a hearing scheduled on the Mass Bill at 10 Am in Room 222 of the Mass State House in Boston. 10am on what date? -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Run a remailer, go to jail?
Peter, I'll see if I can get there. I'm not sure I can. But I know a number of other MIT-types who are considering going. If I can go I'll try to keep notes. If I can't go, then hopefully someone else can take some notes. -derek Trei, Peter [EMAIL PROTECTED] writes: Derek, etal If you (or anyone) goes, I'm sure we'd all appreciate some notes on what transpired. I understand 17 different bills are being considered at this hearing, so don't blink or you may miss it. Peter Trei -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: responding to claims about TCPA
AARG!Anonymous [EMAIL PROTECTED] writes: I don't agree with this distinction. If I use a smart card chip that has a private key on it that won't come off, is that protecting me from third parties, or vice versa? If I run a TCPA-enhanced Gnutella that Who owns the key? If you bought the smartcard, you generated the key yourself on the smartcard, and you control it, then it is probably benefitting you. If the smartcard came preprogrammed with a certificate from the manufacturer, then I would say that it is protecting the third party from you. I wrote earlier that if people were honest, trusted computing would not be necessary, because they would keep their promises. Trusted computing allows people to prove to remote users that they will behave honestly. How does that fit into your dichotomy? Society has evolved a myriad The difference is proving that you are being honest to someone else vs. an application proving to YOU that it is being honest. Again, it is a question of ownership. There is the DRM side (you proving to someone else that you are being honest) vs. Virus Protection (an application proving to _you_ that it is being honest). -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Ross's TCPA paper
I, for one, can vouch for the fact that TCPA could absolutely be applied to a DRM application. In a previous life I actually designed a DRM system (the company has since gone under). In our research and development in '96-98, we decided that you need at least some trusted hardware at the client to perform any DRM, but if you _did_ have some _minimal_ trusted hardware, that would provide a large hook to a fairly secure DRM system. Check the archives of, IIRC, coderpunks... I started a thread entitled The Black Box Problem. The issue is that in a DRM system you (the content provider) wants to verify the operation of the client, even though the client is not under your control. We developed an online interactive protocol with a sandbox environment to protect content, but it would certainly be possible for someone to crack it. Our threat model was that we didn't want people to be able to use a hacked client against our distributation system. We discovered that if we had some trusted hardware that had a few key functions (I don't recall the few key functions offhand, but it was more than just encrypt and decrypt) we could increase the effectiveness of the DRM system astoundingly. We thought about using cryptodongles, but the Black Box problem still applies. The trusted hardware must be a core piece of the client machine for this to work. Like everything else in the technical world, TPCA is a tool.. It is neither good nor bad; that distinction comes in how us humans apply the technology. -derek Lucky Green [EMAIL PROTECTED] writes: Anonymous writes: Lucky Green writes regarding Ross Anderson's paper at: Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? Anonymous raises a valid question. To hand Anonymous additional rope, I will even assure the reader that when questioned directly, the members of the TCPA will insist that their efforts in the context of TCPA are concerned with increasing platform security in general and are not targeted at providing a DRM solution. Unfortunately, and I apologize for having to disappoint the reader, I do not feel at liberty to provide the proof Anonymous is requesting myself, though perhaps Ross might. (I have no first-hand knowledge of what Ross may or may not be able to provide). I however encourage readers familiar with the state of the art in PC platform security to read the TCPA specifications, read the TCPA's membership list, read the Hollings bill, and then ask themselves if they are aware of, or can locate somebody who is aware of, any other technical solution that enjoys a similar level of PC platform industry support, is anywhere as near to wide-spread production as TPM's, and is of sufficient integration into the platform to be able to form the platform basis for meeting the requirements of the Hollings bill. Would Anonymous perhaps like to take this question? --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: Ross's TCPA paper
I, for one, can vouch for the fact that TCPA could absolutely be applied to a DRM application. In a previous life I actually designed a DRM system (the company has since gone under). In our research and development in '96-98, we decided that you need at least some trusted hardware at the client to perform any DRM, but if you _did_ have some _minimal_ trusted hardware, that would provide a large hook to a fairly secure DRM system. Check the archives of, IIRC, coderpunks... I started a thread entitled The Black Box Problem. The issue is that in a DRM system you (the content provider) wants to verify the operation of the client, even though the client is not under your control. We developed an online interactive protocol with a sandbox environment to protect content, but it would certainly be possible for someone to crack it. Our threat model was that we didn't want people to be able to use a hacked client against our distributation system. We discovered that if we had some trusted hardware that had a few key functions (I don't recall the few key functions offhand, but it was more than just encrypt and decrypt) we could increase the effectiveness of the DRM system astoundingly. We thought about using cryptodongles, but the Black Box problem still applies. The trusted hardware must be a core piece of the client machine for this to work. Like everything else in the technical world, TPCA is a tool.. It is neither good nor bad; that distinction comes in how us humans apply the technology. -derek Lucky Green [EMAIL PROTECTED] writes: Anonymous writes: Lucky Green writes regarding Ross Anderson's paper at: Ross and Lucky should justify their claims to the community in general and to the members of the TCPA in particular. If you're going to make accusations, you are obliged to offer evidence. Is the TCPA really, as they claim, a secretive effort to get DRM hardware into consumer PCs? Or is it, as the documents on the web site claim, a general effort to improve the security in systems and to provide new capabilities for improving the trustworthiness of computing platforms? Anonymous raises a valid question. To hand Anonymous additional rope, I will even assure the reader that when questioned directly, the members of the TCPA will insist that their efforts in the context of TCPA are concerned with increasing platform security in general and are not targeted at providing a DRM solution. Unfortunately, and I apologize for having to disappoint the reader, I do not feel at liberty to provide the proof Anonymous is requesting myself, though perhaps Ross might. (I have no first-hand knowledge of what Ross may or may not be able to provide). I however encourage readers familiar with the state of the art in PC platform security to read the TCPA specifications, read the TCPA's membership list, read the Hollings bill, and then ask themselves if they are aware of, or can locate somebody who is aware of, any other technical solution that enjoys a similar level of PC platform industry support, is anywhere as near to wide-spread production as TPM's, and is of sufficient integration into the platform to be able to form the platform basis for meeting the requirements of the Hollings bill. Would Anonymous perhaps like to take this question? --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Re: PKI: Only Mostly Dead
[EMAIL PROTECTED] (Peter Gutmann) writes:
For example the value
1234567890 taken in isolation could be anything from my ICQ number
to my shoe size in kilo-angstroms, but if you view it as the pair {
ICQ domain, locally unique number } then it makes sense
(disclaimer: I have no idea whether that's either a valid ICQ number
or my shoe size in kilo-angstroms).
It's clearly not your shoe size in kilo-angstroms, unless you have
MIGHTY large feet. According to 'units', that works out to 4860
inches.
-derek
--
Derek Atkins
Computer and Internet Security Consultant
[EMAIL PROTECTED] www.ihtfp.com
Re: PKI: Only Mostly Dead
[EMAIL PROTECTED] (Peter Gutmann) writes: It's clearly not your shoe size in kilo-angstroms, unless you have MIGHTY large feet. According to 'units', that works out to 4860 inches. Obviously it's my hat size then. I always knew you had a fat head ;) Peter. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available
Re: PKI: Only Mostly Dead
[EMAIL PROTECTED] (Peter Gutmann) writes:
For example the value
1234567890 taken in isolation could be anything from my ICQ number
to my shoe size in kilo-angstroms, but if you view it as the pair {
ICQ domain, locally unique number } then it makes sense
(disclaimer: I have no idea whether that's either a valid ICQ number
or my shoe size in kilo-angstroms).
It's clearly not your shoe size in kilo-angstroms, unless you have
MIGHTY large feet. According to 'units', that works out to 4860
inches.
-derek
--
Derek Atkins
Computer and Internet Security Consultant
[EMAIL PROTECTED] www.ihtfp.com
Re: PKI: Only Mostly Dead
[EMAIL PROTECTED] (Peter Gutmann) writes: It's clearly not your shoe size in kilo-angstroms, unless you have MIGHTY large feet. According to 'units', that works out to 4860 inches. Obviously it's my hat size then. I always knew you had a fat head ;) Peter. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available
Re: FreeSWAN Release 1.93 ships!
Note that to compile FreeS/WAN on Red Hat using the Red Hat kernel-source RPM you need to: rm include/linux/modules/*.ver before you 'make dep'. Otherwise you get module version brokenness. -derek Lucky Green [EMAIL PROTECTED] writes: The big question is: will FreeS/WAN latest release after some 4 or 5 years of development finally both compile and install cleanly on current versions of Red Hat Linux, FreeS/WAN's purported target platform? --Lucky, who is bothered by the fact that most his Linux using friends so far have been unable to get FreeS/WAN to even compile into a working kernel, while just about every *BSD distribution - and for that matter Windows XP - ship with a working IPSec implementation out-of-the-box. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Stewart Sent: Thursday, December 06, 2001 2:05 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: FreeSWAN Release 1.93 ships! From Claudia Schmeing [EMAIL PROTECTED]'s summary: http://lists.freeswan.org/pipermail/briefs/ = 1. Release 1.93 ships! === 1 post Dec 3 http://lists.freeswan.org/pipermail/users/2001-December/005632 .html A number of small improvements have been added to this release, which was shipped on-time. Some highlights: * Diffie-Hellman group 5 is now the first group proposed. * Two cases where fragmentation is needed will be handled better, thanks to these two changes The code that decides whether to send an ICMP complaint back about a packet which had to be fragmented, but couldn't be, has gotten smart enough that we now feel comfortable enabling it by default. and IKE (UDP/500) packets which were large enough to be fragmented used to be mishandled, with some of the fragments failing to bypass IPsec tunnels properly. This has been fixed; our thanks to Hans Schultz. * If Pluto gets more than one RSA key from DNS, it will now try each key. This will help when a system administrator replaces a key. * There is preliminary support for building RPMs. * SMP support is better. * The team has eliminated a vulnerability that might permit a denial of service attack. What can we expect from the next release? Henry Spencer writes: We are in the process of chasing down a couple of significant bugs (which have been there since at least 1.92 and possibly earlier), and we *might* ship another release quite shortly if we nail them down and fix them. If we don't, we won't. Barring that possibility, the next release is planned for the end of January; a more precise date will be announced shortly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available
Re: secure IRC/messaging successor
gale has scaling problems to large numbers of users, in particular for group messaging. -derek Eugene Leitl [EMAIL PROTECTED] writes: Gale http://www.gale.org/ seems a well thought out infrastructure. Is the consensus this is it, or have I missed any alternatives? TIA, -- Eugen* Leitl a href=http://www.lrz.de/~ui22204/;leitl/a __ ICBMTO : N48 10'07'' E011 33'53'' http://www.lrz.de/~ui22204 57F9CFD3: ED90 0433 EB74 E4A9 537F CFF5 86E7 629B 57F9 CFD3 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available
Re: Rijndael Hitachi
No, you're right. Medeco should certainly work on a better lock. Except there comes a point at which, relatively speaking, ALL doors are "glass" doors compared to the security of this new medeco++ lock. At which point no, it doesn't make sense to develop an even better lock until you come up with better doors. :) -derek "Arnold G. Reinhold" [EMAIL PROTECTED] writes: Derek Atkins adds: Why try to pick a Medeco when it's locking a glass door? :-) The fact that some people put Medeco's in glass doors, doesn't mean Medeco should never develop a better lock. Arnold Reinhold -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available
