Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On Fri, Oct 11, 2013 at 10:32 AM, Zooko O'Whielacronx wrote: > I like the ideas, John. > > The idea, and the protocol you sketched out, are a little reminiscent > of ZRTP ¹ and of tcpcrypt ². I think you can go one step further, > however, and make it *really* strong, which is to offer the "higher" > or "outer" layer a way to hook into the crypto from your inner layer. > > This could be by the inner layer exporting a crypto value which the > outer layer enforces an authorization or authenticity requirement on, > as is done in ZRTP if the "a=zrtp-hash" is delivered through an > integrity-protected outer layer, or in tcpcrypt if the "Session ID" is > verified by the outer layer. Hi Zooko, Are you and John talking about the same thing? John's talking about tunnelling a redundant inner "record layer" of encryption inside an outer record layer (using TLS terminology). I think you're talking about a couple different-but-related things: * "channel binding", where an unauthenticated-but-encrypted channel can be authenticated by performing an inside-the-channel authentication which commits to values uniquely identifying the outer channel (note that the "inner" vs "outer" distinction has flipped around here!) * "out-of-band verification", where a channel is authenticated by communicating values identifying the channel (fingerprint, SAS, sessionIDs) over some other, authenticated channel (e.g. ZRTP's use of the signalling channel to protect the media channel). So I think you're focusing on *modularity* between authentication methods and the record layer, whereas I think John's getting at *redundancy*. > I think the way that SSL combined transport layer security, > authorization, and identification was a terrible idea. I (and others) > have been saying all along that it was a bad idea, and I hope that the > related security disasters during the last two years have started > persuading more people to rethink it, too. This seems like a different thing again. I agree that TLS could have been more modular wrt "key agreement" and "public-key authentication". It would be nice if the keys necessary to compute a TLS handshake were part of TLS, instead of requiring X.509 certs. This would avoid "self-signed certs", and would allow the client to request various "proofs" for the server's public key, which could be X.509, other cert formats, or other info (CT, TACK, DNSSEC, revocation data, etc.). But this seems like a minor layering flaw, I'm not sure it should be blamed for any TLS security problems. The problems with chaining CBC IVs, plaintext compression, authenticate-then-encrypt, renegotiation, and a non-working upgrade path aren't solved by better modularity, nor are they solved by redundancy. They're solved by making better choices. I guess the designers of > SSL were simply following the lead of the original inventors of public > key cryptography, who delegated certain critical unsolved problems to > an underspecified "Trusted Third Party". What a colossal, historic > mistake. If you're talking about the "New Directions" paper, Diffie and Hellman talk about a "public file". Certificates were a later idea, due to Kohnfelder... I'd argue that's where things went wrong... > 1. Go, go, go! The path your thoughts are taking seems fruitful. Just > design a really good "inner layer" of crypto, without worrying (for > now) about the vexing and subtle problems of authorization, > authentication, naming, Man-In-The-Middle-Attack and so on. For now. That's easy though, right? Use a proper KDF from a shared secret, do authenticated encryption, don't f*ck up the IVs The worthwhile problems are the hard ones, no? :-) Trevor ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On Thu, Oct 10, 2013 at 3:32 PM, John Kelsey wrote: > The goal is to have an inner protocol which can run inside TLS or some > similar thing [...] > > Suppose we have this inner protocol running inside a TLS version that is > subject to one of the CBC padding reaction attacks. The inner protocol > completely blocks that. If you can design an "inner protocol" to resist such attacks - which you can, easily - why wouldn't you just design the "outer protocol" the same way? Trevor ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Key management, key storage. (was Re: prism proof email, namespaces, and anonymity)
On Sat, Sep 14, 2013 at 9:46 AM, Perry E. Metzger wrote: > > However, on the topic of key management itself, my own proposal was > described here: > > http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html > > In summary, I proposed a way you can map IDs to keys through pure > long term observation/widely witnessed events. The idea is not > original given that to some extent things like Certificate > Transparency already do this in other domains. Hi Perry, What you're proposing is "multipath probing" of email users' public keys. Certificate Transparency isn't the right comparison, but this has certainly been discussed in other domains: Public Spaces Key Infrastructure / SecSpider (Osterweil et al, 2006, 2007) [1] Perspectives (for HTTPS - Wendlant et al, 2008) [3] Convergence (for HTTPS - Marlinspike, 2011) [4] Vantages (for DNSSSEC - Osterweil et al, 2013) [5] Probing servers is easier than probing email users, and publishing a servername -> key directory is also easier as server names don't have the same privacy concerns as email names. Still, it's an interesting idea. Key changes are a challenge to this approach, which people tend to overlook. One approach is to have the probed party declare a commitment to maintaining its public key constant for some period of time, and have this commitment be detected by the probing parties. This provides some timing guarantees so that the rest of the system can probe and download new results at regular intervals, without having sudden key changes cause glitches. Things like HPKP [6] and TACK [7] explore this option. Trevor [1] http://irl.cs.ucla.edu/papers/pski.pdf [2] http://secspider.cs.ucla.edu/docs.html [3] http://perspectives-project.org/ [4] http://convergence.io/ [5] http://irl.cs.ucla.edu/~eoster/doc/pubdata-tpds13.pdf [6] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [7] http://tack.io ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: NPR : E-Mail Encryption Rare in Everyday Use
Ed Gerck wrote:
Ben Laurie wrote:
I totally don't buy this distinction - in order to write to you with
postal mail, I first have to ask you for your address.
We all agree that having to use name and address are NOT the problem,
for email or postal mail. Both can also deliver a letter just with
the address ("CURRENT RESIDENT" junk mail, for example).
The problem is that pesky public-key. A public-key such as
[2. application/pgp-keys]...
is N O T user-friendly.
True enough about public keys. Not so true about key fingerprints - a
20-char fingerprint is probably not much harder to manage than the usual
sorts of contact info (email, postal, & IM addresses, phone numbers, etc.).
Of course, a fingerprint won't let you encrypt an email without
supporting infrastructure for key lookups. However, it *will* let you
authenticate a session (e.g., IM, VoIP, SSH) if your parter presents his
public key in the handshake.
Perhaps this is further support for Iang's contention that we should
expect newer, interactive protocols (IM, Skype, etc.) to take the lead
in communication security. Email-style "message encryption" may simply
be a much harder problem.
Trevor
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: FW: How broad is the SPEKE patent.
Charlie Kaufman wrote: [...] I am not aware of anyone who is publicly shipping - either > in a commercial product or as open source - an implementation > of a strong password protocol without having paid protection > money to either Lucent or Phoenix (or both). A not totally up-to-date list of SRP implementations & applications is here: http://srp.stanford.edu/links.html I suspect most implementors aren't paying anyone. Trevor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: continuity of identity
Hi John, John Denker wrote: [...] For starters, let me suggest that rather than having a self-signed certificate of the type created more-or-less automatically when you set up your Apache server or set up your SSH daemon, it makes more sense to set up your own CA and issue your own certs from there. In some sense this is just a different type of self-signing, but it adds a possibly useful layer of indirection. Conceptually, this self-managed layer of indirection is similar to things like PGP master keys / subkeys, X.509 Proxy Certificates [1], and proposals such as httpsy YURLs [2] and cryptoIDs [3]. [...] This scheme is in some sense doable already, since modern browsers have a way of importing new CA keys under user control. If you can persuade a user to go through those steps you're all set. Browsers would need to be modified for this. I don't think you want to encourage users to import CA certs into current browsers, since those certs will usually become trusted for all domains. So you'd need something like a known_hosts file to bind the imported certificates to domain names. Adding this with a good UI to mainstream browsers seems like the biggest challenge (sending a CA cert during the SSL handshake is easy). [...] Comments, anyone? One pragmatic issue is that it would be nice if you could form "continuity of identity" bindings to existing 3rd-party-managed identities as well as self-managed identities. If the client records an identity as something like (CA cert, domain name), then this identity would remain stable across end-entity key and cert changes regardless of whether the CA cert is self-managed or belongs to Verisign. Tyler Close's Petname Toolbar [4] is an excellent implementation of this concept. Moving from pragmatics to, I guess, "theory": Once you have a layer of indirection between an entity's public identity and the subkey(s) it uses in protocols, there's a lot of features you could add. A simple layer of indirection would be a master key that can sign (subkey, expiration time) certificates. But you could achieve more security and flexibility in managing keys with things like: - Allow the master key to delegate revalidation/revocation of subkeys to other authorities, so compromised subkeys could be quickly disabled without involving the master key. - Allow the public identity to be a combination of a public master key and a user identifier (as above) so that a single master key could support different identities (for example, multiple users might choose a trustworthy 3rd-party to host their identity). - Allow subkeys to sign other subkeys, to allow more flexible architectures. - Allow subkeys to be granted limited privileges for use in different protocols. - Allow SPKI-like threshold subjects, for greater resilience. It's interesting that all these techniques developed for other PKIs could be applied for the purpose of making a single "crypto identity" more secure and flexible. It's also interesting that such an identity is not just useful for a "leap-of-faith" / key continuity model, but could be used with any other PKI model (web of trust, authorization certs, name certs, etc.) - you could include the identity information or its hash in a certificate, or manually exchange it. One could argue that this gives a nice architecture: The PKI or other infrastructure would be responsible for distributing and attesting to bindings between crypto identities and real-world names, authorizations, etc. Then, users would be responsible for the key management tasks relating to security and stability of their identities. Trevor [1] RFC 3820 [2] http://www.waterken.com/dev/YURL/ [3] http://trevp.net/cryptoID/ [4] http://www.waterken.com/user/PetnameTool/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: cryptoIDs
At 09:51 AM 10/16/2003 -0500, Von Welch wrote: Trevor Perrin writes (02:53 October 16, 2003): ... > Anyways, for private-key management people should use certs - store your > root key (i.e. the key that matches the fingerprint) in a safe place (for > most people, this would be with their employer or a commercial service; but > the security-conscious can do whatever they want). Then have your root-key > issue you short-lived certs for use on your cell-phone, email client, web > browser, etc.. In the Grid community these short-lived certs you mention exist and are in day-to-day use for the sort of delegation you describe. We call them proxy certificates and have standardized them through the IETF PKIX working group. See the following url for the latest draft (which has passed WG last call). http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-08.txt A service implementation also exists to hand out Proxy Certificates from the long-term credentials as you suggest. It's called MyProxy, and you can find more information at http://myproxy.ncsa.uiuc.edu Hi Von, yes, I like those, and I discuss them - http://trevp.net/cryptoID/cryptoID.html#3.2.1 PGP subkeys and SPKI certs can also be used for "key management" in this fashion. I don't claim this is novel. I *do* think that if you design a new cert format from scratch, without sticking within X.509's straitjacket, you can get something better. CryptoID certs allow threshold subjects (like SPKI), timed and one-time revalidation (ditto), they have an authorization language suited to the task at hand (saying which protocols a key can be used with), and they're a clean, simple XML format. Of course, they're also not compatible with X.509 software :-(. If you don't like that trade-off, then I agree that proxy certs are the better choice. Trevor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
cryptoIDs
Hi cryptography, I haven't posted here much, but I've got an idea I'd like to try to win some converts / draw some criticism for. There's a paper, code, and other stuff here: http://trevp.net#cryptoID. Here's the gist: The goal is a system for encrypted & authenticated person-to-person communications (email, voice, IM, etc.). It should be simple for people to use, and easy for developers to plug into everything. Such a system would address two problems: - public-key distribution (how does Bob get Alice's public key) - private-key management (how does Alice deal with her private key - keep it secure yet accessible, recover from compromise, etc.) The PKI approach is to use certs for the 1st, and, I guess, smartcards for the 2nd. Instead, I think people should use fingerprints for the 1st and certs for the 2nd. Fingerprints would work well for key distribution since they're small pieces of data, like phone numbers or email addresses. Users already know how to handle these by exchanging them on business cards, writing or speaking them, looking them up in directories, etc.. Similarly, software already has address books to store these things, so it would be easy to add another field for the fingerprint. Software would inform you when something authenticates to a known fingerprint (a blinking indicator next to a "pet name"[1], for example) . One problem: fingerprints are large, thus not very user-friendly. But that can be fixed, somewhat: if you use the "hash extension" technique from [2] and base32 encoding, you can get 20 character fingerprints with a reasonable security level (for example: to generate a fingerprint with a security level of 120 bits requires a computation of ~15 seconds; if talk of "generating" a fingerprint sounds strange see [2] or [3]). These fingerprints (call them "cryptoIDs") would look like: erbtr.isnx6.4fcuj.5yymj frqtp.3jbrt.ukued.ngwwe Not as short as one would like, but much better than the usual hex-coded SHA-1. There's other problems with doing things via fingerprint, but you'll have to see the paper - I'm trying (though failing) to be brief :-). Anyways, for private-key management people should use certs - store your root key (i.e. the key that matches the fingerprint) in a safe place (for most people, this would be with their employer or a commercial service; but the security-conscious can do whatever they want). Then have your root-key issue you short-lived certs for use on your cell-phone, email client, web browser, etc.. You could use PGP subkeys, X.509 proxy certs, or SPKI certs for this. But all of them are either excessively complicated for this, lacking in features, or both. So I designed a certificate format just for private-key management. It's SPKI-like but a little simpler and I think does a couple things better. I'm eager for feedback, off-list or on. Nothing here is that novel, but to me this seems a powerful, yet fairly simple, blend of techniques. Trevor [1] http://www.erights.org/elib/capability/pnml.html [2] http://research.microsoft.com/users/tuomaura/CGA/ [3] http://trevp.net/cryptoID/cryptoID.html#3.3.1 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: DH with shared secret
At 05:13 AM 10/3/2003 -0400, Jack Lloyd wrote: This was just something that popped into my head a while back, and I was wondering if this works like I think it does. And who came up with it before me, because it's was too obvious. It's just that I've never heard of something alone these lines before. Basically, you share some secret with someone else (call it S). Then you do a standard issue DH exchange, but instead of the shared key being g^(xy), it's g^(xyS) But a bad guy MITM can try and verify guesses for S, so this is vulnerable to an offline dictionary attack. [A bad guy server will choose y, and will receive g^x. Now he can try guesses for S and see if the resulting g^(xyS) properly decrypts/verifies the client's confirmation message.] The better approach is "DH-EKE": use S as a symmetric key, and exchange S(g^x), S(g^y). No offline attacks, a bad guy only gets a single guess during the protocol run. An ever better approach is SRP, where the server doesn't need to know the password but only a function of it. There's even an I-D for doing it with TLS - http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-05.txt This would be a great way of doing password auth in protocols like POP/IMAP, HTTP, and elsewhere, since it mutually authenticates both parties based only on the password. Only one implementation right now (gnuTLS in the CVS version), but hopefully that will change soon. Trevor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: 3 more good ideas: cryptoURLs, SFS, eternal resource locator/WAX
At 11:53 AM 7/16/2003 -0400, Ian Grigg wrote: Content-Transfer-Encoding: 7bit Below follows a paragraph on each idea to distribute key hashes within existing web practice, with examples. Trevor Perrin wrote: > A similar idea was discussed on the W3C's URI list[1]. Simon Josefsson had > the clever idea of a URI scheme that binds an underlying URI to some > "crypto data" such as document hashes, key fingerprints, and key URLs: > > crypto:[] > > crypto:https://www.acme.com[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551] This is really good stuff. Thanks! The first observation is that it is more general than Tyler's approach, Yeah, but also more complicated. in that it explicitly incorporates URIs and also the existing CA-cert regime. In this way it will actually add to the current situation, rather than require the dismantling or ignoring of the CA-cert. As Tyler pointed out, YURLs contain the hash of the CA's key, so they're similar in this respect. (Much as I think the CA-cert is 'mostly harmless' as far as security goes, there is little point in trying to remove it. It really needs to be incorporated into any and all plans to add security to the browsing experience.) One observation immediatly springs to mind is that the above URLs simply don't work with existing conventions. That is, when I click on them in my (admittedly not security conscious) email agent, the result fails. That would be a great property, but I couldn't find a way to achieve it (see below). To rectify this, one could reverse the location of the hash: crypto:[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551]:https://www.acme.com and similar with the mailto. Do those work with your email client? However you order it I'd expect clients to choke, so it seems more a question of readability. Alternatively, use a wrapper convention such as: crypto:<https://www.acme.com>[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551] Maybe. Angle brackets are disallowed in RFC 2396; so are square brackets but RFC 2396bis currently admits them.. but yeah, these are the kind of miniscule but crucial details I'm not sure we've gotten right yet. [...] >From what I can see across all these ideas, I'd suggest that if a URI form can be constructed that is compatible with existing URIs then this will have deployment advantages over the above. That's a tough problem. Tyler repurposes userinfo: https://*@... but that won't work well with ftp or telnet URLs that actually use userinfo. And you're not supposed to have userinfo in http or https URLs, clients might choke on that. You could try stuffing crypto data into the path or the query component: http:///path1/path2// http://? Then a naive client would pass it to the server and the server could ignore it, and an upgraded client would strip it off and not send it. You'd have to upgrade servers to handle naive clients throwing crypto junk at them. Still pretty ugly.. With a single "crypto" scheme, at least it would be easy to upgrade clients to recognize "crypto", discard the crypto data, and then process the URL normally. Even in the best case, it would be years before you could expect most people to have browsers that did that. But once that threshold was crossed, you could use "secure URLs" without inconveniencing people. Trevor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Announcing httpsy://, a YURL scheme
At 11:26 AM 7/16/2003 -0400, Perry E. Metzger wrote: Ian Grigg <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > > A YURL aware search engine may find multiple independent references to a > > YURL, thus giving you parallel reporting channels, and increasing trust. > > Of course, this method differs from the YURL method for trust. The > > parallel channel method assigns a trust value to a site by querying the > > YURL aware search engine. > > That's an extraordinarily good idea! It reminds It seems to me to be more "a bad idea, fully realized". I'll repeat: 1) The "YURL" makes key management and replacement effectively impossible. One approach: instead of putting the end-entity key's fingerprint in the URL, place the CA key's fingerprint. CryptoURLs have an x509_root_sha1 datatype for this purpose. Then ensure that the HTTPS server returns the CA's self-signed cert. The client hashes this to see if the fingerprint matches the cryptoURL, then validates the chain in the usual way. Now a compromise of the EE's key can be recovered from like normal. For example, the CA can issue short-lived certs, or the EE cert can have a CDP extension where CRLs are found. Compromise of the CA key is still a catastrophe, but it always was. The neat thing here is the EE can choose his own "CA", based on the sole critieria that he believes it will remain secure, and will be rigorous in authenticating him. For example, I could choose my mom as my "CA", since she's highly security-conscious and unlikely to certify anyone else as me. Or I could be my own CA, but split the CA key up into threshold shares and stow them in various safes and hiding places, and proactivize them periodically. The negative, security-wise, is that now you're relying on two trusted introducers: wherever the cryptoURL came from, and the CA. But for that price, you've purchased some resilience to EE key compromise. Trevor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: httpsy, SSH and eternal resource locator/WAX (Re: Announcing httpsy://, a YURL scheme)
At 12:33 AM 7/16/2003 +0100, Adam Back wrote: I'm not that familiar with SFS, but httpsy sounds quite related to Anderson, Matyas and Peticolas' "eternal resource locator" [1], and the WAX system they describe in that paper. This scheme allows a referer to embody in a URL they refer to authentciation information about the contents of the text in the body of the page referred to (either by SHA1 document hash, or by reference to a signing key the publisher of the referred page may use to sign and update that page's contents). A similar idea was discussed on the W3C's URI list[1]. Simon Josefsson had the clever idea of a URI scheme that binds an underlying URI to some "crypto data" such as document hashes, key fingerprints, and key URLs: crypto:[] crypto:https://www.acme.com[x509_sha1=4ca4.b169.587f.7258.9f6b.f9ee.bd6e.d7cd.cd6a.d551] crypto:ftp://ftp.acme.com/file.dat[content_md5=6bb2.83af.35c9.2ec4.9deb.4654.5f31.f175] crypto:mailto:[EMAIL PROTECTED],pgp_url=http://www.acme.com/alice.asc] The first example is like an httpsy URL. The second gives a file and its md5 hash. The third gives Alice's email address and PGP key. These "cryptoURLs" could be used wherever URLs are, not just on the web. For example, a signed XML document that uses cryptoURLs to reference external content would extend the signature over that content. A protocol like LDAP that returns a URL referral to another server could return a cryptoURL so the client can securely access that server. We sorta started an I-D, but it's not very far along[2]... Trevor [1] http://lists.w3.org/Archives/Public/uri/2003Apr/0095.html [2] (this is not a real Internet-Draft, despite boilerplate): http://trevp.net/cryptoURL/draft-ietf-cryptoURL-01.html http://trevp.net/cryptoURL/draft-ietf-cryptoURL-01.txt - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
