Re: Is cryptography where security took the wrong branch?
In message [EMAIL PROTECTED], Ian Grigg [EMAIL PROTECTED] wrote: For example, he states that 28% of wireless networks use WEP, and 1% of web servers use SSL, but doesn't explain why SSL is a success and WEP is a failure :-) Actually, he does; slide 11 is titled Why has SSL succeeded?, and slide 23 is titled The WEP Debacle. Also, although speakers often do nothing more than read what's on the screen, a talk does ideally involve more content than is on the slides. I would agree that HTTPS has been more successful than WEP, in the sense of providing defense against real threats. HTTPS actually defends against some real attacks, providing an effective answer to a clearly defined problem: preventing the exposure of sensitive information such as credit card numbers, even in the face of eavesdropping and server impersonation. This is only one threat model and maybe not the most realistic one, but HTTPS does define it and address it. Meanwhile, WEP is too weak to prevent any attacks; and even if it were not cryptographically weak, its stone-age key management would make it a poor tool for any network with more than a handful of users. A very relevant question is why WEP has been so much more widely deployed than HTTPS. Eric Rescorla is correct that people choose whether to use security measures or not based mostly on how convenient they are, not on how much they need them. In this sense, HTTPS is a failure; although it is effective, it is so difficult to use that almost no one bothers unless credit card numbers are involved. Security needs to be easy, or people will just put up with losses instead. One thing he doesn't stress is design by committee v. design by small focused team. Much of SSL and SSH's strengths are that they were designed and deployed quickly and cheaply (and insecurely!) so as to tap into real needs real quickly. I would suggest that any security protocol designed by a committee has a low survivability rating. In fact, early versions of both SSL and SSH had extensive flaws; it took many people to evolve them into their present states. *All* security protocols have low survivability ratings. Inventing a new protocol is extremely hazardous. -- Shields. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PRNG design document?
Anton Stiglic [EMAIL PROTECTED] writes: It is important to chose both a random seed and random key, and FIPS 140 has no provision for this. Yes it does, you just have to interpret it correctly. The post-processed pool output [from the cryptlib generator] is not sent directly to the caller but is first passed through an X9.17 PRNG that is rekeyed every time a certain number of output blocks have been produced with it, with the currently active key being destroyed. Since the X9.17 generator produces a 1:1 mapping, it can never make the output any worse, and it provides an extra level of protection for the generator output (as well as making it easier to obtain FIPS 140 certification). Using the generator in this manner is valid since X9.17 requires the use of DT, a date/time vector which is updated on each key generation, and cryptlib chooses to represent this value as a complex hash of assorted incidental data and the date and time. The fact that 99.% of the value of the X9.17 generator is coming from the timestamp is as coincidental as the side effect of the engine-cooling fan in the Brabham ground-effect cars [Reference]. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: U.S. seeks OSCE pact on biometric passports
At 04:50 PM 9/2/03 -0400, Duncan Frissell wrote: Anyone have any pointers to non destructive methods of rendering Smart Chips unreadable? Just curious. DCF Perhaps I'm being dense but how could this be non-destructive? Do you mean non-obvious? Or reversible? If the usual microwave games don't apply, perhaps sufficient acceleration or ionic fluids would work. Thermal stress for the liquid nitrogen folks? The flash unit from a $4 disposable camera does a nice job of vaporizing a spot of metal from a coin or screwdriver shorting the cap. Do any europeans have experience leaving smartcards in the laundry? One question would be how to discretely test/verify the new read-not mode :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: invoicing with PKI
-- On 1 Sep 2003 at 12:23, Ian Grigg wrote: I suspect the widest use of public key crypto in a non-PKI context would be SSH, which opportunistically generates keys rather than invite the user to fund a PKI. According to this page [1], there may or may not be 2,400k SSH servers This of course enormously dwarfs the use of PKI certificates. Why? Because an SSH server uses its public key to prove continuity of identity, rather than true names, and this is lot easier than true names. Outlook and outlook express support digital signing and encryption -- but one must first get a certificate. So I go to Thawte to get my free certificate, and find that Thawte is making an alarmingly great effort to link certificates with true name information, and with the beast number that your government has assigned to you, which imposes large costs both on Thawte, and on the person seeking the certificate, and also has the highly undesirable effect that using these certificates causes major loss of privacy, by enabling true name and beast number contact tracing of people using encryption. Now what I want is a certificate that merely asserts that the holder of the certificate can receive email at such and such an address, and that only one such certificate has been issued for that address. Such a certification system has very low costs for issuer and recipient, and because it is a nym certificate, no loss of privacy. Is there any web page set up to automatically issue such certificates? The certs that IE and outlook express accept oddly do not seem to have any provision for defining what the certificate certifies. This seems a curious and drastic omission from a certificate format. Since there is no provision to define what a certificate certifies, one could argue that any certification authority that certifies anything other than a true name connected to a state issued id number, the number of the beast, is guilty of fraud. This would seem to disturbingly limit the usefulness and application of such certificates. It also, as anyone who tries to get a free certificate from Thawte will discover, makes it difficult, expensive, and inconvenient to get certificates. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG id/UsYl2xTf9Mswn+zhPXu3gZK4Hx7RMoDuc1LXZ 4TEx1/ENp2au248aS2r/SqmAc7NKT8yzMwGTk3dOK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: invoicing with PKI
-- On 1 Sep 2003 at 19:17, Hadmut Danisch wrote: Is cryptography where security took the wrong branch? True names is where security took the wrong branch. The entire PKI structure has been rejected. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 23+XuDK7JTGYW75W2R6MyD+V56OpgktSnYqZ4GBT 4OFVh0w6Cykrd+ETKSZ7D+1zB0+KUqjBmSgIFnmsG - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: invoicing with PKI
Peter Gutmann wrote: Hadmut Danisch [EMAIL PROTECTED] writes: There was an interesting speech held on the Usenix conference by Eric Rescorla (http://www.rtfm.com/TooSecure-usenix.pdf, unfortunately I did not have the time to visit the conference) about cryptographic (real world) protocols and why they failed to improve security. It was definitely a must hear talk. If you haven't at least read the slides (were the invited talks recorded this year? Any MPEGs available?), do so now. I'll wait here. I read them twice the other say. Recordings would be nice. [Pause] The main point he made was that designers are resorting to fixing mostly irrelevant theoretical problems in protocols because they've run out of other things to do, while ignoring addressing how to make the stuff they're building usable, or do what customers want. My favourite example of this (coming from the PKI world, not in the talk) is an RFC on adding animations and theme music to certificates, because that's obviously what's holding PKI deployment back. :-) Was this an April 1st RFC? Or a stealth DRM effort? From the logfiles I've visited I'd estimate that more than 97% of SMTP relays do not use TLS at all, not even the oportunistic mode without PKI. I did a talk last year at Usenix Security where I said that all SSL really needed was anon-DH, because in most deployments that's how certificates are being used (self-signed, expired, snake-oil CAs, even Verisign's handed-out- like-confetti certs). It's worth looking at these figures from 1st Sep 2003: Description Count Valid35709 Self Signed 9769 Unknown Signer 27507 Cert-Host Mismatch 40276 Expired 54578 http://www.securityspace.com/s_survey/sdata/200308/certca.html I used the total in my calculation to get 1.24% server penetration, but the true story is way worse - only a quarter are supposed PKI-valid. The rest are deviant in some form. It's no less secure than what's being done now, and since you can make it completely invisible to the user at least it'll get used. If all new MTA releases automatically generated a self-signed cert and enabled STARTTLS, we'd see opportunistic email encryption adopted at a rate that tracks MTA software upgrades. I've thought about this a lot, and I've come to the conclusion that trying to bootstrap using ADH is not worth the effort. I think the best thing is if the web servers were to automatically generate self-signed certs on install, and present them by default. Then, at least, we offer the opportunity for browsers to do SSH-style time-trust analysis. The forces of crypto-conservatism are so strong that I suspect we only get one shot at saving the HTTPS protocol. Trying to get browsers and servers to agree to like ADH seems too much a challenge. Using self- signed certs seems to promise more bang for buck. For new applications, using ADH is definately a good way to go. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg [EMAIL PROTECTED] writes: There appear to be a number of metrics that have been suggested: a. nunber of design wins b. penetration into equivalent unprotected market c. number of actual attacks defeated d. subjective good at the application level e. worthless measures such as deployed copies, amount of traffic protected You forgot the most important one: f. value added elsewhere SSL's real strength is that it's convinced 100 million Joe Sixpacks that it's safe to make purchases online. This has nothing to do with security (you could do the same with padlock GIFs stuck on your web page), but does count as some sort of measure of success, although it's marketing success rather than security success. Although they provide about the same level of real security, it seems that SSH is the tool of choice for people who care about providing real security while SSL is the tool of choice for people who care about providing their customers warm fuzzies. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
Ian Grigg [EMAIL PROTECTED] writes: Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: I think it's pretty inarguable that SSL is a big success. One thing that has been on my mind lately is how to define success of a crypto protocol. I.e., how to take your thoughts, and my thoughts, which differ, and bring the two together. There appear to be a number of metrics that have been suggested: a. nunber of design wins b. penetration into equivalent unprotected market c. number of actual attacks defeated d. subjective good at the application level e. worthless measures such as deployed copies, amount of traffic protected All of these have their weaknesses, of course. It may be that a composite measure is required to define success. I'm sure there are more measures. a. The only thing that seems to be clearly a win for SSL is the number of design wins - quite high. That is, it would appear that when someone is doing a new channel security application, the starting point is to consider SSL. b. we seem to be agreeing on 1% penetration of the market, at least by server measurement (see my other post where I upped that to 1.24% in the most recent figures). This really depends on your definition of market. SSL was designed to protect credit card transactions, period. For that, the market penetration is near 100%. d. subjective good. For HTTPS, again, it's a decidedly mixed score card. When I go shopping at Amazon, it makes little difference to me, because the loss of info doesn't effect me as much as it might - $50 limit on liability. That $50 limit is a funny thing. I look at it this way: You don't PERSONALLY eat the cost of fraud on your own card but you eat the cost of fraud on other people's cards. Thus, as in many situations, it's in your interest for everyone else to practice good hygiene. In this particular case, the issuers were *very* wary of providing credit card transactions over the Internet without some sort of encryption. So, SSL is what enables you to do e-commerce on the net. That seems like a large subjective good. Actually, I think that SSL has the right model for the application it's intended for. SSH has the right model for the application it was intended for. Horses for courses. Plenty of room for future discussion then :-) (I sense your pain though - I see from the SHTTP experiences, you've been through the mill. Vis a vis SHTTP, I'm not sure if that was the right design or SSL was. However, they had relatively similar threat models. I'm almost convinced that WEP is a failure, but I think it retains some residual value. I agree. After all, I occasionally come upon a network I'd like to use and WEP stops me cause I'm too lazy. On the other hand, MAC restrictions would have done just as well for that. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: invoicing with PKI
Peter Gutmann wrote:
It's no less secure than what's being done now, and
since you can make it completely invisible to the user at least it'll get
used. If all new MTA releases automatically generated a self-signed cert and
enabled STARTTLS, we'd see opportunistic email encryption adopted at a rate
that tracks MTA software upgrades.
I've thought about this a lot, and I've come to the conclusion that trying to
bootstrap using ADH is not worth the effort. I think the best thing is if
the web servers were to automatically generate self-signed certs on install,
and present them by default.
Right, that's what I meant - RSA is being used as anon-DH anyway, so we may as
well stop pretending and just make it fully automated and transparent to the
user. If people do want to go to the effort of checking that everything is
OK, do it by checking the cert fingerprint in the same way that PGP and SSH
have been doing for years.
The main point he made was that designers are resorting to fixing mostly
irrelevant theoretical problems in protocols because they've run out of other
things to do, while ignoring addressing how to make the stuff they're building
usable, or do what customers want. My favourite example of this (coming from
the PKI world, not in the talk) is an RFC on adding animations and theme music
to certificates, because that's obviously what's holding PKI deployment back.
:-) Was this an April 1st RFC? Or a stealth DRM effort?
It's a real RFC (currently still a draft), Logotypes in X.509 certificates.
I originally suggested this as a joke a couple of years ago (Can you imagine
KPMGCoopersPriceLybrandWaterhouseAnderson distributing a single cert without
the Official Corporate Logo(tm) with Official Corporate Animation(tm) and
Official Corporate Song(tm) playing in the background?). Given PKIX's
propensity for standardising anything that comes along (PKIX was formed to do
one thing and has become a standing committee that will do anything, provided
it is in ASN.1 syntax - Phil Hallam-Baker), it was only a matter of time
before a draft appeared. I made the following suggestion for a further
addition to the RFC, but it hasn't been adopted (yet):
-- Snip --
4.3. Scent logotypes
Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties. For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, the NRA would use a heady mixture of
cordite and gun oil, and PKIX could use cold coffee and stale cigarette smoke.
The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage. Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.
The scent logotype extension MUST have the following syntax:
LogotypeScent ::= SEQUENCE {
scentSubtype IA5String, -- MIME scent subtype
scentOCTET STRING,
refreshInfo ScentRefreshInfo OPTIONAL
}
A MIME type is used to specify the format of the file containing the scent
logotype data. The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.
Since scents fade over time, it may be necessary to periodically refresh the
scent to preserve the user experience:
ScentRefreshInfo ::= SEQUENCE {
refreshTime INTEGER DEFAULT 30,
refreshCount [0] INTEGER DEFAULT 1,
refreshUrl IA5String,
refreshUrlHash OCTET STRING OPTIONAL }
The refresh time specifies the time in seconds after which the scent must be
refreshed, the refresh count specifies the number of times the scent should be
refreshed after initial deployment, and the URL and optional hash of the data
stored at the URL location contains the scent payload and integrity protection
mechanism.
7.1. Security considerations
Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes. For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse. Resolution of this issue lies outside the scope of this memo.
Intensive usage of scent logotypes may trigger smoke alarms and, by extension,
sprinkler systems. Users should be aware of this and carry an umbrella.
Certificate users involved in skunkworks projects are discouraged from
Re: invoicing with PKI
At 11:41 PM 9/2/2003 -0700, James A. Donald wrote: True names is where security took the wrong branch. The entire PKI structure has been rejected. x.509 identity certificates are business processes ... not a cryptography process. as I've mentioned elsewhere many of the institutions that looked at x.509 identity certificates in the early 90s had retrenched to relying-party-only certificates with just some sort of account number and public key. The problem of overloading a x.509 identity certificate with lots of privacy information turned out to be an enormous identity and liability problem. Part of the issue was creating a certificate at some time in the past and attempting to guess at what might be needed by various random relying-parties in the future ... led to overloading certificates with ever increasing privacy detail loaded. One of the content models was driver's license, name, address, date-of-birth. date-of-birth is an obvious identity theft vulnerability. The idea of randomly spraying your privacy detail all over the earth (attached to every electronic operation) turned out to be significant issues. Even just having your name attached to every electronic operation and sprayed all over the world represented a significant issue. recent post in sci.crypt: http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES and slightly related post (also from sci.crypt): http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Is cryptography where security took the wrong branch?
In message [EMAIL PROTECTED], Ian Grigg [EMAIL PROTECTED] wrote: One thing that has been on my mind lately is how to define success of a crypto protocol. There are two needs a security protocol can address. One is the need to prevent or mitigate real attacks; the other is to make people feel less afraid. HTTPS might or might not have addressed a major problem, but it did address a major fear. Many people -- not only consumers, but also merchants, issuing banks, and processing companies -- were concerned about using credit card numbers on the Internet in 1995, when there was no viable way to buy anything online. Netscape designed an effective protocol, deployed it widely, and made it visible to end-users. It offered a credible promise that you could trust your session without trusting the network, and that's what made people willing to do large-scale online commerce and banking. This is not to be underestimated. At the same time, Netscape put visible crypto into the hands of people who had never used crypto before, and in many cases had never even owned a computer before. This did a great deal to counter the rhetoric about encryption being a tool for drug dealers and child pornographers. The physical security industry has known for a long time that if you want something deployed, you shouldn't be looking at what problems are interesting or even at what problems people actually have. You should be looking at what makes people afraid. Fear drives deployment. -- Shields. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
