RE: Maybe It's Snake Oil All the Way Down
Lucky Green [EMAIL PROTECTED] writes: I trust that we can agree that the volume of traffic and number of transactions protected by SSL are orders of magnitude higher than those protected by SSH. As is the number of users of SSL. The overwhelming majority of which wouldn't know ssh from telnet. Nor would they know what to do at a shell prompt and therefore have no use for either ssh or telnet. Naah, that third sentence is wrong. It's: The overwhelming majority of [SSL users] wouldn't know SSL from HTTP with a padlock GIF in the corner. Given that SSL use is orders of magnitude higher than that of SSH, with no change in sight, primarily due to SSL's ease-of-use, I am a bit puzzled by your assertion that ssh, not SSL, is the only really successful net crypto system. I think the assertion was that SSH is used in places where it matters, while SSL is used where no-one really cares (or even knows) about it. Joe Sixpack will trust any site with a padlock GIF on the page. Most techies won't access a Unix box without SSH. Quantity != quality. If you could wave a magic wand and make one of the two protocols vanish, I'd notice the loss of SSH immediately (I couldn't send this message for starters), but it would take days or weeks before I noticed the loss of SSL. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Draft Edition of LibTomMath book
Werner Koch [EMAIL PROTECTED] writes: Does the proprietary SSH still use GMP? I know no other major crypto apps using GMP for big number math. I've seen it used in a couple of lesser-known apps that I played with for interop testing, nothing that counts as a major app though. Maybe it's being used by people who prefer the LGPL to the more widely-used OpenSSL bignum lib's BSD license (or perhaps it's the fact that GMP has documentation :-). A problem with GMP is that it heavily uses alloca() and thus it is not that hard to find traces of secrets in the core. Ouch! This is a pity, because GMP seems to have the most active development in terms of both algorithm optimisation and machine-specific optimisations - if you want to find a version that runs well on $obscure_embedded_platform, it's pretty much GMP or nothing. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
William Allen Simpson [EMAIL PROTECTED] writes: Would this be the DHCP working group that on at least 2 occasions when I was there, insisted that secure DHCP wouldn't require a secret, since DHCP isn't supposed to require configuration? Given that their goal is zero-configuration networking, I can see that being required to provide a shared secret would mess things up a bit for them. It'd be a bit like PKIX being asked to make ease-of-use a consideration in their work, or OpenPGP to take X.509 compatibility into account. Peter. - 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: 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: 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: OpenSSL *source* to get FIPS 140-2 Level 1 certification
Rich Salz [EMAIL PROTECTED] writes: Sure, that's why it's *the first.* They have never done this before, and it is very different to how they (or their Ft Meade experts) have done things before. I suppose one could argue that they're doing this for Level 1 to increase the industry demand for Level 2, but I'm not that paranoid. I think they finally get it. I think this uniquely broad certification, if permitted, would be mostly a sign that the politicians have finally won out over the certification purists. Let me explain... it's been known for a long time (at least from talking to evaluators, I don't know if NIST will admit to it) that there's large-scale use of unevaluated crypto going on, with the FIPS eval requirement being ignored by USG agencies, contractors, etc etc whenever it gets in the way of them getting their job done. If NIST allow this extremely broad certification, it'd be a sign that they're following the Calvin and Hobbes recipe for success: The secret to [success] is to lower your expectations to the point where they're already met. In other words the unevaluated crypto problem (or a major part of it) suddenly goes away, and it's possible to report that the certification effort has been wonderfully successful, because a large portion of the noncompliant usage is (at least on paper) magically made compliant overnight. The only potential downside to this is that a pile of vendors who previously got a very narrowly-interpreted certification will presumably be queueing up to do the I'll have what she's having thing as soon as an open-ended certification is issued. As with others who have commented on this, I'm going to believe this when I see it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fyi: bear/enforcer open-source TCPA project
Rich Salz [EMAIL PROTECTED] writes: Second, if the key's in hardware you *know* it's been stolen. You don't know that for software. Only for some definitions of stolen. A key held in a smart card that does absolutely everything the untrusted PC it's connected to tells it to is only marginally more secure than a key held in software on said PC, even though you can only steal one of the two without physical access. To put it another way, a lot of the time you don't need to actually steal a key to cause damage - it doesn't matter whether a fraudulent withdrawal is signed on my PC with a stolen key or on your PC with a smart card controlled by a trojan horse, all that matters is that the transaction is signed somewhere. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: End of the line for Ireland's dotcom star
John Young [EMAIL PROTECTED] writes: Who at Baltimore, or was once there, is likely to be able to account for the security of the certs for customers who still rely upon them? Not somebody to spin a fairy tale, but to truthfully explain what Baltimore has done to avoid betraying the trust of its customers, or handing that trust over to others who may not have Baltimore's scruples or be bound by its promises. Is it really that big a deal though? You're only ever as secure as the *least secure* of the 100+ CAs automatically trusted by MSIE/CryptoAPI and Mozilla, and I suspect that a number of those (ones with 512-bit keys or moribund web sites indicating that the owner has disappeared) are much more of a risk than the GTE/Baltimore/beTRUSTed/whoever-will-follow-them succession. The real lesson of this, I think, is the observation that The company would have done better to concentrate on making its core PKI technology easier to deploy, which applies to most other PKI vendors and products as well. Baltimore had the bizarre business strategy of using revenue from its PKI products as a means of driving/funding work in its other product branches, which is a bit like a drowning man going for a boat anchor as his most likely flotation device. Peter (curently flooded with Linux VPN mail, please be patient). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: End of the line for Ireland's dotcom star
Anonymous via the Cypherpunks Tonga Remailer [EMAIL PROTECTED] writes: Why is it that none of those 100-odd companies with keys in the browsers are doing anything with them? Verisign has such a central role in the infrastructure, but any one of those other companies could compete. Why isn't anyone undercutting Verisign's prices? Look what happened with Thawte when it adopted this strategy: Mark Shuttleworth got to visit Mir! Maybe that was a one shot deal, but clearly these keys are not being utilized up to their economic potential. Is there some behind the scenes coercion? Contractual limitations? Will Microsoft pull the keys if someone tries to compete with Verisign? What's the deal? No-one ever got fired for buying Verisign. Unfortunately in order to understand that buying your certs from anything but the cheapest CA present is a waste of money, you need a certain amount of understanding of how PKI (or at least certificate manufacturing, as currently practiced) works. Verisign have invested an enormous amount of time and money into communicating the message that it ain't secure if it doesn't say Verisign, and that's been very effective. I have, very occasionally, run into people who've told me how they managed to locate a CA that sold them their certs for $29.95/year instead of $495/year, but this is very much the exception to the rule. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: why are CAs charging so much for certs anyway? (Re: End of the line for Ireland's dotcom star)
Ed Gerck [EMAIL PROTECTED] writes: PRICING STRATEGY: CAs should keep their prices high and find ways to add price to current products (eg, offering insurance, different certificate classes, benefits for CRL access, etc.) -- because the potentially difficult mid-term future of such business impose the need for a large ROI in a short time. This is probably not a long-term business activity. Actually there's a second aspect to this as well: Verisign's managed PKI services. The idea here is that since PKI (specifically, the X.509 PKI model) is too hard for any normal person or organisation to handle, you charge people an enormous amount of money to run their PKI for them. You end up talking to a Verisign cloud that acts as an authorisation oracle (Is this thing OK? - Yep, go ahead), although exactly why you need a PKI for this rather than (say) a basic challenge-response protocol to query the cloud is unclear (maybe it's a fashion thing, or an in-joke that no-one's let me in on). As a moneymaking racket, it's second only to the make the browser warning dialogs go away one: First you create an unworkable PKI design (although Verisign didn't do that, they're just taking advantage of it), then you charge people buckets of money to run it for them (and in terms of money-earners, it leaves the $495 server certs in the dust - it's sort of like a PKI-DNS service, except that you pay 5-6 figure sums for your name/key registration). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A different Business Model for PKI (was two other subjects related to the demise of Baltimore)
Ed Reed [EMAIL PROTECTED] writes: 2) PKI vendors looked at that and must have said - gee, if we can get $100-$150/yr/user for managing identity around PKI certificates, why shouldn't we? Actually it's even better than that, the companies using the managed service are still expected to act as the RA (registration authority) for certs, so they do all the hard work (verifying users, etc etc). Verisign just give them access to a cert-management engine and collect the fees (OK, there's a bit more work to it than that, but still, the Verisign beancounters must be like pigs in clover over it). 3) the standards groups, PKIX in particular, still haven't addressed the cert life cycle management issues, and neither has the market place, in any coherent, interoperable fashion That's my perpetual gripe with PKIX, they're frantically busy distracting themselves with interesting (to them) but ultimately pointless and irrelevant additional standardisation of features so obscure that you need 15 pages of diagrams just to explain to users why they might be useful, while ignoring the fact that most people can't use even the most rudimentary parts of what's already there. This is presumably why the IETF finally shut them down, they realised they'd just keep endlessly churning out RFCs until the sun goes out (I'm not sure whether just leaving them alone to do that in perpetuity wouldn't have been the better option). After some research, it appears to me that there's a tidy little business possible for someone to break the mold. Can't be done. SPKI tried it, designing an eminently workable PKI (for the task they were trying to solve) and no-one was interested because it wasn't X.509. Certainly if you throw out all the X.500 baggage that we know doesn't work (X.500 DNs, directories, CRLs, etc etc, which is what SPKI did) you can build a very workable, usable, scalable PKI, but OSI digital ancestor-worship requirements say that you're not allowed to do that. Anyone care to make a go of it? Please, go ahead. I'll stand over here and watch. It's a vicious circle, X.509 doesn't work/doesn't do what people want, but anything that does work isn't X.509 and therefore won't be accepted by the market. SPKI was a heroic effort to break out of the cycle, but despite a lot of work and input from some very clever people, it ultimately failed for that reason. And unlike the OSI experience in the 1980s (which X.509 is a direct repeat of), for PKI there isn't any DARPA-spawned white knight to come in and fix things when it fails. To some extent this is computer darwinism in action. With networking protocols, some alternative to OSI (that is, a relatively functional set of networking protocols) had to evolve at some point, because computers had to communicate somehow. There was intense market pressure to get something that worked, and eventually it was the IP protocol suite. With PKI on the other hand no such pressure exists, since it's pretty much irrelevant for most people. Sure, your marketing folks can come up with all sorts of neat hypothetical scenarios where PKI would make things so much better, but in reality people and companies can do their banking, tax filing, buying and selling, share trading, and every other use that might justify a PKI, perfectly well without it. As a result there's no pressure on the people involved in PKI standardisation to create anything that meets any real-world requirement, allowing them instead to spend their time building great gothic cathedrals of infinite complexity whose sole purpose seems to be to strike awe and terror into the masses. What's left to vendors is a few niche markets, generally the same groups who are still trying to make a go of using X.400 (government departments/the military, a few large corporates, a few banks) who will keep struggling with X.509 for a number of years. That's a pretty small market to peddle your wares into, as companies like Baltimore, Entrust, and a number of other PKI vendors have found out. Peter (who probably now officially qualifies as a PKI curmudgeon). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
Bill Frantz [EMAIL PROTECTED] writes: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. This doens't really work. Consider the simple case where you run Outlook with 'nobody' privs rather than the current user privs. You need to be able to send and receive mail, so a worm that mails itself to others won't be slowed down much. In addition everyone's sending you HTML-formatted mail, so you need access to (in effect) MSIE via the various HTML controls. Further, you need Word and Excel and Powerpoint for all the attachments that people send you. They need access to various subsystems like ODBC and who knows what else as an extension of the above. As you follow these dependencies further and further out, you eventually end up running what's more or less an MLS system where you do normal work at one privilege level, read mail at another, and browse the web at a third. This was tried in the 1970s and 1980s and it didn't work very well even if you were prepared to accept a (sizeable) loss of functionality in exchange for having an MLS OS, and would be totally unacceptable for someone today who expects to be able to click on anything in sight and have it automatically processed by whatever app is assigned to it. Even if you could somehow enforce the MLS-style restrictions and convince people to run an OS with this level of security enabled, the outcome when this was tried with MLS OSes was that users would do everything possible to bypass it because it was seen as an impediment to getting any work done: SIGMA eventually allowed users to violate the *-property to avoid them having to re- type messages at lower security levels (i.e. it recognised that they were going to violate security anyway, so it made it somewhat less awkward to do), Multics and GEMSOS allowed users to be logged in at multiple security levels to get work done (now add the 1,001 ways that Windows can move data from A to B to see how much harder this is to control than on a 1970s system where the only data-transfer mechanism was copy a file), KSOS used non-kernel security-related functions (kludges) to allow users to violate security properties and get their work done, etc etc. One thing that I noticed in the responses to CyberInsecurity: The Cost of Monopoly was that of the people who criticised it as recommending the wrong solution, no two could agree on any alternative remedy. This indicates just how hard a problem this really is... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
John S. Denker [EMAIL PROTECTED] writes: According to 'ps', an all-up ssh system is less than 3 megabytes (sshd, ssh- agent, and the ssh client). At current memory prices, your clients would save less than $1.50 per system even if their custom software could reduce this bulk to zero. Let me guess, your background is in software rather than hardware? :-). Not all computers are PCs, where you can just drop in another SIMM and the problem is fixed. Depending on how you measure it, there are at least as many/many more embedded systems out there than PCs, where you have X system resources and can't add any more even if you wanted to because (a) the system is already deployed and can't be altered, (b) it's cheaper to rewrite the crypto from scratch than spend even 5 cents (not $1.50) on more memory, or (c) the hardware can't address any more than the 128K or 512K (64K and 256K 8-bit SRAMs x 2, the bread and butter of many embedded systems) that it already has. With the cost of writing custom software being what it is, they would need to sell quite a large number of systems before de-bulking began to pay off. And that's before accounting for the cost of security risks. See above. This is exactly the situation that embedded-systems vendors find themselves in (insert tales of phone exchanges built from clustered Z80s because it's easier to keep adding more of those than to move the existing firmware to new hardware without the Z80's restrictions, or people being paid outrageous amounts of money to hand-code firmware for 4-bit CPUs because it's cheaper than moving everything to 8-bit ones, or ...). Perry E. Metzger [EMAIL PROTECTED] writes: SSL is not only used to protect people's credit cards. It is one thing if, as a customer, with eyes wide open, you make a decision to use something iffy. However, as a producer, it is a bad idea to make assumptions you know what people will do with your tools, because you don't. People end up using tools in surprising ways. You can't control them. Yup. I once had a user discuss with me the use of my SSL code in an embedded application that controlled X. I was a bit curious as to why they'd bother, until they explained the scale of the X they were controlling. If anything were to go wrong there, it'd be a lot more serious than a few stolen credit cards. Once you have a general-purpose security tool available, it's going to be used in ways that the original designers and implementors never dreamed of. That's why you need to build it as securely as you possibly can, and once it's done go back over it half a dozen times and see if you can build it even more securely than that. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: anonymous DH MITM
Tim Dierks [EMAIL PROTECTED] writes: It does not, and most SSL/TLS implementations/installations do not support anonymous DH in order to avoid this attack. Uhh, I think that implementations don't support DH because the de facto standard is RSA, not because of any concern about MITM (see below). You can talk to everything using RSA, you can talk to virtually nothing using DH, therefore... Many wish that anon DH was more broadly used as an intermediate security level between bare, insecure TCP authenticated TLS, but this is not common at this time. RSA is already used as anon-DH (via self-signed, snake-oil CA, expired, invalid, etc etc certs), indicating that MITM isn't much of a concern for most users. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
Bill Frantz [EMAIL PROTECTED] writes: This is the second significant problem I have seen in applications that use ASN.1 data formats. (The first was in a widely deployed implementation of SNMP.) Given that good, security conscience programmers have difficultly getting ASN.1 parsing right, we should favor protocols that use easier to parse data formats. I think this leaves us with SSH. Are there others? I would say the exact opposite: ASN.1 data, because of its TLV encoding, is self-describing (c.f. RPC with XDR), which means that it can be submitted to a static checker that will guarantee that the ASN.1 is well-formed. In other words it's possible to employ a simple firewall for ASN.1 that isn't possible for many other formats (PGP, SSL, ssh, etc etc). This is exactly what cryptlib does, I'd be extremely surprised if anything could get past that. Conversely, of all the PDU-parsing code I've written, the stuff that I worry about most is that which handles the ad-hoc (a byte here, a unit32 there, a string there, ...) formats of PGP, SSH, and SSL. We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP analysis tool) with malformed PGP packets (I've also crashed quite a number of SSH clients with malformed packets while fiddling with my SSH server code), and I'm just waiting for someone to do the same thing with SSL packets. In terms of safe PDU formats, ASN.1 is the best one to work with in terms of spotting problems. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
Jerrold Leichter [EMAIL PROTECTED] writes: Both of these are helped by a well-specified low-level syntax. TLV encoding lets you cross-check all sorts of stuff automatically, once, in low-level calls. Ad hoc protocols scatter the validation all over the place - and some of it will inevitably be overlooked. Yup, and that's exactly what makes me so nervous about the ad hoc formats. Having had the experience of writing parsers for every major format used in crypto (oh, except IPsec, but that falls into the same class as PGP/SSH/SSL) and ranking things in the order in which I'd expect problems to occur, I get: ASN.1: Pretty much bulletproof, you should be able to throw anything at that code and it'll just bounce off (I should be able to run the recent malformed-ASN.1 attacks that hit OpenSSL on it within the next few days, but I'd expect all of those to be caught by the firewall and not even get to the actual ASN.1 code). Ad hoc formats (PGP, SSH, SSL): Should be OK because I apply anal-retentive amounts of checking everywhere and have done probably a dozen full audits of the code, but I'm still not fully confident about it (it did withstand the malformed-SSH-message weaknesses from a few months ago though). Text formats (XML): Full of arbitrarily-complex messages, variable-length encodings, special-case escape sequences, and other horrors, and that's without even thinking about the nightmare added by XSLT, XPath, DTDs, style sheets, XML namespace problems, and who knows what else. If anything goes wrong, it'll be in there. I can't even imagine how you could produce a truly safe parser for that stuff. While I'm not madly in love with ASN.1, in terms of safe data formats it's the one I feel most comfortable with. Jonathan S. Shapiro [EMAIL PROTECTED] writes: I agree that ASN.1 is statically checkable, and that this is an important property. However, ASN.1 is notoriously hard to parse, which leads to errors. ASN.1 has a *reputation* of being notoriously hard to parse, gained chiefly from some early bad experiences with OSI work (which would give anything a reputation of being hard to work with :-). I've implemented, and I know of others who have implemented, extremely compact and portable ASN.1 libraries. My ASN.1 library is about the same level of complexity as the PGP and SSH libraries, so the bit-bagging scheme being used has little to do with it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Other OpenSSL-based crypto modules FIPS 140 validated?
Nathan P. Bardsley [EMAIL PROTECTED] writes: Anecdotally, I've heard that there are many, but almost all of them were done by vendors for embedding in their proprietary products. Ditto. The problem is that when vendors have spent $100K+ on the certification, they're very reluctant to give anyone else (and specifically their competitors) the benefits of their expenditure, so you end up getting the same thing re-certified over and over for private use, rather than a single generally-usable version being certified. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
Anton Stiglic [EMAIL PROTECTED] writes: This is why you get requirements of the type that it should run on Windows in single-user mode, which I take to mean have only an admin account. This prevents privilege escalation attacks (regular user to root) that are easily done. I think this is reasonable, since you really are relying on the OS and the PC for the security of the module. Uhh, so you're avoiding privilege escalation attacks by having everyone run as root, from which you couldn't escalate if you wanted to. This doesn't strike me as a very secure way to do things (and it would still get MSDOS certified, because you've now turned your machine into a DOS box protection-wise). More scary to me is stuff like DSSENH does not provide persistent storage of keys. While it is possible to store keys in the file system, this functionality is outside the scope of this validation. That's the Define the bits that we can easily get away with to be secure and ignore the rest approach that I commented on. It was actually part of a posting to another list where I was poking fun at BS 7799: -- Snip -- Some years ago I witnessed a BS 7799 security certification being done. For those of you who aren't familiar with this, it's ISO 9000 for security. It went something like this: First, we define the region from the rug in the corner to Dave's desk to the pot-plant on the right to be... SECURE. Everything inside this region is by definition SECURE. Everything outside the region is none of our concern. Access to the server room from the SECURE area is by locked door. The keys are on a hook on the wall, but since the hook is outside the SECURE area, we don't have to worry about that. Now we need to produce a lot of paperwork. I'll help you with this, it should only take a few weeks. Congratulations, you now have a BS 7799-certified SECURE facility. Here's my bill. In other words they didn't change anything at all in their insecure (except in the eyes of BS 7799) work area. The whole certification process was an exercise in meeting the certification requirements purely through the production of paperwork. -- Snip -- The SECURE facility has since been decomissioned, so I guess it's safe to talk about it now. Incidentally, almost everyone knew where the key was because the room in question had the best air-conditioning in the building (it was packed full of servers and networking gear), so it became quite popular in the summer with the sysadmins, who'd find various reasons to do extended amounts of work in there. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
Markus Friedl [EMAIL PROTECTED] writes: On Sat, Oct 04, 2003 at 05:58:49PM +1200, Peter Gutmann wrote: We've already seen half the SSH implementations in existence taken out by the SSH malformed-packet vulnerabilities, I don't think so. According to the CERT advisory, roughly half of all known SSH implementations are vulnerable (some of the vendor statements are a bit ambiguous), and the number would have been higher if it weren't for the fact that several of the non-vulnerable implementations share the OpenSSH code base (there are a number of implementations not in the advisory, but we can take it as being a representative sample). The reason I appear to be defending ASN.1 here is that there seems to be an irrational opposition to it from some quarters (I've had people who wouldn't recognise ASN.1 if they fell over it tell me with complete conviction that it's evil and has to be eradicated because... well just because). I don't really care about the religious debate one way or the other, I'm just stating that from having used almost all of the bit-bagging formats (starting with PGP 1.0) for quite a number of years, ASN.1 is the one I feel the most comfortable with in terms of being able to process it safely. Incidentally, if anyone wants to look for holes in ASN.1 data in the future, I'd be really interested in seeing what you can do with malformed X.509 and S/MIME data. Peter (who's going to look really embarrassed if the NISCC test suite finds problems in his ASN.1 code :-). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
I wrote: Peter (I define myself to be A BIT CYNICAL about all this). Since it could appear that I'm gratuitously bashing FIPS 140 (or certification processes in general) here, I should clarify: As with all attempts at one- size-fits-all solutions, one size doesn't quite fit all. You can break the people getting the certification down into three classes: Group 1: Vendors who really care about security, and go well beyond the FIPS 140 requirements anyway. Group 2: Vendors who are generally interested in security, and will polish up their product to meet the FIPS 140 requirements. Group 3: Vendors who want government contracts and see getting to their goal as being a penetration exercise on the certification process. Over time, the certification has been moving from being a value-add performed only by vendors who really care to being a You must be at least this high to ride the government-contract gravy train ticket check. During this progression, group 1 membership has remained more or less constant (they've been building secure products for years, with or without the certification), group 2 has grown slowly (mostly for hardware vendors doing level 2-3 stuff), and everything else sort of ends up in group 3 (no-one wants to miss the gravy train). Of the three groups, only group 2 really benefit from the certification requirements. Group 1 is frequently hindered by them because the vendors' security systems and models are far more sophisticated than the FIPS 140 ones, but to get your certification you have to show that it's only at the FIPS 140 level (this situation is a bit like the short story that's been circulating for some years in which systems engineers lobotomise a HAL 9000 so that it can run COBOL and JCL as the market requires). Group 3 just sees it as a paperwork-production exercise, shipping exactly the same product as before, only now they're allowed to sell it to government departments. The problem is that what we really need to be able to evaluate is how committed a vendor is to creating a truly secure product. Saying You won't get government contracts until you can fill in the checkboxes seems to be providing entirely the wrong motivation. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Open Source (was Simple SSL/TLS - Some Questions)
Peter Clay [EMAIL PROTECTED] writes: If you want a VPN that road warriors can use, you have to do it with IP-over- TCP. Nothing else survives NAT and agressive firewalling, not even Microsoft PPTP. IP-over-TCP has some potential performance problems, see http://sites.inka.de/bigred/devel/tcp-tcp.html, although having used SSH and SSL tunnels quite a lot, I wonder how serious this really is - the author of the above analysis mentions performance problems on a link with a high level of packet loss, but on a typical link I haven't found any real problems. If you specifically want a pure TCP tunnel though, there's a pile of solutions available, of which the easiest to set up is SSH (point it at the target, indicate that you want port forwarding, and you're done). If someone out there wants to write VPN software that becomes widely used, then they should make a free IP-over-TCP solution that works on Windows and Linux which uses password authentication. Some guy called Ylonen already did this in 1995 :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
Anton Stiglic [EMAIL PROTECTED] writes:
But the problem is how can people who know nothing about security evaluate
which vendor is most committed to security? For the moment, FIPS 140 and CC
type certifications seem to be the only means for these people...
Yeah, it's largely a case of looking where the light is. An extreme example
of this is the use of formal methods for high-assurance systems, as required
by FIPS 140-2 level 4. Why is it in there? Because FIPS 140-1 had it there
at the highest levels. Why was it in there? Because the CC has it in there
at the highest levels. Why was it in there? Because the ITSEC had it in
there at the highest levels. Why was it in there? Because the Orange Book
('85) had it in there at the highest levels. Why was it in there? Because
the proto-Orange Book ('83) had it in there at the highest levels. Why was it
in there? Because in the 1970s some mathematicians hypothesised that it might
be possible to prove properties of complex programs/systems in the same way
that they proved basic mathematical theorems.
(Aside: This is starting to sound like that apocryphal Why are railway tracks
spaced X units apart saga).
To continue: At what point in that progression did people realise that this
wasn't a very practical way to build a secure system? Some time in the late
1970s to early 1980s, when they actually tried to reduce the theory into
practice. There were quite a number of papers being published even before the
first proto-Orange Book appeared which indicated that this approach was going
to be extremely problematic, with problems... well, insert the standard
shopping list here.
So why is this stuff still present in the very latest certification
requirements? Because we're measuring what we know how to measure, whether it
makes sense to evaluate security in that way or not. This is probably why
penetrate-and-patch is still the most widely-used approach to securing
systems. Maybe the solution to the problem is to figure out how to make
penetrate-and-patch more rigorous and effective...
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
Jerrold Leichter [EMAIL PROTECTED] writes: There was also an effort in England that produced a verified chip. Quite impressive, actually - but I don't know if anyone actually wanted the chip they (designed and) verified. The Viper. Because it needed to be formally verifiable, they had to leave out most of the things that people are used to in modern CPUs and that make writing an OS easy, leading to a vaguely early-60s level of CPU architecture that probably would have been unpleasant to program for for anyone used to modern CPUs, and requiring expensive custom development of almost everything from scratch (you can't run Linux on that one). Eventually the project went into a meltdown over what was actually done (for example is verifying a set of 4-bit slices the same as verifying a 32-bit CPU?) and the legal battles lead to the demise of the company that was to exploit it commercially (there's a lot more to it than that including a fair bit of politics, that's a cut-down version to save space). Very few real efforts were made to actually produce a provably correct OS. There were actually quite a few efforts, starting in the 1970s, some of which went on much longer than the 9-year VAX VMM effort. PSOS - SAT - LOCK - SMG (it may be called something else again now) has been going for about 25 years. However, this is a really complex topic (way too much to cover here), so I'll cheat a bit and refer anyone who's really that interested in the problems that people ran into to Chapter 4 of Cryptographic Security Architecture Design and Verification to save me having to paraphrase 40 pages of text here. The point of my post wasn't to start yet another round of formal-methods bashing, but to point to an example of measuring what we know how to measure even if there are strong indicators that this isn't the best way to do it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Damien Miller [EMAIL PROTECTED] writes: The SSH protocol supports certificates (X.509 and OpenPGP), though most implementations don't. One of the reason why many implementations may not support it is that the spec is completely ambiguous as to the data formats being used. For example it specifies the signature blob format as an X.509 signature, which could be about half a dozen different things. Same with PGP signatures, for which there's even more possibilities. In addition since almost nothing implements them, it's not possible to get test data from someone else's server to see what they're doing (hmm, and even if there was there's no way to tell whether their interpretation would match someone else's). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
Thor Lancelot Simon [EMAIL PROTECTED] writes: I believe the VanDyke implementation also supports X.509, and interoperates with the ssh.com code. It was also my perception that, at the time, the VanDyke guy was basically shouted down when trying to discuss the utility of X.509 for this purpose and put his marbles back in his cloth sack and went home. Are there any known servers online that offer X.509 (or PGP) mechanisms in their handshake? Both ssh.com and VanDyke are commercial offerings so it's not possible to look at the source code to see what they do, and I'm not sure that I want to run the gauntlet of getting some sample copy of a commercial app (if they're available) and figuring out how to set it up to work with certs just to see what the data format is supposed to be... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PKI Research Workshop '04, CFP
Carl Ellison [EMAIL PROTECTED] writes: The third annual PKI Research workshop CFP has been posted. I note that it's still not possible to use PKI to authenticate submissions to the PKI workshop :-). (To those people who missed the original comment a year or two back, the first PKI workshop required that people use plain passwords for the web-based submission system due to the lack of a PKI to handle the task). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Perry E. Metzger [EMAIL PROTECTED] writes: TLS is just a pretty straightforward well analyzed protocol for protecting a channel -- full stop. It can be used in a wide variety of ways, for a wide variety of apps. It happens to allow you to use X.509 certs, but if you really hate X.509, define an extension to use SPKI or SSH style certs. TLS will accommodate such a thing easily. Indeed, I would encourage you to do such a thing. Actually there's no need to even extend TLS, there's a standard and very simple technique which is probably best-known from its use in SSH but has been in use in various other places as well: 1. The first time your server fires up, generate a self-signed cert. 2. When the user connects, have them verify the cert out-of-band via its fingerprint. Even a lower-security simple phrase or something derived from the fingerprint is better than nothing. 3. For subsequent connections, warn if the cert fingerprint has changed. That's currently being used by a number of TLS-using apps, and works at least as well as any other mechanism. At a pinch, you can even omit (2) and just warn if a key that doesn't match the one first encountered is used, that'll catch everything but an extremely consistent MITM. Using something like SSH keys isn't going to give you any magical security that X.509 certs doesn't, you'll just get something equivalent to the above mechanism. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Intel announces DRM-enabled motherboard
Intel has just announced a desktop motherboard with Wave's Embassy chip built in at http://www.intel.com/design/motherbd/rh/index.htm. Embassy is a DRM chip that was more recently re-targeted slightly for, uhh, non-DRM TCPA/TPM/whatever when they realised that DRM hardware was a bit of a hard sell. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Clipper for luggage
Bill Frantz [EMAIL PROTECTED] writes: I usually travel with zipper closed duffel bags. I fasten the zipper closed with a screw link. Anyone can unscrew the link and get into the bag, but it does effectively keep the zipper closed in transit. I suppose it also provides some level of security because someone wanting to do a quick grab from luggage will probably pick a less-secured piece. When true locks are banned, that's actually a rather good protection mechanism, constituting a type of hashcash for luggage. Someone who's looking for targets of opportunity and has a choice between a Clipper-locked container they can get into almost unnoticed in 5 seconds or something where it'll take a minute or two of obvious fiddling will presumably go for the Clipper-lock. Just don't go overboard with those custom foot-long screw machined locks. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Partition Encryptor
Dave Howe [EMAIL PROTECTED] writes: Peter Gutmann wrote: E4M needs some minor updates for XP by someone who knows about NT device drivers, otherwise you'll occasionally get problems unmounting volumes. Does anyone know of a version where this work has been done? Since this was last discussed (without resolution) in alt.security.scramdisk about a week ago, I'd say the answer is Probably not. A better question would be Can someone who knows about NT device drivers make the necessary changes to the code (it's GPL'd and freely available)?. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Open Source Embedded SSL - (License and Memory)
J Harper [EMAIL PROTECTED] writes: 2) Make it functional on systems without memory allocation. Did I mention that I work on (very) small embedded systems? Having fixed spaces for variables is useful when you want something to run deterministically for a long time with no resets, and I have yet to find a free bignum library that didn't want to use malloc all the time. We have implemented a block allocation scheme for our device Web services product that would probably solve this issue. Queues of various structure sizes are held within a single chunk of memory. How common is it to find an embedded system sophisticated enough to have a TCP stack and ethernet interface (and running SSL), but not sophisticated enough to have a malloc() implementation? I've always assumed that anything with the former will also have the latter (I know there are some highly constrained embedded platforms used in some web-enabled widgets, but they usually don't run SSL). My code will run without malloc() in general, but assumes that if you have a TCP stack and ethernet then you're also going to have malloc() support. For the non-malloc platforms, it's written to grab memory in a FIFO manner, so you can get away with a simple brk-style allocator. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PKI root signing ceremony, etc.
Dave Howe [EMAIL PROTECTED] writes: Key management and auditing is pretty much external to the actual software regardless of which solution you use I would have thought. Not necessarily. I looked at this in an ACSAC'2000 paper (available from http://www.acsac.org/2000/abstracts/18.html). This uses a TP-capable database as its underlying engine, providing the necessary auditing capabilities for all CA operations. This was desgined to meet the security/auditing requirements in a number of PKI standards (see the paper for full details, I've still got about 30cm of paper stacked up somewhere from this). The paper is based on implementation experience with cryptlib, you can't do anything without generating an audit trail provided you have proper security on the TP system (that is, a user can't inject arbitrary transactions into the system or directly access the database files). I tested the setup by running it inside a debugger and resetting/halting the program at every point in a transaction, and it recovered from each one. It can be done, it's just a lot of work to get right. I should mention after having done all that work that most CAs rely on physical and personnel security more than any automatic logging/auditing. Take a PC and an HSM, lock it in a back room somewhere, and declare it a secure CA. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Stefan Lucks [EMAIL PROTECTED] writes: Currently, I have three smart cards in my wallet, which I did not want to own and which I did never pay for. I never used any of them. Conversation from a few years ago, about multifunction smart cards: - Multifunction smart cards are great, because they'll reduce the number of [smart] cards we'll have to carry around. - I'm carrying zero smart cards, so it's working already! Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and other forms of trust
John Gilmore [EMAIL PROTECTED] writes: They eventually censored out all the sample application scenarios like DRM'd online music, and ramped up the level of jargon significantly, so that nobody reading it can tell what it's for any more. Now all the documents available at that site go on for pages and pages saying things like FIA_UAU.1 Timing of authentication. Hierarchical to: No other components. FIA_UAU.1.1 The TSF shall allow access to data and keys where entity owner has given the 'world' access based on the value of TCPA_AUTH_DATA_USAGE; access to the following commands: TPM_SelfTestFull, TPM_ContinueSelfTest, TPM_GetTestResult, TPM_PcrRead, TPM_DirRead, and TPM_EvictKey on behalf of the user to be performed before the user is authenticated. That gobbledigook sounds like Common Criteria-speak. So it's not deliberate, it's a side-effect of making it CC-friendly. nobody reading it can tell what it's for any more Yup, that's definitely Common Criteria. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: stego in the wild: bomb-making CDs
John Denker [EMAIL PROTECTED] writes: ] Thursday 25 December 2003, 17:13 Makka Time, 14:13 GMT ] ] Saudis swoop on DIY bomb guide [...] I suspect there is a lot more to this story.. The story could apply to any one of hundreds (thousands?) of hacker/warez CDs available off-the-shelf in the US. Heck, it could apply to the Encyclopedia Britannica CD edition. So I'd pick: 3) Also: as a rule, anything you do with computers generates more headlines than doing the same thing with lower-tech methods. because: ] Saudis swoop on DIY bomb guide sounds a lot better than: ] Saudis swoop on Britannica vendors Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Non-repudiation (was RE: The PAIN mnemonic)
Carl Ellison [EMAIL PROTECTED] writes: Ah. That's why they're trying to rename the corresponding keyUsage bit to contentCommitment then: Maybe, but that page defines it as: contentCommitment: for verifying digital signatures which are intended to signal that the signer is committing to the content being signed. The precise level of commitment, e.g. with the intent to be bound may be signaled by additional methods, e.g. certificate policy. This refers to the second (and IMHO more sensible) use of the X.509 nonRepudiation bit, which uses digitalSignature for short-term signing (e.g. user authentication) and nonRepudiation for long-term signing (e.g. signing a document). The other definition uses digitalSignature for everything, and nonRepudiation as an additional service on top of digitalSignature. The problem with that definition is that no two people in the X.509 world can agree on what nonRepudiation actually signifies. The best suggestion I've seen for the nonRepudiation bit is that CAs should set it to random values to disabuse users of the notion that it has any meaning. For the additional-service definition of nonRepudiation, the X.509 Style Guide says: Although everyone has their own interpretation, a good practical definition is Nonrepudiation is anything which fails to go away when you stop believing in it. Put another way, if you can convince a user that it isn't worth trying to repudiate a signature then you have nonrepudiation. This can take the form of having them sign a legal agreement saying they won't try to repudiate any of their signatures, giving them a smart card and convincing them that it's so secure that any attempt to repudiate a signature generated with it would be futile, threatening to kill their kids, or any other method which has the desired effect. One advantage (for vendors) is that you can advertise just about anything as providing nonrepudiation, since there's sure to be some definition which matches whatever it is you're doing (there are nonrepudiation schemes in use today which employ a MAC using a secret shared between the signer and the verifier, which must be relying on a particularly creative definition of nonrepudiation). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: fun with CRLs!
/. is reporting this, anyone know the real story? The CryptoAPI list has been lit up end to end with mail about this. The summary from one poster (Tim Anderson [EMAIL PROTECTED]) is: IE5.x's digital signature expired yesterday. Every computer that uses WinVerifyTrust now has to have the verify publisher certificate dealy unchecked or the WinVerifyTrust call takes upwards of 5 minutes to complete. The fix, as for the We're from Microsoft, give us a certificate fiasco of two years ago, is an OS update from Microsoft to replace the certs. Further patches will be in Win2K SP5 and WinXP SP2. ObSnideComment: It's a good thing 99.99% of PKI use is just window dressing, imagine if people were basing things like electronic funds transfers on technology as brittle as this: Please wait 5 minutes for the server to time out so your funds can become available. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Verisign CRL single point of failure
Rich Salz [EMAIL PROTECTED] writes: Can someone explain to me why the expiring of a certificate causes new massive CRL queries? Here's the reply straight from Verisign: -- Snip -- We wanted to pass on a notification that we have determined what we feel is the root cause of the CRL outage issue. It appears that at midnight GMT (4pm PST) on January 7, 2004, VeriSign experienced a sudden and dramatic increase in the number of requests by Windows-based clients to download a certificate revocation list (CRL). The CRL is a file which confirms the validity status of a set of certificates, and is used by applications and users to determine whether a particular certificate has been revoked between the time it was issued and the time it will expire. The CRL in question was for a code-signing application. VeriSign normally serves up several million CRLs per hour. These CRLs typically have one- to two-week validity periods, and client applications using CRLs will check for an update as the CRL expires. The Code Signing CRL was supplied to a large number of Windows clients. When that CRL expired, those clients simultaneously requested a particularly large CRL file, resulting in an eight-fold increase in traffic at the site crl.verisign.com, where VeriSign hosts all our CRLs. As a result, As a result, Windows-based browsers requesting status of certain server certificates have experienced intermittent delays. VeriSign has increased its capacity to handle these requests by 10 fold in the past 8 hours. As the particular code-signing CRL file is no longer a dynamically changing, there will be no need for clients, once they have downloaded this file, to request a new version of this particular CRL. While this does not represent a security risk, it may have represented a performance degradation for some users. VeriSign regrets the inconvenience caused to customers, and has implemented procedures both internally, and with our partners, to ensure that this problem does not reoccur. Please note that this problem is in no way related to the Intermediate CA expiration issue discussed on our site at http://www.verisign.com/support/vendors/exp-gsid-ssl.html?sl=070807. Although the expiration dates are the same, it is strictly a coincidence in timing. -- Snip -- ObComment again: Ahh, the wonders of doing an online CRL fetch that feeds you information that's two weeks out of date. I'm not sure what the no longer dynamically changing means, I assume they've made it even worse by giving it a much larger expiry period, so your online check gives you the status from last year instead of last week. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptonomicon.Net - Key Splitting : First (and Second) Person Key Escrow
R. A. Hettinga [EMAIL PROTECTED] quotes: One of our missions here at Cryptonomicon.Net is to advocate the use of appropriate cryptographic technology. One technology that's sorely missed in a number of commercial products is key splitting. Never heard of key splitting? That's not surprising. It's not surprising because there's no demand for it. A number of commercial (crypto hardware) products do it, but only as a backup mechanism / to allow key migration into new hardware units. Every vendor has their own techniques for this, which fit their existing key management mechanisms. I talked to some people about doing a standard for this a while back, but given the vast number of implementation details you'd have to accomodate and the absence of demand for it, it never went any further than that. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Examining the Encryption Threat
Peter Parker [EMAIL PROTECTED] writes: In one of the issue of ijde found at http://www.ijde.org/docs/04_winter_v2i3_art1.pdf the authors have analysed various encryption applications and discussed results for few sample applications. Does any one have the complete results. Tried mailing the author but no response. Any one having further info. To save people downloading the PDF, it's an 11-page article that reinvents the 'file' command. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The future of security
Anton Stiglic [EMAIL PROTECTED] writes: I think cryptography techniques can provide a partial solution to spam. No they won't. All the ones I've seen are some variant on the build a big wall around the Internet and only let the good guys in, which will never work because the Internet doesn't contain any definable inside and outside, only 800 million Manchurian candidates waiting to activate. For example MessageLabs recently reported that *two thirds* of all the spam it blocks is from infected PCs, with much of it coming from ADSL/cable modem IP pools. Given that these spammers are legitimate users, no amount of crypto will solve the problem. I did a talk on this recently where I claimed that various protocols designed to enforce this (Designated Mailers Protocol, Reverse Mail Exchanger, Sender Permitted From, etc etc) will buy at most 6-12 months, and the only dissent was from an anti-virus researcher who said it'd buy weeks and not months. The alternative proof-of-resource-consumption is little better, since it's not the spammers' resources that are being consumed. There is one technological solution which would help things a bit, which is Microsoft implementing virus throttling in the Windows TCP stack. Like a firebreak, you can never prevent fires, but you can at least limit the damage when they do occur. Unfortunately I don't see this happening too soon, both because MS aren't exactly at the forefront of implementing security features (it took them how many years to add the most basic popup-blocking?), and because of liability issues - adding virus throttling would be an admission that Windows is a petri dish. The problem we're facing is social, not technological, so no there's no technological fix. The problem is that neither users nor vendors have any natural incentive to fix things. In the long run, only legislation will help: penalise vendors for selling spam-enabling software (MS Outlook, via viruses/worms), and penalise users for running software in a spam-enabling manner (open relays). This is equivalent to standard corporate-governance legislation that sets auditing/environmental/due diligence/etc requirements. Unfortunately this is unlikely to pass in the US (where it matters most) due to software industry lobbying, it'd require an Enron-style debacle to pass over there, perhaps a virus-induced reactor meltdown or something similar. (Much of the above was lifted from Why isn't the Internet secure yet, dammit?, http://www.cs.auckland.ac.nz/~pgut001/pubs/dammit.pdf, with the section on spam starting at page 5. Apologies for the PDF link, but there are some diagrams in there that don't translate well to text). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Russell Nelson [EMAIL PROTECTED] writes: It would be better if the solution does NOT need industry support at all, only user support. It should use what is already available. This is the point in the script at which I laugh at you, Ed. S/MIME and PGP have been available for many many years now. How many messages to the Cryptography Mailing List are cryptographically signed? If it was going to happen, it would have *already* happened. It *is* happening, only it's now called STARTTLS (and if certain vendors (Micromumblemumble) didn't make it such a pain to set up certs for their MTAs but simply generated self-signed certs on install and turned it on by default, it'd be happening even more). How many messages to the Cryptography Mailing List are cryptographically signed? The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Yahoo releases internet standard draft for using DNS as public key server
Russell Nelson [EMAIL PROTECTED] writes:
Peter Gutmann writes:
STARTTLS
If Alice and Cathy both implement STARTTLS, and Beatty does not, and Beatty
handles email which is ultimately sent to Cathy, then STARTTLS accomplishes
nothing. If Uma and Wendy implement DomainKeys, and Violet does not, and
Violet handles email which is ultimately sent to Wendy, then Wendy can check
Uma's signature.
Since none of Uma, Wendy, or Violet implement DomainKeys or even know what
they are, DomainKeys accomplishes nothing. OTOH if their { ISP, company,
whatever } has STARTTLS enabled, they're getting their email encrypted without
even knowing about it and are having better-than-average security applied to
their POP/IMAP mail account, again without even knowing about it (I suspect
the latter is far more of a selling point to users than encryption. No-one
would want to read their mail anyway so they're not worried about that, but if
it stops those nasty hackers from breaking into their account, it's a good
thing).
If, instead, Perry had a list of PGP keys and email addresses, he wouldn't
*need* to compare the email address on the incoming email.
He'd instead need to spend even more time mucking around with keyrings and
updating keys and writing scripts to handle all the checking and wondering why
it all has to be so complicated, and maybe he should just ask people to fax in
submissions.
Peter.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Article on passwords in Wired News
An article on passwords and password safety, including this neat bit: For additional security, she then pulls out a card that has 50 scratch-off codes. Jubran uses the codes, one by one, each time she logs on or performs a transaction. Her bank, Nordea PLC, automatically sends a new card when she's about to run out. http://www.wired.com/news/infostructure/0,1377,63670,00.html One-time passwords (TANs) was another thing I covered in the Why isn't the Internet secure yet, dammit! talk I mentioned here a few days ago. From talking to assorted (non-European) banks, I haven't been able to find any that are planning to introduce these in the foreseeable future. I've also been unable to get any credible explanation as to why not, as far as I can tell it's We're not hurting enough yet. Maybe it's just a cultural thing, certainly among European banks it seems to be a normal part of allowing customers online access to banking facilities. (If anyone from the outside-Europe banking industry can provide me with an explanation for non-use of TANs that goes beyond We're looking into it, I'd be interested in hearing from them). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Chalabi Reportedly Told Iran That U.S. Had Code
On a semi-related note, there's ex-Iraqi crypto gear for sale on e-bay at http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemcategory=296item=2249455706rd=1. Only used once by a slightly gullible/careless owner... It'd be interesting for someone with too much spare time on their hands to buy one of these and try and figure out what customised-for-Iraq supplemental functionality it contains. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Breaking Iranian Codes (Re: CRYPTO-GRAM, June 15, 2003)
R. A. Hettinga [EMAIL PROTECTED] forwarded: So now the NSA's secret is out. The Iranians have undoubtedly changed their encryption machines, and the NSA has lost its source of Iranian secrets. But little else is known. Who told Chalabi? Only a few people would know this important U.S. secret, and the snitch is certainly guilty of treason. Someone (half-)remembered reading the Crypto AG story in the Baltimore Sun several years ago, bragged to Chalabi that the US had compromised Iranian crypto, and the story snowballed from there. The story could have started out with a loquacious (Sun-reading) cab driver for all we know. Some reports have suggested the source was drunk, so maybe it was a drunk in a bar. Maybe Chalabi read the story himself and invented the snitch to make it seem more important than it was, or to drive the US security community nuts with an orgy of internal witch-hunting. Given the lack of further information, it could have been just about anything. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: recommendations/evaluations of free / low-cost crypto libraries
Anton Stiglic [EMAIL PROTECTED] writes: A list can be found here http://www.homeport.org/~adam/crypto/ Hmm, that list is somewhat out of date (several years in some cases). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on the state of the security industry
Steve Furlong [EMAIL PROTECTED] writes: On Wed, 2004-06-30 at 06:49, Ian Grigg wrote: Here's my question - is anyone in the security field of any sort of repute being asked about phishing, consulted about solutions, contracted to build? Anything? Nothing here. Spam is the main concern on people's minds, so far as I can tell. I never considered phishing to be much of an issue until about a month ago, when I had a long discussion with someone at a security conference about a scale and type of phishing you never really hear about much. Not small-scale script-kiddie stuff but large-scale phishing run as a standard commercial business, with (literally) everything but 24-hour helpdesks (if you can read Portuguese you may be able to find more info at http://www.nbso.nic.br/). Some of this I've already covered in the Why isn't the Internet secure yet tutorial I mentioned a while back: Trojans that control your DNS to direct you to fake web sites, trojans that grab copies of legit web sites from your browser cache and render them asking for your to re-validate yourself since your session has expired, trojans that intercept data from inside your browser before it gets to the SSL channel, etc etc. This isn't stuff that only newbies will fall for, these are exact copies of the real site that look and act exactly like the real site. This stuff is the scariest security threat I've heard of in (at least) the last couple of years because it's almost impossible to defend against. There is simply no way to protect a user on a standard Windows PC from this type of attack - even if you can afford to give each user a SecurID or crypto challenge-response calculator, that doesn't help you much because the attacker controls the PC. It's like having users stick their bank cards into and give their PIN to a MafiaBank branded ATM, the only way to safely use it is to not use it at all. The only solution I can think of is to use the PC only as a proxy/router and force users to do their online banking via a small terminal (not running Windows) that talks to the PC via the USB port, but it's not really economically viable. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Using crypto against Phishing, Spoofing and Spamming...
Enzo Michelangeli [EMAIL PROTECTED] writes: Can someone explain me how the phishermen escape identification and prosecution? Gaining online access to someone's account allows, at most, to execute wire transfers to other bank accounts: Some (a lot of?) large-scale phishing is done by or with the aid of international organised crime, who have a great deal of experience in making money disappear (or reappear in cleaned form). Even without that expertise, there are many, many ways to launder the money. One that I heard of recently is to go to small in-debt businesses and offer to pay off their debt, with the business then paying back half that in cash to the phisher. The business has half their debt paid off, and the phisher has converted their wire transfer into untraceable cash. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
Sean W. Smith [EMAIL PROTECTED] writes: I would have thought that de facto standard approach is: the client constructs the certificate request message, which contains things like the public key and identifying info, and signs it. The CA then checks the signature against the public key in the message. A depressing number of CAs generate the private key themselves and mail out to the client. This is another type of PoP, the CA knows the client has the private key because they've generated it for them. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
Anne Lynn Wheeler [EMAIL PROTECTED] write: the assertion here is possible threat model confusion when the same exact technology is used for two significantly different business purposes. I don't think there's any confusion about the threat model, which is Users find it too difficult to generate keys/obtain certs, so if the CA doesn't do it for them the users will complain, or not become users at all. Having the CA generate the key addresses this threat model. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
Richard Levitte - VMS Whacker [EMAIL PROTECTED] writes: Peter, are you talking about generic CAs or in-corporation ones? Both. Typically what happens is that the CA generates the key and cert and mails it to the user as a PKCS #12 file, either in plaintext, with the password in the same email, or occasionally with the password in separate email. See How to build a PKI that works on my home page (direct link at http://www.cs.auckland.ac.nz/~pgut001/pubs/howto.pdf, Challenge #2 starting on p.25) for details, including a few sample quotes from users. I can definitely see different needs between those. Actually they both seem to have the same need, it's the least effort to do it this way. Occasionally you see it dressed up as something else, e.g. We don't trust our users to generate the keys properly themselves (one of those was from a CA that's distinguished itself through the bugginess of its software, which makes the comment rather amusing coming from them), but it almost always boils down to the same thing. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: dual-use digital signature [EMAIL PROTECTED]
[EMAIL PROTECTED] writes: 2 centsIn the business cases pointed out where it is good that the multiple parties hold the private key, I feel the certificate should indicate that there are multiple parties so that Bob can realize he is having authenticated and private communications with Alice _and_ Alice's employer. X.509 does not provide a standard way to encode multiple subjects./2 cents Yes it does, if you needed this you could add an extension (say) additionalRecipients with a SEQUENCE of GeneralName naming the additional parties listening in. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
NIST announces (proposed) withdrawal of DES
For those who haven't seen the announcement: -- Snip -- July 27, 2004 -- NIST has determined that the strength of the (single) Data Encryption Standard (DES) algorithm is no longer sufficient to adequately protect Federal government information. As a result, NIST proposes withdrawing FIPS 46-3, which specifies the DES, and two related standards (see http://csrc.nist.gov/Federal-register/July26-2004-FR-DES-Notice.pdf). Future use of DES by Federal agencies is to be permitted only as a component function of the Triple Data Encryption Algorithm (TDEA; see NIST Special Publication 800-67 at http://csrc.nist.gov/publications/nistpubs/800-67/SP800-67.pdf). TDEA may be used for the protection of Federal information; however, NIST encourages agencies to implement the faster and stronger algorithm specified by FIPS 197, Advanced Encryption Standard (AES) instead. Comments must be received on or before September 9, 2004. To submit comments, concerns or questions please forward them to: [EMAIL PROTECTED] Elaine Barker National Institute of Standards and Technology 100 Bureau Dr., Stop 8930 Gaithersburg, MD 20899-8930 Phone: 301-975-2911 Fax: 301-926-2733 Email: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: dual-use digital signature [EMAIL PROTECTED]
[EMAIL PROTECTED] writes: Your certificate definition says additionalRecipients, mine says additionalSubjects, Fred-over-there's says coKeyOwners. The OIDs for these extensions end up all different. A human may be able to parse the intent from the ASN.1 it but email programs will have difficulty. What I meant was that if there was any demand for this, someone would define a standard place to store the info, which apps would (eventually) display. At the moment there's neither a additionalRecipients, a additionalSubjects, a coKeyOwners, or anything else, because no-one's ever asked for it. Given the complete lack of demand for this to date I suspect that even if you did do an RFC for it it'd be relegated to Experimental status and everyone would ignore it... what exactly is the intent of adding this information? Under what circumstances would it be used? What's the UI for it? Do you throw up a warning? Warning of what? If it's Others are listening in then the alternative is to not use the cert at all, in which case the choice given to the users will be Allow one or two others to listen in vs. Allow anyone to listen in, since everyone will choose the former there's not much point in putting it there in the first place. etc etc etc. (There have been similar suggestions made about other warn-the-user type features on the S/MIME list, which tend to get shot down with some variant of I wouldn't even know how to begin to do a UI for this, with a backup of This amounts to giving the user a choice of communicate or don't communicate, guess which one they'll choose?). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: should you trust CAs? (Re: dual-use digital signature vulnerability)
Aram Perez [EMAIL PROTECTED] writes: I agree with Michael H. If you trust the CA to issue a cert, it's not that much more to trust them with generating the key pair. Trusting them to safely communicate the key pair to you once they've generated it is left as an exercise for the reader :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Microsoft .NET PRNG (fwd)
Forwarded here as the original forum is having no success. [...] I'm looking for the same information. I want to know which method does MS Crypto API use in order to obtain strong random seeds. This is cross-posted back to the original list (with snippets from various postings) to try and tie up the loose ends: Peter Gutmann's paper on randomness describes the algorithms used, at least in some/most versions. It's possible it's been changed at some recent point in time. You can find it here: http://www.cypherpunks.to/~peter/06_random.pdf. That's based on what was known of the CAPI PRNG at the time, there's a more up-to-date version of that in Cryptographic Security Architecture Design and Verification, but that also predates the most recent information on the generator, which is the second edition (not the first) of Writing Secure Code by Michael Howard and David LeBlanc. It also appears that the generator itself has changed somewhat over time, with more recent versions being rather better than the earlier ones. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Good quote about the futility of ID-checking
Yeterday I watched Gillo Pontecorvo's 1966 film The Battle of Algiers, a dramatisation of real events that looks at France's own war on terror in Algeria in the 1950s. The police attempt to control things by only allowing people who can show valid ID into the european quarter of Algiers via a few checkpoints. When this proves completely ineffective, the French army, led by a Colonel Mathieu, is called in. The first thing he does is show his troops film footage of the checkpoints and the ID checking, pointing out that this footage is useful because it illustrates how not to do things: Checking identity papers is a complete waste of time. If anyone can be counted on to have valid papers, it will be the terrorists. That's actually a rather astute observation: Joe Sixpack will be lucky to remember to bring their passport, let alone check whether it's currently valid and every little detail is correct, but any terrorist will triple-check every bit of it to make sure that they don't get picked out. The best that the ID- checking can hope to do is stop opportunists (as well as any number of innocent Joe Sixpacks). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Compression theory reference?
Hadmut Danisch [EMAIL PROTECTED] writes: I need a literature reference for a simple problem of encoding/compression theory: comp.compression FAQ, probably question #1 given the number of times this comes up in the newsgroup. (I've just checked, it's question #9 in part 1. Question #73 in part 2 may also be useful). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [anonsec] Re: potential new IETF WG on anonymous IPSec (fwd from [EMAIL PROTECTED]) (fwd from [EMAIL PROTECTED])
Steven M. Bellovin [EMAIL PROTECTED] writes: Maybe it's worth doing some sort of generic RFC for this security model to avoid scattering the same thing over a pile of IETF WGs, Sounds good. Who wants to write it...? Since there seems to be at least some interest in this, I'll make a start on it. If anyone else wants to add their $0.03 to it [0], let me know. Peter. [0] Or $0.04 if you're paying in Euros. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Certificate serial number generation algorithms
Eric Rescorla [EMAIL PROTECTED] writes: In particular, Verisign's is very long and I seem to remember someone telling me it was a hach but I don't recall the details... It's just a SHA-1 hash. Many CAs use this to make traffic analysis of how many (or few) certificates they're issuing impossible. An additional motivation for use by Verisign was to avoid certs with low serial numbers having special significance. While there are a few CA's that follow the monotonically-increasing-integers scheme that certs were originally intended to have (and all manner of other weirdness, 32-bit integer IDs of unknown origin seem to be popular in the other category), most seem to use a binary blob of varying length. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
[EMAIL PROTECTED] writes: No need to buy a company just to use its product in your development shop. They're not using it in their development shop, that's their standard development environment that they ship to all Windows CE, Pocket PC, SmartPhone, and XP Embedded developers (and include free with every copy of MSDN). If an entire branch of my OS development was centered around a particular technology, I'd want to make sure I owned both the technology and the developers who created it and will be maintaining/updating it in the future. This isn't an optional add-on that MS uses internally, it's a core component of their embedded OS effort that they push out to anyone who'll take it in an attempt to dissuade them from going with QNX, embedded Linux, VxWorks, etc etc. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Anti-RFID outfit deflates Mexican VeriChip hype
R.A. Hettinga [EMAIL PROTECTED] forwarded: Promoting implanted RFID devices as a security measure is downright 'loco,' says Katherine Albrecht. Advertising you've got a chip in your arm that opens important doors is an invitation to kidnapping and mutilation. Since kidnapping is sort of an unofficial national sport in Mexico (or at least Mexico City), this is particularly apropos. An implanted RFID seems to be just asking for an express kidnap, something more traditionally used to get money from ATMs. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
Steven M. Bellovin [EMAIL PROTECTED] writes: Is a private root key (or the equivalent signing device) an asset that can be acquired under bankruptcy proceedings? Almost certainly. Absolutely certainly. Even before Baltimore, CA's private keys had been bought and sold from/to third parties, usually as a result of bandruptcies or takeovers. You can also occasionally find lesser CA's keys left in crypto gear sold on ebay or similar surplus-disposal channels. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How to Stop Junk E-Mail: Charge for the Stamp
Barry Shein [EMAIL PROTECTED] writes: Eventually email will just collapse (as it's doing) and the RBOCs et al will inherit it and we'll all be paying 15c per message like their SMS services. And the spammers will be using everyone else's PC's to send out their spam, so the spam problem will still be as bad as ever but now Joe Sixpack will be paying to send it. Hmmm, and maybe *that* will finally motivate software companies, end users, ISPs, etc etc, to fix up software, systems, and usage habits to prevent this. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: That's gratitude for ya...
Rich Salz [EMAIL PROTECTED] writes: Why would mozilla embed this? If they came here, to the putative experts, for an evaluation, they'd leave thinking Amir and company just invented Rot-13. It's not that. It's also not perfect. BFD -- you got anything better? This ties in to one of my favourite articles on security usability, Good- Enough Security: Toward a Pragmatic Business-Driven Discipline, Ravi Sandhu, IEEE Internet Computing, Vol.5, No.3 (January/February 2003), p.66, or http://www.list.gmu.edu/journals/ic/03-sandhu-good.pdf if you don't get the print version. This contains observations like: How many security engineers would it take to design a system for ATM security today? I don't think it could be done. We would be debating biometric-enabled smartcards, assurance, protection profiles, denial of service, non-repudiation, viruses and buffer-overflow attacks till we were blue in the face. There is no way that such a system with good enough security could be designed and built today on the basis of conventional security wisdom. Yet it happened. And it works. The author offers three design principles for good-enough security: 1. Good enough is good enough. 2. Good enough always beats perfect. 3. The really hard part is determining what is good enough. I think Trustbar does a pretty good job of getting (3) right. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to phase in new hash algorithms?
Steven M. Bellovin [EMAIL PROTECTED] writes: We all understand the need to move to better hash algorithms than SHA1. At a minimum, people should be switching to SHA256/384/512; arguably, Whirlpool is the right way to go. The problem is how to get there from here. So -- what should we as a community be doing now? Kick it upstairs to the political layer. Someone else's problem, we've already shown them what the solution is, our job is done. Peter :-). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: and constrained subordinate CA costs?
Erwann ABALEA [EMAIL PROTECTED] writes: On Fri, 25 Mar 2005, Florian Weimer wrote: * Adam Back: Does anyone have info on the cost of sub-ordinate CA cert with a name space constraint (limited to issue certs on domains which are sub-domains of a your choice... ie only valid to issue certs on sub-domains of foo.com). Is there a technical option to enforce such a policy on subordinated CAs? Yes, the nameConstraints extension. But nobody checks it, and since this extension MUST be critical as per RFC3280, it invalidates the CA certificate that includes it, making it useless, for now. Not necessarily, some implementations also ignore the critical flag, so the cert is treated as valid, although the entire extension is ignored. However a corollary of this is that because of the hit-and-miss nature of support for the extension, you can't rely on it unless you carefully control all of the software that's used to process certs and make sure that it handles everything correctly. (Even if your app supports name constraints, there are some rather arcane matching rules in the spec that a number of apps get wrong, so there's a whole range of behaviours that you can encounter when you put a nameConstraints extension in a cert). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Invalid banking cert spooks only one user in 300
Invalid banking cert spooks only one user in 300 Stephen Bell, Computerworld 16/05/2005 09:19:10 Up to 300 New Zealand BankDirect customers were presented with a security alert when they visited the bank's website earlier this month - and all but one dismissed the warning and carried on with their banking. The rest of the story is at http://www.pcworld.idg.com.au/index.php/id;1998944536;fp;2;fpid;1 or http://www.computerworld.co.nz/news.nsf/0/FCC8B6B48B24CDF2CC2570020018FF73?OpenDocumentpub=Computerworld (PC World Australia or ComputerWorld NZ). To provide a little more background information, BankDirect is an online-only offshoot of another bank (ASB) that's targeted at computer-savvy users who don't need (or want) the expense of a standard bricks-and-mortar account. There are no branches, and payment is done electronically at the point of sale (EFTPOS) and managed via the Internet or a cellphone, thus the (apparently) low number of accesses - you'd generally rarely need to access it over the net. So in other words the number of computer-savvy users who were stopped by an invalid server cert at a banking site was essentially zero. To quote the article again: Peter Benson, chief executive of Auckland-based Security-Assessment.com, says he is not at all surprised at the statistics. In my experience, the single weakest point in the chain of [computer] security is the space between the keyboard and the floor. A lot more education of users in responding appropriately to security alerts is needed, he says. Looks like we have a long way to go in making effective security usable. Note that if the same site had used TLS-PSK (http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-08.txt) instead of straight passwords over TLS, and had this been malicious spoofing instead of just an accident, none of this would have been possible (TLS-PSK provides mutual authentication of both parties before any sensitive information is exchanged, so even if the user ignores the warning, they won't be able to communicate with a spoofed site). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Citibank discloses private information to improve security
James A. Donald [EMAIL PROTECTED] writes: With bank web sites, experience has shown that only 0.3% of users are deterred by an invalid certificate, probably because very few users have any idea what a certificate authority is, what it does, or why they should care. James (and others): I really wouldn't cite the BankDirect figure as a hard value, since it represents just a single user, who may in turn have clicked on the wrong button (i.e. the real figure could have been 0%). It'd be better to say statistically insignificant or negligible or some other close-to-or- equal-to-zero synonym. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Citibank discloses private information to improve security
Heyman, Michael [EMAIL PROTECTED] writes: In this situation, I believe that the users, through hard won experience with computers, _correctly_ assumed this was a false positive. Probably not. This issue was discussed at some length on the hcisec list, (security usability, http://groups.yahoo.com/group/hcisec/), e.g: -- Snip -- In my experience with helping out non-technical users, certificates are treated as a purely boolean option, either they're valid or they're not. In fact usually the validity of certificates isn't even an option, either you get a warning dialog or you don't, the actual text may as well be written in Swahili. People don't understand (or maybe don't want to understand) the technical explanations that browsers throw up for them. So an expired cert would have the same status as one for the wrong site or a dozen other reasons why the browser would throw up a warning. I did some even less rigorous checking (i.e. asked a few users who were handy) why they would have done something like this if they'd been one of the 300 and their response was that since it was a known site that they'd dealt with before, they'd assume it was some config error and continue anyway. Several of them had had similar problems with things like hotmail (that is, not SSL- related but just general it didn't work when I tried it problems), where clicking OK to get rid of warnings or waiting half an hour and trying again had fixed things. This was just another random site error that they would have navigated around. -- Snip -- For more discussion, see the list archives. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Citibank discloses private information to improve security
Heyman, Michael [EMAIL PROTECTED] writes: The false positive I was referring to is the something is telling me something unimportant positive. I didn't mean to infer that the users likely went through a thought process centered around the possible causes of the certificate failure, specifically the likelihood of an active man-in-the- middle vs. software bug, vs. setup error, vs. etc.. Oh, I see. So we were actually in violent agreement :-). I've probably seen hundreds of signature validation warnings from various web-sites for certificates and Active-X and possibly other signed content. I can't recall needing to heed even one of the warnings. We are trying to detect man-in-the-middle or outright spoofing with signatures and our false positive rate is through the roof. The false positive rate must be zero or nearly zero to work as a useful detector in real world situations. It's not just passive false-positive acceptance, users are actively encouraged by software vendors to accept verification-failed content. For example every other hardware device you install, as part of it's connect-the-dots sequence of screen shots in the install guide, shows a shot of some sort of signature- warning dialog, along with an arrow pointing to the Ignore this warning button to click and text telling users to, well, do what the button says. Even things like WHQL-certified drivers, which should have all the correct credentials, end up being installed in non-certified ways because the vendors submit a safe-but-slow configuration to get certified and then ship the unsafe-but-fast one to be installed (this is standard practice for any hardware where performance is the main selling point, i.e. video drivers, RAID drivers, network drivers, etc etc). Alternatively, the latest bugfix drivers are several steps ahead of the certified WHQL'd ones, so you get the same thing. For non-Windows users who haven't seen this sort of user-conditioning in documentation, here's the first half-dozen online examples of this (to save me having to scan install guides to demonstrate it): http://www.msha.gov/TECHSUPP/ACC/shortcircuit/install.htm http://support.academic.com/knowbase/root/public/acdm9103.htm http://mail.regent-college.edu/wireless/printer/w98/ http://home.cfl.rr.com/dogone/Download.htm http://129.171.91.6/firewall/InstallConfig/msie_instruction.cfm http://www.rochester.edu/its/wireless/win_IE_certificate.html Note also that the warnings for valid and invalid signed content are extremely similar, and both contain lots of text, jargon, and incomprehensible (to the average user) information. Both in effect state Mumble mutter fnord fnord, do you want to go ahead, with the fnord-level for the valid-signature dialog being at least as high as the invalid-signature one. It'd be interesting to see if users can tell the difference between the two. This one is particularly cool: Don't get worried by the JPilot Security Warning! Just click YES to install run applet. If you don't, you can't chat!: http://mc2.vicnet.net.au/help/chathelp.html (Don't worry about those nasty warnings, just close your eyes and click your heels tog^H^H^H^Hclick OK). Just to show that it's not just ActiveX signing under Windows that's training users in this manner, here's a Unix one too: http://apps.cybersource.com/library/documentation/dev_guides/Microsoft_Commerce_Server_2002/html/install.htm Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Rich Salz [EMAIL PROTECTED] writes: I think signatures are increasingly being used for technical reasons, not legal. That is, sign and verify just to prove that all the layers of middleware and Internet and general bugaboos didn't screw with it. That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Anne Lynn Wheeler [EMAIL PROTECTED] writes: the problem was that xml didn't have a deterministic definition for encoding fields. Yup, see Why XML Security is Broken, http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt, for more on this. Mind you ASN.1 is little better, there are rules for deterministic encoding, but so many things get them wrong that experience has shown the only safe way to handle it is to do an exact bit-for-bit copy from A to B, rather than trying to re-code at any point. I've frequently commented that there is only one workable rule for encoding objects like X.500 DNs, and that's memcpy(). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Ben Laurie [EMAIL PROTECTED] writes: Anne Lynn Wheeler wrote: Peter Gutmann wrote: That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation. this was one of the big issues in the asn.1 encoding vis-a-vis xml encoding wars. asn.1 encoding provided deterministic encoding for signed material, You mean it _would_ have done if anyone could implement it correctly. Sadly, experience shows that no-one can. Right, but that's lead to a de-facto encoding rule of The originator encodes it however they like, and everyone else re-encodes it (if required) using memcpy(). The advantage of the format is that it's never tried to be anything other than a pure binary-only format, so moving it over text-only channels is handled at the next layer down (usually base64), rather than trying to make the encoding itself text-only-capable and then finding yourself in a world of pain when half the systems the stuff passes through mangle the text. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AmEx unprotected login site
Perry E. Metzger [EMAIL PROTECTED] writes: Steven M. Bellovin [EMAIL PROTECTED] writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of the page. They're doing the wrong thing, and probably feel they have no choice. Setting up an SSL session is expensive; most people who go to their . home page do not log in, and hence do not (to Amex) require cryptographic protection. That's why Citibank and most well run bank sites have you click on a button on the front page to go to the login screen. There are ways to handle this correctly. I was just going to mention this myself because I've noticed local banks doing it, you click on some log in for online banking link and get to an HTTPS login page that's distinct from the HTTP main page. For Mozilla/Firefox users, grab a copy of the TargetAlert extension and you'll see this on the originating page, TargetAlert will tag the login link with the opens in new window indicator and the HTTPS indicator (the usual yellow padlock). When you've got TargetAlert installed, go to e.g. http://www.asbbank.co.nz/ to see this. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital signatures have a big problem with meaning
Rich Salz [EMAIL PROTECTED] writes: Peter's shared earlier drafts with me, and we've exchanged email about this. The only complaint that has a factual basis is this: I don't want to have to implement XML processing to do XML Digital Signatures I don't want to have to re-implement Apache in order to do an SSL implementation. I don't want to have to re-implement MS Exchange in order to do a PGP implementation. I don't want to have to re-implement ext2fs in order to encrypt a file. Makes sense to me. The other problem with XML sigs (also pointed out in the writeup) is the fact that it gives you 10 ways to do everything, of which only 1 is actually correct/secure/usable, but is indistinguishable from the other 9. Since ease of use/secure-by-default is a major goal of my work, I'm rather reluctant to implement something that lets users blow their feet off in a dozen different ways without even knowing it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: encrypted tapes (was Re: Papers about Algorithm hiding ?)
Jerrold Leichter [EMAIL PROTECTED] writes: They also sold a full solution for encrypted Ethernet - KDC, encrypting Ethernet adapters, associated software. None of this stuff went anywhere. People just weren't interested. That wasn't quite the case for the Ethernet encryption. What happened there was that they had a complete product ready to ship and quite a bit of interest when it was killed by marketing. The problem was that Ethernet at the time wasn't the forgone conclusion it is now, it was just one of a number of potential candidates for the foregone-conclusion role. By shipping an encrypting Ethernet adapter, marketing felt that DEC were saying that standard Ethernet wasn't safe. In contrast token ring didn't have an encryption adapter, so obviously token ring must be secure by default, whereas Ethernet clearly wasn't. As a result, the encryption adapter was never shipped. Strategy is not letting the enemy know you're out of bullets by continuing to fire. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
[EMAIL PROTECTED] (Hal Finney) writes: Steven M. Bellovin writes: Dan Bernstein has a new cache timing attack on AES: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf This is a pretty alarming attack. It is? Recovering a key from a server custom-written to act as an oracle for the attacker? By this I don't even mean the timing-related stuff, but just one that just acts as a basic encryption oracle. Try doing that with TLS or SSH, you'll get exactly one unrelated packet back, which is the connection shutdown message. So while it's a nice attack, section 15 should really be simplified to: Don't do that, then. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Stephan Neuhaus [EMAIL PROTECTED] writes: Concerning the practical use of AES, you may be right (even though it would be nice to have some advice on what one *should* do instead). Definitely. Maybe time for a BCP, not just for AES but for general block ciphers? But as far as I know, resistance to such attacks was one of the design goals for AES. I find it pretty alarming that in spite of all the review that AES got, this design goal was not met, and in an exploitable fashion to boot. Well, it depends on what your design assumptions were. I assume AES went with a basic Newtonian physics-level approximation of the world that's good enough for most cases without going into so much specialised detail that it becomes unworkable. In fact I'd say it's actually not possible to certify resistance to timing attacks across all possible CPUs, because it'll always be possible to find some oddball CPU for which an AES-critical instruction somewhere has some weird characteristic that helps in an attack. Lets say you want constant timing for at least the most common CPU family, x86. But that's way too broad, so you restrict it to Intel x86. That still covers far too many architectures to be useful, so you say Intel P4 x86. But there are multiple P4 cores that all perform differently, so you decide on the Northwood core. Now, which stepping of that core do you want to use? So in the end you've got an algorithm design that happens to be resistant to timing attacks on the D0 stepping of a Northwood-core Intel P4. Anything else and all bets are off. This doesn't seem very useful to me. I think this says more about the standardization and review process than about AES. I think the standardisation process went about as well as can be expected, given Newtonian physics-level assumptions about how CPUs work. Once you start getting into special relativity-level analysis, the model gets a bit more precise, but you also need a small book of explanatory notes for each situation, and it becomes impossible to ship any normal product if you require per-core-stepping tuning. So I'll stick by my comment that the only really practical way to address this is with Don't do that, then. Now, as you point out, we need a BCP on what not to do. I'd suggest not just a basic don't do this but also a do do this, along with a list of common solutions that get it right: SSL/TLS, SSH, IPsec, etc etc. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Ian G [EMAIL PROTECTED] writes: Definitely. Maybe time for a BCP, not just for AES but for general block ciphers? What is a BCP? Best Coding Practices? Block Cipher Protocol? Best Current Practice, a special-case type of RFC. Based on recent experience with this style of collaborative document editing, I've set up a wiki at http://blockcipher.pbwiki.com/, blank username, password 'sbox', for anyone who wants to add their $0.02 about what to do/what not to do to protect block ciphers from side-channel attacks. If it works out, this could turn into a BCP. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: massive data theft at MasterCard processor
Peter Fairbrother [EMAIL PROTECTED] writes: Steven M. Bellovin wrote: Designing a system that deflects this sort of attack is challenging. The right answer is smart cards that can digitally sign transactions No, it isn't! A handwritten signature is far better, it gives post-facto evidence about who authorised the transaction - it is hard to fake a signature so well that later analysis can't detect the forgery, and few people would bother to do it that well anyway, while it is easy enough to enter a PIN with digital reproducibility. Not only that, you can mess up the transaction without even wanting to do it fraudulently. With PIN-based authentication (at least every one I've ever seen), you insert your card, enter your PIN to authorise the transaction, and then it prints your receipt. As you point out, there's no link between the paper trail and the authorisation, and by the time you get to see the paper trail it's too late to do anything about it. Running a two-phase commit to fix this is unworkable (it'd double the number of transactions and require holding state at the acquirer gateway), and even then it doesn't tie the authorisation to the paper trail. Consider a recent example, in which a hotel inadvertently charged me twice for one stay. The first time they ran the transaction on the handheld card terminal the built-in printer ran out of paper, so they reversed the charge and charged me a second time with a new roll of paper in the printer. Since I didn't trust them to get this right, I asked for both printouts, wrote VOID on the first one, and signed the second one. As it turned out, they didn't get it right, and I have a pretty clear paper trail to prove that the first transaction wasn't authorised. If I'd done this with a PIN, both would have been authorised, because I can only take the merchant's word for it that they've cleared up the first transaction for me - the client has to go to some lengths to prove their credentials, but the merchant only has to claim that they've sorted it out. In fact I don't think there's any way for them to prove to a client that they've reversed a transaction short of phoning their bank and getting them to fax out a statement. So I'll stick with printouts and signatures for the foreseeable future. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Ian G [EMAIL PROTECTED] writes: On Tuesday 21 June 2005 13:45, Peter Gutmann wrote: Best Current Practice, a special-case type of RFC. Based on recent experience with this style of collaborative document editing, I've set up a wiki at http://blockcipher.pbwiki.com/, blank username, password 'sbox', for anyone who wants to add their $0.02 about what to do/what not to do to protect block ciphers from side-channel attacks. If it works out, this could turn into a BCP. That's what I like, action, not words! To celebrate this, I've stuck some words in there which others can act on ;-) Uhh, that wasn't really what I was after, that's pretty much textbook stuff, what I wanted was specifically advice on how to use block ciphers in a way that avoids possibilities for side-channel (and similar) attacks. I have some initial notes that can be summarised as Don't let yourself be used as an oracle that I was planning to add after I've fleshed them out a bit. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES cache timing attack
Ian Grigg [EMAIL PROTECTED] writes: Alternatively, if one is in the unfortunate position of being an oracle for a single block encryption then the packet could be augmented with a cleartext random block to be xor'd with the key each request. Moves you from being an encryption oracle to a related-key oracle, and makes the protocol non-idempotent. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the limits of crypto and authentication
[EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic transactions as well. The way it works is that for transactions with a combined value over the default floor limit of NZ$2.5K you have to use an additional PIN sent via SMS to a pre-configured number to authenticate the session. The PIN authenticates that particular session (not just one transaction), with a fee of NZ$0.25. It's not perfect, obviously, but that was seen as the best tradeoff between cost, user convenience, and security. grumbleA few years ago I wanted to do this out-of-band authentication as a research project, and at the time couldn't find anyone interested in it; now they've paid an arm and a leg for it themselves, sigh/grumble. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
Perry E. Metzger [EMAIL PROTECTED] writes: Why is it, then, that banks are not taking digital photographs of customers when they open their accounts so that the manager's computer can pop up a picture for him, which the bank has had in possession the entire time and which I could not have forged? I don't know about photos specifically, but I know that signature imprints are often still moved around by laborious manual means because the background infrastructure to handle images doesn't exist. Most banks are still using 3270-style interfaces, even if they have a screen-scraped GUI front-end. There simply isn't any provision for handling anything other than basic text records - the data-centre back-ends are text-record based (and in some cases the text is EBCDIC), the communications channels send and receive text records (often at a few kbps over leased lines, X.25, or PSTN dialup), and the branch software processes text records. So using images (of any kind) isn't just a case of making an executive decision to do so, it would involve a massive, end-to-end infrastructure upgrade to implement. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: mother's maiden names...
Ian Brown [EMAIL PROTECTED] writes: Steven M. Bellovin wrote: Cambridge Trust puts your picture on the back of your VISA card, for instance. They have for more than a decade, maybe even two. One New York bank -- long since absorbed into some megabank -- did the same thing about 30 years ago. They gave up -- it was expensive then, and may not have solved any real problems. (Possibly, it simply didn't fit their real purpose of attracting more customers.) They don't for example seem to reduce fraud -- shop staff don't compare the photo to the customer carefully enough: R. Kemp, N. Towell, G. Pike, When seeing should not be believing: Photographs, credit cards and fraud, Applied Cognitive Psychology Vol 11(3) (1997) pp 211-222. For those who haven't seen this study, it's an important read (it's also been re-published in a somewhat more accessible journal, perhaps it was CACM?). What they did was send students into a supermarket with card photos of either them, someone who looked vaguely like them, or someone who looked nothing like them. Both the FRR and FAR were found to be such that the photo IDs were more or less worthless for fraud prevention. Some banks over here started to introduce photos on cards, but dropped the scheme based on this study and other research which showed that it wasn't worth it: The photos were too small to be useful, only customs immigration staff and to a lesser extent police have any formal training in matching faces to images, and your typical minimum-wage checkout operator couldn't care less if the image matched or not, their incentive was to move shoppers through quickly, not to check IDs. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
John Kelsey [EMAIL PROTECTED] writes: One nontrivial reason is that many organizations have spent a lot of time and money building up elaborate rules for using PKI, after long negotiations between legal and technical people, many hours of writing and revising, gazillions of dollars in consultants' time, etc. So, anytime you start doing anything involving public key cryptography, all this machinery gets invoked, for bureaucratic reasons. That is, you've now trespassed on PKI turf, and you'll have to comply with this enormous set of rules. I've seen this happen on many occasions, one example being the posting I made to this list a few months ago where an organisation had spent so much money setting up a PKI that they then had to use it (even though it was totally unnecesary for what they were doing) simply because it was there. I know of a couple cases where this led to really irritating results. In one, a friend of mine was using a digital signature to verify some fairly trivial thing, but was told it was against policy to use a digital signature without the whole PKI. Been there, seen that. You're well into layers 8 and 9 whenever anything related to PKI is involved. I think the fact that PKI is so strong at enabling layers 8+9 is its great appeal to the inhabitants of said layers. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ID theft -- so what?
James A. Donald [EMAIL PROTECTED] writes: The PKI that was designed to serve no very useful function other than make everyone in the world pay $100 a year to Verisign is dead. Yet the technology is potent, and the problems of identity and authenticity are severe. We shall, bye and bye, see reliance on public keys. Other things just don't work. What makes you so sure of that? When I looked at this (Plug-and-play PKI: A PKI your Mother can Use, available from my home page), I found that by the time you'd hidden enough of the PKI complexity to make it user-friendly, you had something that was indistinguishable from a username-and-password interface. Conversely, as soon as you start surfacing any of the PKI arcana, it becomes unusable by the majority of users. Currently the best way that I know of securing an SSL link is through the use of TLS-PSK, which provides mutual authentication of client and server as part of the TLS handshake without requiring any public-key technology at all. This also happens to be the most usable security technology around - even your mother can use it, and since the TLS handshake will fail in a very obvious manner if she connects to a spoofed site, there's no need to rely on users mastering PKI/PKC arcana for the security to work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: solving the wrong problem
Adam Shostack [EMAIL PROTECTED] writes: Let me propose another answer to Perry's question: Wearing a millstone around your neck to ward off vampires. This expresses both ends of a lose/lose proposition: -- a burdensome solution -- to a fantastically unimportant problem. That sounds a bit like unicorn insurance (We've taken out insurance against unicorns, and we know that it's effective because we haven't been attacked by any unicorns yet), which is used for silly threat models. However, this is slightly different from what Perry was suggesting. There seem to be at least four subclasses of problem here: 1. ??? : A solution based on a misunderstanding of what the real problem is. 2. Unicorn insurance: A solution to a nonexistent problem. 3. ???: A solution to a problem created artificially in order to justify its solution (or at least to justify publication of an academic paper containing a solution). 4. PKI: A solution in search of a problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: solving the wrong problem
Peter Fairbrother [EMAIL PROTECTED] writes: Peter Gutmann wrote: Peter Fairbrother [EMAIL PROTECTED] writes: Didn't the people who did US/USSR nuclear arms verification do something very similar, except the characterised surface was sparkles in plastic painted on the missile rather than paper? Yes. The intent was that forging the fingerprint on a warhead should cost as much or more than the warhead itself. Talking of solving the wrong problem, that's a pretty bad metric - forging should cost the damage an extra warhead would do, rather than the cost of an extra warhead. That's got to be in the trillions, rather than a few hundred thousand for another warhead. The cost was US$12M per warhead. I think that's sufficient. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The summer of PKI love
Stephan Neuhaus [EMAIL PROTECTED] writes: So, the optimism of the article's author aside, where *do* we stand on PKI deployment? The same place we were standing on OSI deployment 15 years ago. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
How many wrongs do you need to make a right?
In the 1950s we had cheque blacklists, which were used in an attempt to manage bad cheques. They didn't work well, and were abandoned as soon as better mechanisms became available. In the 1960s and 70s we had credit card blacklists, which were used in an attempt to manage bad credit cards. They didn't work well, and were abandoned as soon as better mechanisms became available. In the 1980s, the fine folks who gave us OSI also brought us CRLs in an attempt to manage bad certs. They didn't work well, but twenty years later the X.509 folks are still hanging in there in the hope that one day they'll spontaneously start working. http://www.networkworld.com/news/2005/081505-pki.html?nl [...] In the eight years since the U.S. Department of Defense started using the PKI certificate management system it bought from Netscape Communications, it has issued more than 16 million digital certificates. Most of them are stored on the department's common access smartcard, which is the main ID card used by the Army, Navy, Air Force and Marines. Along the way, the military also has revoked 10 million certificates as personnel and network needs change. That huge certificate revocation list (CRL) - which has bloated to over 50M bytes in file size - is the crux of the problem facing the Defense Department, because the entire CRL is supposed to be downloaded daily to every PKI user's desktop at the department from servers acting as distribution points. [...] Gosh, I wonder why no-one saw that coming. (I guess they have to revoke all those certs that were issued in exchange for a few dollars and some weed :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
When people ask for security holes as features
Raymond Chen's blog has an interesting look at companies trying to bypass Windows XP's checks that a driver has been WHQL-certified: My favorite stunt was related to my by a colleague who was installing a video card driver whose setup program displayed a dialog that read, roughly, After clicking OK, do not touch your keyboard or mouse while we prepare your system. After you click OK, the setup program proceeds to move the mouse programmatically all over the screen, opening the Display control panel, clicking on the Advanced button, clicking through various other configuration dialogs, a flurry of activity for what seems like a half a minute. When faced with a setup program that does this, your natural reaction is to scream, Aaaigh! There are many more examples (in followup comments and links) of vendors cheating in the certification and install process: my new Dell laptop came with an usigned bluetooth driver whose setup automatically clicks on the Continue button of the dialogs while installing the driver the driver for a USB memory key [...] would install and auto-push the button on that warning dialog. XP SP2 added a new check for kernel memory pool corruption and guess what? This driver would blue-screen every time the memory key was plugged in. I work on a wifi product that sometimes is bundled with wifi cards. When packaged like that our installer also installs the wifi card dirver. Guess what. The suits are all upset about the unsigned driver warning, and they are sure that a programmer more clever than me could make them go away. Of course actually getting the drivers certified is too expensive. Excuse me while I get back to work on my TPS report. I still remember one of Linksys's Wireless B PCMCIA cards. I went to install the driver, the instructions actually said something to the tune of Ignore this warning box, it doesn't mean anything important. Continue clicking OK on every screen until the driver finishes installing. Hell I could have put a box in that said Click here to format your hard drive and I'm sure some end users would have clicked OK. Cisco is a huge company, surely the WHQL payment isn't much to them. At a company I used to work for they had found away around that dialog box. They would silently launch the System Properties / Driver Signing Options dialog, send windows messages to select Ignore and then click ok, effectively turning off the dialog box (BTW, the code to re-enable the setting was commented out, so the installer made your machine less secure forever -- great stuff coming from a security company). More details at http://blogs.msdn.com/oldnewthing/archive/2005/08/16/452141.aspx. The best suggestion is that the warning be changed to: Warning! Your hardware manufacturer hasn't bothered to test this driver! Do you feel lucky? [Yes] [No] Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
John Kelsey [EMAIL PROTECTED] writes: Recently, Earthlink's webmail server certificate started showing up as expired. (It obviously expired a long time ago; I suspect someone must have screwed up in changing keys over or something, because the problem wasn't happening up until recently.) This is now the third time in the last few months in which invalid/expired SSL server certs have totally failed to have any effect, at least until a security person noticed that there was a problem. Maybe one of the HCI people reading the list could be persuaded to investigate whether SSL server certs have any real security value and/or what changes to the UI need to be made to make them useful. Alternatively, how long can you get away with a $19.95 cert from Honest Joe's Used Cars and Certificates that expired several years ago? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Dave Howe [EMAIL PROTECTED] writes: Nicolas Williams wrote: Yes, a challenge-response password authentication protocol, normally subject to off-line dictionary attacks by passive and active attackers can be strengthened by throwing in channel binding to, say, a TLS channel, such that: a) passive attacks are not possible, b) MITMs below TLS get nothing that can be attacked off-line, and c) server impersonators can be detected heuristically when the attacker can't retrieve the password in real-time (such an attack is indistinguishable from password incorrect situations, but...). Indeed. The main problem with TLS is lack of PKI support; in principle, this isn't true - TLS uses X509 certs, just like any other SSL based protocol - but in practice, everyone uses self signed certificates and nobody checks them or even caches them to see if they change. TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, ... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
James A. Donald [EMAIL PROTECTED] writes: From: [EMAIL PROTECTED] (Peter Gutmann) TLS-PSK fixes this problem by providing mutual authentication of client and server as part of the key exchange. Both sides demonstrate proof-of- possession of the password (without actually communicating the password), if either side fails to do this then the TLS handshake fails. Its only downside is that it isn't widely supported yet, it's only just been added to OpenSSL, and who knows when it'll appear in Windows/MSIE, Mozilla, Konqueror, Safari, This will take out 90% of phishing spam, when widely adopted. And that's it's killer feature: Although you can still be duped into handing out your password to a fake site, you simply cannot connect securely without prior mutual authentication of client and server if TLS-PSK is used. What'd be necessary in conjunction with this is two small changes to the browser UI: - Another type of secure-connect indicator (maybe light blue or light green in the URL bar instead of the current yellow) to show that it's a mutually authenticated connection, along with a Why is this green? tooltip for it. - A non-spoofable means of password entry that only applies for TLS-PSK passwords. In other words, something where a fake site can't trick the user into revealing a TLS-PSK key. Anyone know how to communicate this to the Mozilla guys? The only mechanism I'm aware of is bugzilla, which doesn't seem very useful for this kind of request. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Alaric Dailey [EMAIL PROTECTED] writes: While I admit that PKI is flawed, I don't see anyway that PSK could used effectively. How are PSKs going to be shared in a secure way? are we talking about generating a new key for every connection? if so how do you validate the key? if not, how do you validate that the key hasn't been compromised by someone who put up a phishing site? Gosh, I don't know. How about the way we've already been doing it for the past decade or so on every single passworded web site in existence, and for another decade before that with ATM PINs. In my opinion, PSK has the same problems as all symmetric encryption, its great if you can share the secret securely, but distribution to the masses makes it infeasible. Exactly, PSK's are infeasible, and all those thousands of web sites that have successfully employed them for a decade or more are all just figments of our imagination. By extension, ATMs are also infeasible. Sarcasm aside for a minute, several people have responded to the PSK thread with the standard passwords don't work, whine moan complain response that security people are expected to give whenever passwords are mentioned. It's all the user's fault, they should learn how to use PKI. Well we've had ten years of that and it seems to be making bugger-all difference in protecting users, based on the universal success of phishing attacks. What's happened is that security people have said Here's our perfect solution, PKI, and we're not budging an inch on that, the masses have said We can't manage anything beyond usernames and passwords and we're not budging an inch on that, and the phishers have leaped in and filled the gap between the two while both sides are sitting there holding their breath to see whose face goes blue first. The failing is in the security community. Security practitioners (by which I mean people who build secure systems, not ones who merely go out and pontificate about them) have 30 years of research in authentication mechanisms to fall back on, and yet the state-of-the-art in use today is to hand out the plaintext password to anyone who asks for it: Hi, I'm your bank, or Paypal, or something, please give me your password. Instead of using a decent (and trivial to implement) challenge-response mutual-authentication mechanism, we're using the worst possible one there is, the one that every security textbook warns against, while sitting back and waiting for PKI to start working. My mother (to use my favourite canonical non-technical user) has figured out how to use a username and password to authenticate herself. She hasn't, and never will, figure out PKI, and nor will most of the rest of humanity. The users have amply demonstrated to us what they're capable of handling. It is the failing of the security community to not use that effectively - password- based authentication is bad because the security community (or at least security application developers) have made it bad, not because it's inherently poor. Here's my proposal for an unmistakable TLS-PSK based authentication mechanism for a browser: When connecting to a TLS-PSK protected site, the URL bar (or something else very obvious, say the top border of the page) is set to a colour like blue, matching what Mozilla currently does with its yellow for SSL sites. The blue bar then zooms out into a blue-marked dialog box asking for the username and password (I'm assuming here that you can't spoof this sort of thing in Javascript). Once the mutual auth of client and server has occurred, the blue-marked dialog box zooms back to the blue-marked web page, providing a clear connection between all stages of authentication and secure display. All that users have to learn is to never enter their password on a non-blue-marked site. It doesn't solve *all* phishing problems, but it's a darn sight better than the mess we're in now. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
Stephan Neuhaus [EMAIL PROTECTED] writes: I think you're talking about me here, Oh no, I wasn't focusing on any one person, it was a characterisation of the general response from security people when this sort of thing is mentioned. Long before the discussion on this list, there were already missionaries coming to the ietf-tls list to enlighten the heathens who dared to mention PSK and remind them of their duty to support PKI in all its infinite perfection, and not to take any false gods before it. I also didn't say that passwords didn't *work*, I said that they had *storage and management issues* that certificates did not have and that their deployment would be problematic because of that, and I stand by that. Sure, but those issues have already been addressed by pretty much every site that needs to use passwords or user authentication for any reason. That's the point I was trying to make, that the standard response to use of passwords (or PSKs) is they don't work, they don't scale, you can't handle revocation, distribution is a problem, etc etc etc. However, despite all of these issues, all the sites that need to authenticate users are using passwords, and they seem to be doing OK with that. Rather, it is my impression that a switch to TLS-PSK would not just be a client-side thing, but that server code would have to be changed also, and that it is this issue which will prevent widespread deployment of TLS-PSK. Sure, that will be an issue. I think it depends on how much pain banks and merchants are willing to endure due to phishing attacks. The problem with current authentication methods is that the authenticated is in completely the wrong direction to prevent phishing, and the phishing industry has developed in response to the fact that TLS server cert-based auth is useless against it. TLS-PSK addresses this problem. Not only does it authenticate the server, but it authenticates it in a manner that proves the server has direct knowledge of the client, not merely that they've shelled out all of $7 for a server cert. So in other words I could be directed by phishers to dozens of sites all claiming to be XYZ Bank, some even with TLS certs proving this, but only one will be able to authenticate itself to me as my bank. If you look at this in terms of attack surface reduction, it's gone from: The software I use will hand my password over (in plaintext) to anything claiming to be my bank. to: An attacker will have to get to me during the enrolment phase, or compromise the bank's server to steal the passwords. This is an *enormous* reduction in attack surface. Compromising the enrolment phase would typically require a huge spoofing effort or powerful MITM, much more than the spam out a plausible password-renewal request type of attack that's been so successful against the current way of doing things. If I were a phisher, I'd set up a web site having normal text boxes for username and password. On it, I'd put a link why isn't the URL bar blue? and use some technical mumbo-jumbo about how for technical reasons, the feature needed to be disabled in the browser, Yeah, that's still a possibility, although I think you can probably train most users to not do this. I only know about NZ banking practices here, but every one of them provides a best-practices way to do things (don't do banking from an Internet cafe, check for the padlock, when logging on check that the last- logon time display was when you actually logged on, etc etc). Drilling it into people that if they don't see the blue flashy bits there's a problem shouldn't be that hard. Sure, there'll be some margin-of-error group who still won't get the message, but these same people would also hand out their credit card details over the phone to someone claiming to be from their bank. The thing is, TLS-PSK provides major attack surface reduction, and that's a big win in the fight against phishing. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
