Re: [Cryptography] PGP Key Signing parties
Reply to various, Yes, the value in a given key signing is weak, in fact every link in the web of trust is terribly weak. However, if you notarize and publish the links in CT fashion then I can show that they actually become very strong. I might not have good evidence of John Gilmore's key at RSA 2001, but I could get very strong evidence that someone signed a JG key at RSA 2001. Which is actually quite a high bar since the attacker would haver to buy a badge which is $2,000. Even if they were going to go anyway and it is a sunk cost, they are rate limited. The other attacks John raised are valid but I think they can be dealt with by adequate design of the ceremony to ensure that it is transparent. Now stack that information alongside other endorsements and we can arrive at a pretty strong authentication mechanism. The various mechanisms used to evaluate the trust can also be expressed in the endorsement links. What I am trying to solve here is the distance problem in Web o' trust. At the moment it is pretty well impossible for me to have confidence in keys for people who are ten degrees out. Yet I am pretty confident of the accuracy of histories of what happened 300 years ago (within certain limits). It is pretty easy to fake a web of trust, I can do it on one computer, no trouble. But if the web is grounded at just a few points to actual events then it becomes very difficult to spoof. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Key stretching
All, Quick question, anyone got a good scheme for key stretching? I have this scheme for managing private keys that involves storing them as encrypted PKCS#8 blobs in the cloud. AES128 seems a little on the weak side for this but there are (rare) circumstances where a user is going to need to type in the key for recovery purposes so I don't want more than 128 bits of key to type in (I am betting that 128 bits is going to be sufficient to the end of Moore's law). So the answer is to use AES 256 and stretch the key, but how? I could just repeat the key: K = k + k Related key attacks make me a little nervous though. Maybe: K = (k + 01234567) XOR SHA512 (k) -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Other Backdoors?
I sarcastically proposed the use of GOST as an alternative to NIST crypto.
Someone shot back a note saying the elliptic curves might be 'bent'.
Might be interesting for EC to take another look at GOST since it might be
the case that the GRU and the NSA both found a similar backdoor but one was
better at hiding it than the other.
On the NIST side, can anyone explain the reason for this mechanism for
truncating SHA512?
Denote H(0)′
to be the initial hash value of SHA-512 as specified in Section 5.3.5
above.
Denote H(0)′′ to be the initial hash value computed below.
H(0) is the IV for SHA-512/t.
For i = 0 to 7
{
(0)′′ (0)′ Hi = Hi ⊕ a5a5a5a5a5a5a5a5(in hex).
}
H(0) = SHA-512 (“SHA-512/t”) using H(0)′′
as the IV, where t is the specific truncation value.
(end.)
[Can't link to FIPS180-4 right now as its down]
I really don't like the futzing with the IV like that, not least because a
lot of implementations don't give access to the IV. Certainly the object
oriented ones I tend to use don't.
But does it make the scheme weaker?
Is there anything wrong with just truncating the output?
The only advantage I can see to the idea is to stop the truncated digest
being used as leverage to reveal the full digest in a scheme where one was
public and the other was not.
--
Website: http://hallambaker.com/
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Iran and murder
On Wed, Oct 9, 2013 at 12:44 AM, Tim Newsham tim.news...@gmail.com wrote: We are more vulnerable to widespread acceptance of these bad principles than almost anyone, ultimately, But doing all these things has won larger budgets and temporary successes for specific people and agencies today, whereas the costs of all this will land on us all in the future. The same could be (and has been) said about offensive cyber warfare. I said the same thing in the launch issue of cyber-defense. Unfortunately the editor took it into his head to conflate inventing the HTTP referer field etc. with rather more and so I can't point people at the article as they refuse to correct it. I see cyber-sabotage as being similar to use of chemical or biological weapons: It is going to be banned because the military consequences fall far short of being decisive, are unpredictable and the barriers to entry are low. STUXNET has been relaunched with different payloads countless times. So we are throwing stones the other side can throw back with greater force. We have a big problem in crypto because we cannot now be sure that the help received from the US government in the past has been well intentioned or not. And so a great deal of time is being wasted right now (though we will waste orders of magnitude more of their time). At the moment we have a bunch of generals and contractors telling us that we must spend billions on the ability to attack China's power system in case they attack ours. If we accept that project then we can't share technology that might help them defend their power system which cripples our ability to defend our own. So a purely hypothetical attack promoted for the personal enrichment of a few makes us less secure, not safer. And the power systems are open to attack by sufficiently motivated individuals. The sophistication of STUXNET lay in its ability to discriminate the intended target from others. The opponents we face simply don't care about collateral damage. So I am not impressed by people boasting about the ability of some country (not an ally of my country BTW) to perform targeted murder overlooks the fact that they can and likely will retaliate with indiscriminate murder in return. I bet people are less fond of drones when they start to realize other countries have them as well. Lets just stick to defense and make the NATO civilian infrastructure secure against cyber attack regardless of what making that technology public might do for what some people insist we should consider enemies. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] The cost of National Security Letters
One of the biggest problems with the current situation is that US technology companies have no ability to convince others that their equipment has not been compromised by a government mandated backdoor. This is imposing a significant and real cost on providers of outsourced Web Services and is beginning to place costs on manufacturers. International customers are learning to shop elsewhere for their IT needs. While moving from the US to the UK might seem to leave the customer equally vulnerable to warrant-less NSA/GCHQ snooping, there is a very important difference. A US provider can be silenced using a National Security Letter which is an administrative order issued by a government agency without any court sanction. There is no equivalent capability in UK law. A UK court can make an intercept order or authorize a search etc. but that is by definition a Lawful Intercept and that capability exists regardless of jurisdiction. What is unique in the US at the moment is the National Security Letter. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] PGP Key Signing parties
Does PGP have any particular support for key signing parties built in or is this just something that has grown up as a practice of use? I am looking at different options for building a PKI for securing personal communications and it seems to me that the Key Party model could be improved on if there were some tweaks so that key party signing events were a distinct part of the model. I am specifically thinking of ways that key signing parties might be made scalable so that it was possible for hundreds of thousands of people to participate in an event and there were specific controls to ensure that the use of the key party key was strictly bounded in space and time. So for example, it costs $2K to go to RSA. So if there is a key signing event associated that requires someone to be physically present then that is a $2K cost factor that we can leverage right there. Now we can all imagine ways in which folk on this list could avoid or evade such controls but they all have costs. I think it rather unlikely that any of you would want to be attempting to impersonate me at multiple cons. If there is a CT infrastructure then we can ensure that the use of the key party key is strictly limited to that one event and that even if the key is not somehow destroyed after use that it is not going to be trusted. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Elliptic curve question
On Tue, Oct 8, 2013 at 4:14 PM, James A. Donald jam...@echeque.com wrote: On 2013-10-08 03:14, Phillip Hallam-Baker wrote: Are you planning to publish your signing key or your decryption key? Use of a key for one makes the other incompatible.� Incorrect. One's public key is always an elliptic point, one's private key is always a number. Thus there is no reason in principle why one cannot use the same key (a number) for signing the messages you send, and decrypting the messages you receive. The original author was proposing to use the same key for encryption and signature which is a rather bad idea. -- Website: http://hallambaker.com/ ___ 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 Sat, Oct 5, 2013 at 7:36 PM, James A. Donald jam...@echeque.com wrote: On 2013-10-04 23:57, Phillip Hallam-Baker wrote: Oh and it seems that someone has murdered the head of the IRG cyber effort. I condemn it without qualification. I endorse it without qualification. The IRG are bad guys and need killing - all of them, every single one. War is an honorable profession, and is in our nature. The lion does no wrong to kill the deer, and the warrior does no wrong to fight in a just war, for we are still killer apes. The problem with the NSA and NIST is not that they are doing warlike things, but that they are doing warlike things against their own people. If people who purport to be on our side go round murdering their people then they are going to go round murdering people on ours. We already have Putin's group of thugs murdering folk with Polonium laced teapots, just so that there can be no doubt as to the identity of the perpetrators. We are not at war with Iran. I am aware that there are people who would like to start a war with Iran, the same ones who wanted to start the war with Iraq which caused a half million deaths but no war crimes trials to date. Iran used to have a democracy, remember what happened to it? It was people like the brothers Dulles who preferred a convenient dictator to a democratic government that overthrew it with the help of a rent-a-mob supplied by one Ayatollah Khomenei. I believe that it was the Ultra-class signals intelligence that made the operation possible and the string of CIA inspired coups that installed dictators or pre-empted the emergence of democratic regimes in many other countries until the mid 1970s. Which not coincidentally is the time that mechanical cipher machines were being replaced by electronic. I have had a rather closer view of your establishment than most. You have retired four star generals suggesting that in the case of a cyber-attack against critical infrastructure, the government should declare martial law within hours. It is not hard to see where that would lead there are plenty of US military types who would dishonor their uniforms with a coup at home, I have met them. My view is that we would all be rather safer if the NSA went completely dark for a while, at least until there has been some accountability for the crimes of the '00s and a full account of which coups the CIA backed, who authorized them and why. I have lived with terrorism all my life. My family was targeted by terrorists that Rep King and Rudy Giuliani profess to wholeheartedly support to this day. I am not concerned about the terrorists because they obviously can't win. It is like the current idiocy in Congress, the Democrats are bound to win because at the end of the day the effects of the recession that the Republicans threaten to cause will be temporary while universal health care will be permanent. The threatened harm is not great enough to cause a change in policy. The only cases where terrorist tactics have worked is where a small minority have been trying to suppress the majority, as in Rhodesia or French occupied Spain during the Napoleonic wars. But when I see politicians passing laws to stop people voting, judges deciding that the votes in a Presidential election cannot be counted and all the other right wing antics taking place in the US at the moment, the risk of a right wing fascist coup has to be taken seriously. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
On Thu, Oct 3, 2013 at 12:21 PM, Jerry Leichter leich...@lrw.com wrote: On Oct 3, 2013, at 10:09 AM, Brian Gladman b...@gladman.plus.com wrote: Leaving aside the question of whether anyone weakened it, is it true that AES-256 provides comparable security to AES-128? I may be wrong about this, but if you are talking about the theoretical strength of AES-256, then I am not aware of any attacks against it that come even remotely close to reducing its effective key length to 128 bits. So my answer would be 'no'. There are *related key* attacks against full AES-192 and AES-256 with complexity 2^119. http://eprint.iacr.org/2009/374 reports on improved versions of these attacks against *reduced round variants of AES-256; for a 10-round variant of AES-256 (the same number of rounds as AES-128), the attacks have complexity 2^45 (under a strong related sub-key attack). None of these attacks gain any advantage when applied to AES-128. As *practical attacks today*, these are of no interest - related key attacks only apply in rather unrealistic scenarios, even a 2^119 strength is way beyond any realistic attack, and no one would use a reduced-round version of AES-256. As a *theoretical checkpoint on the strength of AES* ... the abstract says the results raise[s] serious concern about the remaining safety margin offered by the AES family of cryptosystems. The contact author on this paper, BTW, is Adi Shamir. Shamir said that he would like to see AES detuned for speed and extra rounds added during the RSA conf cryptographers panel a couple of years back. That is the main incentive for using AES 256 over 128. Nobody is going to be breaking AES 128 by brute force so key size above that is irrelevant but you do get the extra rounds. Saving symmetric key bits does not really bother me as pretty much any mechanism I use to derive them is going to give me plenty. I am even starting to think that maybe we should start using the NSA checksum approach. Incidentally, that checksum could be explained simply by padding prepping an EC encrypted session key. PKCS#1 has similar stuff to ensure that there is no known plaintext in there. Using the encryption algorithm instead of the OAEP hash function makes much better sense. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Elliptic curve question
On Mon, Oct 7, 2013 at 4:54 AM, Lay András and...@lay.hu wrote: Hi! I made a simple elliptic curve utility in command line PHP: https://github.com/LaySoft/ecc_phgp I know in the RSA, the sign is inverse operation of encrypt, so two different keypairs needs for encrypt and sign. In elliptic curve cryptography, the sign is not the inverse operation of encrypt, so my application use same keypair for encrypt and sign. Is this correct? Are you planning to publish your signing key or your decryption key? Use of a key for one makes the other incompatible. -- Website: http://hallambaker.com/ ___ 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 Sun, Oct 6, 2013 at 11:26 AM, John Kelsey crypto@gmail.com wrote: If we can't select ciphersuites that we are sure we will always be comfortable with (for at least some forseeable lifetime) then we urgently need the ability to *stop* using them at some point. The examples of MD5 and RC4 make that pretty clear. Ceasing to use one particular encryption algorithm in something like SSL/TLS should be the easiest case--we don't have to worry about old signatures/certificates using the outdated algorithm or anything. And yet we can't reliably do even that. I proposed a mechanism for that a long time back based on Rivest's notion of a suicide note in SDSI. The idea was that some group of cryptographers get together and create some random numbers which they then keyshare amongst themselves so that there are (say) 11 shares and a quorum of 5. Let the key be k, if the algorithm being witnessed is AES then the value AES(k) is published as the 'witness value for AES. A device that ever sees the witness value for AES presented knows to stop using it. It is in effect a 'suicide note' for AES. Similar witness functions can be specified easily enough for hashes etc. We already have the RSA factoring competition for RSA public key. In fact I suggested to Burt Kaliski that they expand the program. The cryptographic basis here is that there are only two cases where the witness value will be released, either there is an expert consensus to stop using AES (or whatever) or someone breaks AES. The main downside is that there are many applications where you can't tolerate fail-open. For example in the electricity and power system it is more important to keep the system going than to preserve confidentiality. An authenticity attack on the other hand might be cause... -- Website: http://hallambaker.com/ ___ 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 Fri, Oct 4, 2013 at 10:23 AM, John Kelsey crypto@gmail.com wrote: On Oct 4, 2013, at 10:10 AM, Phillip Hallam-Baker hal...@gmail.com wrote: ... Dobertin demonstrated a birthday attack on MD5 back in 1995 but it had no impact on the security of certificates issued using MD5 until the attack was dramatically improved and the second pre-image attack became feasible. Just a couple nitpicks: a. Dobbertin wasn't doing a birthday (brute force collision) attack, but rather a collision attack from a chosen IV. Well if we are going to get picky, yes it was a collision attack but the paper he circulated in 1995 went beyond a collision from a known IV, he had two messages that resulted in the same output when fed a version of MD5 where one of the constants had been modified in one bit position. b. Preimages with MD5 still are not practical. What is practical is using the very efficient modern collision attacks to do a kind of herding attack, where you commit to one hash and later get some choice about which message gives that hash. I find the preimage nomencalture unnecessarily confusing and have to look up the distinction between first second and platform 9 3/4s each time I do a paper. ... Proofs are good for getting tenure. They produce papers that are very citable. There are certainly papers whose only practical importance is getting a smart cryptographer tenure somewhere, and many of those involve proofs. But there's also a lot of value in being able to look at a moderately complicated thing, like a hash function construction or a block cipher chaining mode, and show that the only way anything can go wrong with that construction is if some underlying cryptographic object has a flaw. Smart people have proposed chaining modes that could be broken even when used with a strong block cipher. You can hope that security proofs will keep us from doing that. Yes, that is what I would use them for. But I note that a very large fraction of the field has studied formal methods, including myself and few of us find them to be quite as useful as the academics think them to be. The oracle model is informative but does not necessarily need to be reduced to symbolic logic to make a point. Now, sometimes the proofs are wrong, and almost always, they involve a lot of simplification of reality (like most proofs aren't going to take low-entropy RNG outputs into account). But they still seem pretty valuable to me for real-world things. Among other things, they give you a completely different way of looking at the security of a real-world thing, with different people looking over the proof and trying to attack things. I think the main value of formal methods turns out to be pedagogical. When you teach students formal methods they quickly discover that the best way to deliver a proof is to refine out every bit of crud possible before starting and arrive at an appropriate level of abstraction. But oddly enough I am currently working on a paper that presents a formalized approach. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
On Fri, Oct 4, 2013 at 12:27 AM, David Johnston d...@deadhat.com wrote: On 10/1/2013 2:34 AM, Ray Dillinger wrote: What I don't understand here is why the process of selecting a standard algorithm for cryptographic primitives is so highly focused on speed. ~ What makes you think Keccak is faster than the alternatives that were not selected? My implementations suggest otherwise. I thought the main motivation for selecting Keccak was Sponge good. You mean Keccak is spongeworthy. I do not accept the argument that the computational work factor should be 'balanced' in the way suggested. The security of a system is almost always better measured by looking at the work factor for breaking an individual message rather than the probability that two messages might be generated in circumstances that cancel each other out. Given adequate cryptographic precautions (e.e. random serial), a certificate authority can still use MD5 with an acceptable level of security even with the current attacks. They would be blithering idiots to do so of course but Flame could have been prevented with certain precautions. If a hash has a 256 bit output I know that I cannot use it in a database if the number of records approaches 2^128. But that isn't really a concern to me. The reason I use a 256 bit hash is because I want a significant safety margin on the pre-image work factor. If I was really confident that the 2^128 work factor really is 2^128 then I would be happy using a 128 bit hash for most designs. In fact in PRISM-Proof Email I am currently using a 226 bit Subject Key Identifier because I can encode that in BASE64 and the result is about the same length as a PGP fingerprint. But I really do want that 2^256 work factor. If Keccak was weakened in the manner proposed I would probably use the 512 bit version instead and truncate. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] check-summed keys in secret ciphers?
On Mon, Sep 30, 2013 at 7:44 PM, arxlight arxli...@arx.li wrote: Just to close the circle on this: The Iranians used hundreds of carpet weavers (mostly women) to reconstruct a good portion of the shredded documents which they published (and I think continue to publish) eventually reaching 77 volumes of printed material in a series wonderfully named Documents from the U.S. Espionage Den. They did a remarkably good job, considering: http://upload.wikimedia.org/wikipedia/commons/6/68/Espionage_den03_14.png There is a back story to that. One of the reasons that Ayatolah Kohmenhi knew about the CIA and embassy involvement in the 53 coup was that he was one of the hired thugs who raised the demonstrations that toppled Mossadegh. So the invasion of the embassy was in part motivated by a desire to burn any evidence of that perfidy on the regimes part. It was also used to obtain and likely forge evidence against opponents inside the regime. The files were used as a pretext for the murder of many of the leftists who were more moderate and western in their outlook. On the cipher checksum operation, the construction that would immediately occur to me would be the following: k1 = R(s) kv = k1 + E(k1, kd)// the visible key sent over the wire, kd is a device key This approach allows the device to verify that the key is intended for that device. A captured device cannot be used to decrypt arbitrary traffic even if the visible key is known. The attacker has to reverse engineer the device to make use of it, a task that is likely to take months if not years. NATO likely does an audit of every cryptographic device every few months and destroys the entire set if a single one ever goes missing. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] A stealth redo on TLS with new encoding
I think redoing TLS just to change the encoding format is to tilt at windmills. Same for HTTP (not a fan of CORE over DTLS), same for PKIX. But doing all three at once would actually make a lot of sense and I can see something like that actually happen. But only if the incremental cost of each change is negligible. Web Services are moving towards JSON syntax. Other than legacy support I can see no reason to use XML right now and the only reason to use Assanine.1 other than legacy is to avoid Base64 encoding byte blobs and escaping strings. Adding these two features to JSON is very easy and does not require a whole new encoding format, just add additional code points to the JSON encoding for length encoded binary blobs. This approach means minimal changes to JSON encoder code and allows a single decoder to be used for traditional and binary forms: https://datatracker.ietf.org/doc/draft-hallambaker-jsonbcd/ Web services are typically layered over HTTP and there are a few facilities that the HTTP layer provides that are useful in a Web Service. In particular it is very convenient to allow multiple Web Services to share the same IP address and port. Anyone who has used the Web Server in .NET will know what I mean here. Web Services use some features of HTTP but not very many. It would be very convenient if we could replace the HTTP layer with something that provides just the functionality we need but layers over UDP or TCP directly and uses JSON-B encoding. One of the features I use HTTP for is to carry authentication information on the Web Service requests and responses. I have a Web Service to do a key exchange using SSL for privacy (its a pro-tem solution though, will add in a PFS exchange at some point). http://tools.ietf.org/html/draft-hallambaker-wsconnect-04 The connect protocol produces a Kerberos like ticket which is then used to authenticate subsequent HTTP messages using a MAC. http://tools.ietf.org/html/draft-hallambaker-httpsession-01 In my view, authentication at the transport layer is not a substitute for authentication at the application layer. I want server authentication and confidentiality at least at transport layer and in addition I want mutual authentication at the application layer. For efficiency, the authentication at the application layer uses symmetric key (unless non-repudiation is required in which case digital signatures would be indicated but in addition to MAC, not as a replacement). Once a symmetric key is agreed for authentication, the use of the key for application layer authentication is reasonably obvious. http://tools.ietf.org/html/draft-hallambaker-wsconnect-04 OK, so far the scheme I describe is three independent schemes that are all designed to work inside the existing HTTP-TLS-PKIX framework and they provide value within that framework. But as I observed earlier, it is quite possible to kick the framework away and replace HTTP with a JSON-B based presentation layer framing. This is what I do in the UDP transport for omnibroker as that is intended to be a replacement for the DNS client-server interface. So in summary, yes it is quite possible that TLS could be superseded by something else, but that something else is not going to look like TLS and it will be the result of a desire to build systems that use a single consistent encoding at all layers in the stack (above the packet/session layer). Trying to reduce the complexity of TLS is plausible but all of that complexity was added for a reason and those same reasons will dictate similar features in TLS/2.0. The way to make a system simpler is not to make each of the modules simpler but to make the modules fit together more simply. Reducing the complexity of HTTP is hard, reducing the complexity of TLS is hard. Reducing the complexity of HTTP+TLS is actually easier. That said, I just wrote a spec for doing PGP key signing in Assanine.1. Because even though it is the stupidest encoding imaginable, we need to have a PKI that is capable of expressing every assertion type that people have found a need for. That means either we add the functionality of PKIX to the PGP world or vice versa. The PKIX folk have a vast legacy code base and zero interest in compromise, many are completely wedged on ASN.1. The PGP code base is much less embedded than PKIX and PGP folk are highly ideologically motivated to bring privacy to the masses rather than the specific PGP code formats. So I have to write my key endorsement message format in Assanine.1. If I can stomach that then so can everyone else. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ised
On Thu, Oct 3, 2013 at 5:19 AM, ianG i...@iang.org wrote: On 3/10/13 00:37 AM, Dave Horsfall wrote: On Wed, 2 Oct 2013, Jerry Leichter wrote: Always keep in mind - when you argue for easy readability - that one of COBOL's design goals was for programs to be readable and understandable by non-programmers. Managers, in particular. SQL, too, had that goal. 4GLs (remember them?). XML. Has it ever worked? XML was not intended to be easy to read, it was designed to be less painful to work with than SGML, that is all. There are actually good reasons why a document markup format needs to have more features than a protocol data encoding format. People tend to edit documents and need continuous syntax checks for a start. XML is actually a good document format and a lousy RPC encoding. Although that is exactly what SOAP is designed to turn XML into. The design of WSDL and SOAP is entirely due to the need to impedance match COM to HTTP. What does work in my experience is to design a language that is highly targeted at a particular problem set. Like building FSRs or LR(1) parsers or encoding X.509 certificates (this week's work). And no, an ASN1 compiler is not a particularly useful tool for encoding X.509v3 certs as it turns out. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Replying to James and John. Yes, the early ARPANET protocols are much better than many that are in binary formats. But the point where data encoding becomes an issue is where you have nested structures. SMTP does not have nested structures or need them. A lot of application protocols do. I have seen a lot of alternatives to X.509 that don't use ASN.1 and are better for it. But they all use nesting. And to get back on topic, the main motive for adding binary to JSON is to support signed blobs and encrypted blobs. Text encodings are easy to read but very difficult to specify boundaries in without ambiguity. Responding to James, No, the reason for baring multiple inheritance is not that it is too clever, it is that studies have shown that code using multiple inheritance is much harder for other people to understand than code using single inheritance. The original reason multiple inheritance was added to C was to support collections. So if you had a class A and a subclass B and wanted to have a list of B then the way you would do it in the early versions of C++ was to inherit from the 'list' class. I think that approach is completely stupid, broken and wrong. It should be possible for people to make lists or sets or bags of any class without the author of the class providing support. Which is why C# has functional types, ListT. Not incidentally, C also has functional types (or at least the ability to implement same easily). Which is why as a post doc, having studied program language design (Tony Hoare was my college tutor), having written a thesis on program language design, I came to the conclusion that C was a better language base than C++ back in the early 1990s. I can read C++ but it takes me far longer to work out how to do something in C++ than to actually do it in C. So I can't see where C++ is helping. It is reducing, not improving my productivity. I know that some features of the language have been extended/fixed since but it is far too late. At this point it is clear that C++ is a dead end and the future of programming languages will be based on Java, C# (and to a lesser extent Objective C) approaches. Direct multiple inheritance will go and be replaced by interfaces. Though with functional types, use of interfaces is very rarely necessary. So no, I don't equate prohibiting multiple direct inheritance with 'too clever code'. There are good reasons to avoid multiple inheritance, both for code maintenance and to enable the code base to be ported to more modern languages in the future. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On Fri, Sep 27, 2013 at 3:59 AM, John Gilmore g...@toad.com wrote: And the problem appears to be compounded by dofus legacy implementations that don't support PFS greater than 1024 bits. This comes from a misunderstanding that DH keysizes only need to be half the RSA length. So to go above 1024 bits PFS we have to either 1) Wait for all the servers to upgrade (i.e. never do it because the won't upgrade) 2) Introduce a new cipher suite ID for 'yes we really do PFS at 2048 bits or above'. Can the client recover and do something useful when the server has a buggy (key length limited) implementation? If so, a new cipher suite ID is not needed, and both clients and servers can upgrade asynchronously, getting better protection when both sides of a given connection are running the new code. Actually, it turns out that the problem is that the client croaks if the server tries to use a key size that is bigger than it can handle. Which means that there is no practical way to address it server side within the current specs. In the case of (2) I hope you mean yes we really do PFS with an unlimited number of bits. 1025, 2048, as well as 16000 bits should work. There is no reason to use DH longer than the key size in the certificate and no reason to use a shorter DH size either. Most cryptolibraries have a hard coded limit at 4096 bits and there are diminishing returns to going above 2048. Going from 4096 to 8192 bits only increases the work factor by a very small amount and they are really slow which means we end up with DoS considerations. We really need to move to EC above RSA. Only it is going to be a little while before we work out which parts have been contaminated by NSA interference and which parts are safe from patent litigation. RIM looks set to collapse with or without the private equity move. The company will be bought with borrowed money and the buyers will use the remaining cash to pay themselves a dividend. Mitt Romney showed us how that works. We might possibly get lucky and the patents get bought out by a white knight. But all the mobile platform providers are in patent disputes right now and I can't see it likely someone will plonk down $200 million for a bunch of patents and then make the crown jewels open. Problem with the NSA is that its Jekyll and Hyde. There is the good side trying to improve security and the dark side trying to break it. Which side did the push for EC come from? -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The hypothetical random number generator backdoor
On Tue, Sep 24, 2013 at 10:59 AM, Jerry Leichter leich...@lrw.com wrote: On Sep 22, 2013, at 8:09 PM, Phillip Hallam-Baker hal...@gmail.com wrote: I was thinking about this and it occurred to me that it is fairly easy to get a public SSL server to provide a client with a session key - just ask to start a session. Which suggests that maybe the backdoor [for an NSA-spiked random number generator] is of the form that ... you get a lot of nonces [maybe just one] from the random number generator ... and that allows the [next one to be predicted more easily or even the] seed to be unearthed. One simple way [to stop this] would be to encrypt the nonces from the RNG under a secret key generated in some other fashion. nonce = E (R, k) Or hashing the RNG output and XORing with it nonce = R XOR H(R) You shifted from random value to nonce. Given the severe effects on security that using a nonce - a value that is simply never repeated in a given cryptographic context; it may be predictable, even fixed - to a random value, one needs to be careful about the language. (There's another layer as well, partly captured by unpredictable value but not really: Is it a value that we must plan on the adversary learning at some point, even though he couldn't predict it up front, or must it remain secret? The random values in PFS are only effective in providing forward security if they remain secret forever.) Anyway, everything you are talking about here is *supposed* to be a random value. Using E(R,k) is a slightly complicated way of using a standard PRNG: The output of a block cipher in counter mode. Given (a) the security of the encryption under standard assumptions; (b) the secrecy and randomness of k; the result is a good PRNG. (In fact, this is pretty much exactly one of the Indistinguishability assumptions. There are subtly different forms of those around, but typically the randomness of input is irrelevant - these are semantic security assumptions so knowing something about the input can't help you.) Putting R in there can't hurt, and if the way you got R really is random then even if k leaks or E turns out to be weak, you're still safe. However ... where does k come from? To be able to use any of the properties of E, k itself must be chosen at random. If you use the same generator as way use to find R, it's not clear that this is much stronger than R itself. If you have some assured way of getting a random k - why not use it for R itself? (This might be worth it if you can generate a k you believe in but only at a much lower rate than you can generate an R directly. Then you can stretch k over a number of R values. But I'd really think long and hard about what you're assuming about the various components.) BTW, one thing you *must not* do is have k and the session key relate to each other in any simple way. For hash and XOR ... no standard property of any hash function tells you anything about the properties of R XOR H(R). Granted, for the hash functions we generally use, it probably has about the same properties; but it won't have any more than that. (If you look at the structure of classic iterated hashes, the last thing H did was compute S = S + R(S), where S was the internal state and R was the round function. Since R is usually invertible, this is the only step that actually makes the whole thing non-invertible. Your more-or-less repetition of the same operation probably neither helps more hinders.) At least if we assume the standard properties, it's hard to get R from H(R) - but an attacker in a position to try a large but (to him) tractable number of guesses for R can readily check them all. Using R XOR H(R) makes it no harder for him to try that brute force search. I much prefer the encryption approach. There are three ways a RNG can fail 1) Insufficient randomness in the input 2) Losing randomness as a result of the random transformation 3) Leaking bits through an intentional or unintentional side channel What I was concerned about in the above was (3). I prefer the hashing approaches. While it is possible that there is a matched set of weaknesses, I find that implausible. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On Sun, Sep 22, 2013 at 2:00 PM, Stephen Farrell stephen.farr...@cs.tcd.iewrote: On 09/22/2013 01:07 AM, Patrick Pelletier wrote: 1024 bits is enough for anyone That's a mischaracterisation I think. Some folks (incl. me) have said that 1024 DHE is arguably better that no PFS and if current deployments mean we can't ubiquitously do better, then we should recommend that as an option, while at the same time recognising that 1024 is relatively short. And the problem appears to be compounded by dofus legacy implementations that don't support PFS greater than 1024 bits. This comes from a misunderstanding that DH keysizes only need to be half the RSA length. So to go above 1024 bits PFS we have to either 1) Wait for all the servers to upgrade (i.e. never do it because the won't upgrade) 2) Introduce a new cipher suite ID for 'yes we really do PFS at 2048 bits or above'. I suggest (2) -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] The hypothetical random number generator backdoor
So we think there is 'some kind' of backdoor in a random number generator. One question is how the EC math might make that possible. Another is how might the door be opened. I was thinking about this and it occurred to me that it is fairly easy to get a public SSL server to provide a client with a session key - just ask to start a session. Which suggests that maybe the backdoor is of the form that if you know nonce i, and the private key to the backdoor, that reduces the search space for finding nonce i+1. Or maybe there is some sort of scheme where you get a lot of nonces from the random number generator, tens of thousands and that allows the seed to be unearthed. Either way, the question is how to stop this side channel attack. One simple way would be to encrypt the nonces from the RNG under a secret key generated in some other fashion. nonce = E (R, k) Or hashing the RNG output and XORing with it nonce = r XOR H (r) Either way, there is an extra crypto system in the way that has to be broken if a random number generator turns out to have some sort of relationship between sequential outputs. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On Thu, Sep 19, 2013 at 4:15 PM, Ben Laurie b...@links.org wrote: On 18 September 2013 21:47, Viktor Dukhovni cryptogra...@dukhovni.orgwrote: On Wed, Sep 18, 2013 at 08:04:04PM +0100, Ben Laurie wrote: This is only realistic with DANE TLSA (certificate usage 2 or 3), and thus will start to be realistic for SMTP next year (provided DNSSEC gets off the ground) with the release of Postfix 2.11, and with luck also a DANE-capable Exim release. What's wrong with name-constrained intermediates? X.509 name constraints (critical extensions in general) typically don't work. No. They typically work. As usual, Apple are the fly in the ointment. The key to make them work is to NOT follow the IETF standard and to NOT mark the extension critical. If the extension is marked critical as RFC 5280 demands then the certificates will break in Safari (and very old versions of some other top tier browsers). If the extension is not marked critical as CABForum and Mozilla recommend then nothing breaks and the certificate chain will be correctly processed by every current edition of every top tier browser apart from Safari. The peculiar insistence that the extension be marked critical despite the obvious fact that it breaks stuff is one of the areas where I suspect NSA interference. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On Thu, Sep 19, 2013 at 5:11 PM, Max Kington mking...@webhanger.com wrote: On 19 Sep 2013 19:11, Bill Frantz fra...@pwpconsult.com wrote: On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote: I know I would be a lot more comfortable with a way to check the mail against a piece of paper I received directly from my bank. I would say this puts you in the sub 1% of the populace. Most people want to do things online because it is much easier and gets rid of paper. Those are the systems we need to secure. Perhaps another way to look at it: how can we make out-of-band verification simpler? Do you have any evidence to support this contention? Remember we're talking about money, not just social networks. I can support mine. ;-) If organizations like Consumers Union say that you should take that number from the bank paperwork you got when you signed up for an account, or signed up for online banking, or got with your monthly statement, or got as a special security mailing and enter it into your email client, I suspect a reasonable percentage of people would do it. It is, after all a one time operation. As with other themes though, one size does not fit all. The funny thing being that banks are actually extremely adept at doing out of band paper verification. Secure printing is born out of financial transactions, everything from cheques to cash to PIN notification. I think it was Phillip who said that other trust models need to be developed. I'm not as down on the Web of trust as others are but I strongly believe that there has to be an ordered set of priorities. Usability has to be right up there as a near-peer with overall system security. Otherwise as we've seen a real attack in this context is simply to dissuade people to use it and developers, especially of security oriented systems can do that of their own accord. If you want to get your systems users to help with out of band verification get them 'talking' to each other. Perry said that our social networks are great for keeping spam out of our mailboxes yet were busy trying to cut out the technology that's driven all of this. Out of band for your banking might mean security printing techniques and securing your email, phoning your friends. Bear in mind that securing financial transactions is exactly what we designed the WebPKI to do and it works very well at that. Criminals circumvent the WebPKI rather than trying to defeat it. If they did start breaking the WebPKI then we can change it and do something different. But financial transactions are easier than protecting the privacy of political speech because it is only money that is at stake. The criminals are not interested in spending $X to steal $0.5X. We can do other stuff to raise the cost of attack if it turns out we need to do that. So I think what we are going to want is more than one trust model depending on the context and an email security scheme has to support several. If we want this to be a global infrastructure we have 2.4 billion users to support. If we spend $0.01 per user on support, that is $24 million. It is likely to be a lot more than that per user. Enabling commercial applications of the security infrastructure is essential if we are to achieve deployment. If the commercial users of email can make a profit from it then we have at least a chance to co-opt them to encourage their customers to get securely connected. One of the reasons the Web took off like it did in 1995 was that Microsoft and AOL were both spending hundreds of millions of dollars advertising the benefits to potential users. Bank America, PayPal etc are potential allies here. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] InfoRequest: How to configure email clients to accept encrypted S/MIME
Working on Prism Proof email, I could use information on how to configure various email clients to support S/MIME decryption using a previously generated key package. While descriptions of how the user can configure S/MIME would be nice, what I am really after is information on the internals so that it would be possible for a tool to do this configuration for the user automatically. Info on where the account configuration data is stored would also be very useful. The end goal here is a tool that will generate and manage private keys and configure their email clients so that they can read mail encrypted under them. If we have the 'how to read encrypted mail well' side of things sorted using this tool that leaves only the 'how to send encrypted mail well' as a research problem. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On Wed, Sep 18, 2013 at 5:23 PM, Lucky Green shamr...@cypherpunks.towrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-14 08:53, Peter Fairbrother wrote: I get that 1024 bits is about on the edge, about equivalent to 80 bits or a little less, and may be crackable either now or sometime soon. Moti Young and others wrote a book back in the 90's (or perhaps) 80's, that detailed the strength of various RSA key lengths over time. I am too lazy to look up the reference or locate the book on my bookshelf. Moti: help me out here? :-) According to published reports that I saw, NSA/DoD pays $250M (per year?) to backdoor cryptographic implementations. I have knowledge of only one such effort. That effort involved DoD/NSA paying $10M to a leading cryptographic library provider to both implement and set as the default the obviously backdoored Dual_EC_DRBG as the default RNG. This was $10M wasted. While this vendor may have had a dominating position in the market place before certain patents expired, by the time DoD/NSA paid the $10M, few customers used that vendor's cryptographic libraries. There is no reason to believe that the $250M per year that I have seen quoted as used to backdoor commercial cryptographic software is spent to any meaningful effect. The most corrosive thing about the whole affair is the distrust it has sewn. I know a lot of ex-NSA folk and none of them has ever once asked me to drop a backdoor. And I have worked very closely with a lot of government agencies. Your model is probably wrong. Rather than going out to a certain crypto vendor and asking them to drop a backdoor, I think they choose the vendor on the basis that they have a disposition to a certain approach and then they point out that given that they have a whole crypto suite based on EC wouldn't it be cool to have an EC based random number generator. I think that the same happens in IETF. I don't think it very likely Randy Bush was bought off by the NSA when he blocked deployment of DNSSEC for ten years by killing OPT-IN. But I suspect that a bunch of folk were whispering in his ear that he needed to be strong and resist what was obviously a blatant attempt at commercial sabotage etc. etc. I certainly think that the NSA is behind the attempt to keep the Internet under US control via ICANN which is to all intents a quango controlled by the US government. For example, ensuring that the US has the ability to impose a digital blockade by dropping a country code TLD out of the root. Right now that is a feeble threat because ICANN would be over in a minute if they tried. But deployment of DNSSEC will give them the power to do that and make it stick (and no, the key share holders cannot override the veto, the shares don't work without the key hardware). A while back I proposed a scheme based on a quorum signing proposal that would give countries like China and Brazil the ability to assure themselves that they were not subjected to the threat of future US capture. I have also proposed that countries have a block of IPv6 and BGP-AS space assigned as a 'Sovereign Reserve'. Each country would get a /32 which is more than enough to allow them to ensure that an artificial shortage of IPv6 addresses can't be used as a blockade. If there are government folk reading this list who are interested I can show them how to do it without waiting on permission from anyone. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
A few clarifications 1) PRISM-Proof is a marketing term I have not spent a great deal of time looking at the exact capabilities of PRISM vs the other programs involved because from a design point they are irrelevant. The objective is to harden/protect the infrastructure from any ubiquitous, indiscriminate intercept capability like the one Gen Alexander appears to have constructed. PRISM-class here is merely a handy label for a class of attack where the attacker can spend upwards of $100 million to perform an attack which potentially affects every Internet user. PRISM-class is a superset of PRISM, BULLRUN, MANASAS, etc. etc. 2) SSL is not designed to resist government intercept Back in 1993-6 when I was working on Internet security and payments at CERN and the Web Consortium the priority was to make payments on the Web, not make it resistant to government intercept. The next priority was to establish the authenticity of news Web sites. There were several reasons for that set of priorities, one of which was that the technology we had available was limited and it was impractical to do more than one public key operation per session and it was only practical to use public key some of the time. Severs of the day simply could not handle the load otherwise. Twenty years later, much has changed and we can do much more. The designs do not need to be constrained in the way they were then. It is not a question of whether email is encrypted in transport OR at rest, we need both. There are different security concerns at each layer. 3) We need more than one PKI for Web and email security. PGP and S/MIME have different key distribution models. Rather than decide which is 'better' we need to accept that we need both approaches and in fact need more. If I am trying to work out if an email was really sent by my bank then I want a CA type security model because less than 0.1% of customers are ever going to understand a PGP type web of trust for that particular purpose. But its the bank sending the mail, not an individual at the bank. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] An NSA mathematician shares his from-the-trenches view of the agency's surveillance activities
On Tue, Sep 17, 2013 at 8:01 PM, John Gilmore g...@toad.com wrote: Techdirt takes apart his statement here: https://www.techdirt.com/articles/20130917/02391824549/nsa-needs-to-give-its-rank-and-file-new-talking-points-defending-surveillance-old-ones-are-stale.shtml NSA Needs To Give Its Rank-and-File New Talking Points Defending Surveillance; The Old Ones Are Stale from the that's-not-really-going-to-cut-it dept by Mike Masnick, Tue, Sep 17th 2013 It would appear that the NSA's latest PR trick is to get out beyond the top brass -- James Clapper, Keith Alexander, Michael Hayden and Robert Litt haven't exactly been doing the NSA any favors on the PR front lately -- and get some commentary from the rank and file. ZDNet apparently agreed to publish a piece from NSA mathemetician/ cryptanalyst Roger Barkan in which he defends the NSA using a bunch of already debunked talking points. What's funny is that many of these were the talking points that the NSA first tried out back in June and were quickly shown to be untrue. However, let's take a look. It's not that Barkan is directly lying... it's just that he's setting up strawmen to knock down at a record pace. As someone who has met Hayden, I do not think his words are necessarily untrue, they may be out of date. It appears that there was a major change at the NSA after his departure. In particular the number of external contractors seems to have increased markedly (based on the number and type of job adverts from SAIC, Booz-Allen, Van Dyke, etc.) The enterprise bridge control center certainly does not seem to be Hayden's style either. Hayden is not the type to build a showboat like that. After 9/11 we discovered that our view of the cryptowars was completely false in one respect. Louis Freeh wasn't building a panopticon, he simply had no comprehension of the power of the information he was demanding the ability to collect. The FBI computer systems were antiquated, lacking the ability to do keyword search on two terms. I rather suspect that Alexander is similarly blind to the value of the information the system is collecting. They might well be telling the truth when they told the court that the system was so compartmentalized and segregated nobody knew what it was doing. For example, did the NSA people who thought it a good wheeze to trade raw SIGINT on US citizens to the Israelis understand what they were passing on? They certainly don't seem to know the past history of US-Israeli 'cooperation' only last year an Israeli firm was trying to sell intercept equipment to Iran through an intermediary and the story of how the Chinese got an example of the Stinger missile to copy is well known. My country has had an arms embargo on Israel for quite a while due to breach of Israeli undertakings not to use military weapons against civilians. That does not make the situation any less dangerous, it makes it more so. What Barkan does not mention is that we know that the NSA internal controls have collapsed completely, Snowdens disclosure proves that. Snowden should never have had access to the information he has disclosed. As with gwbush53.com, the intelligence gathered through PRISM-class intercepts will undoubtedly be spread far and wide. Anything Snowden knows, China and Russia will know. The fact that nothing has been said on that publicly by the NSA spokespeople is something of a concern. They have a big big problem and heads should be rolling. I can't see how Clapper and Alexander can remain given the biggest security breach in NSA history on their watch. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] PRISM-Proofing and PRISM-Hardening
My phrase PRISM-Proofing seems to have created some interest in the press. PRISM-Hardening might be more important, especially in the short term. The objective of PRISM-hardening is not to prevent an attack absolutely, it is to increase the work factor for the attacker attempting ubiquitous surveillance. Examples include: Forward Secrecy: Increases work factor from one public key per host to one public key per TLS session. Smart Cookies: Using cookies as authentication secrets and passing them as plaintext bearer tokens is stupid. It means that all an attacker needs to do is to compromise TLS once and they have the authentication secret. The HTTP Session-ID draft I proposed a while back reduces the window of compromise to the first attack. I am sure there are other ways to increase the work factor. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] End to end
Just writing document two in the PRISM-Proof series. I probably have to change the name before November. Thinking about 'Privacy Protected' which has the same initials. People talk about end-to-end without talking about what they are. In most cases at least one end is a person or an organization, not a machine. So when we look at the security of the whole system people security issues like the fact they forget private key passphrases and lose machines matter. Which ends you are talking about depends on what the context is. If we are talking about message formats then the ends are machines. If we are talking about trust then the ends are people and organizations. End to end has a lot of costs. Deploying certificates to end users is expensive in an enterprise and often unnecessary. If people are sending email through the corporate email system then in many cases the corporation has a need/right to see what they are sending/receiving. So one conclusion about S/MIME and PGP is that they should support domain level confidentiality and confidentiality, not just account level. Another conclusion is that end-to-end security is orthogonal to transport. In particular there are good use cases for the following configuration: Mail sent from al...@example.com to b...@example.net * DKIM signature on message from example.com as outbound MTA 'From'. * S/MIME Signature on message from example.com with embedded logotype information. * TLS Transport Layer Security with Forward Secrecy to example.net mail server using DNSSEC and DANE to authenticate the IP address and certificate. * S/MIME encryption under example.net EV certificate * S/MIME encryption under b...@example.net personal certificate. [Hold onto flames about key validation and web of trust for the time being. Accepting the fact that S/MIME has won the message format deployment battle does not mean we are obliged to use the S/MIME PKI unmodified or require use of CA validated certificates.] Looking at the Certificate Transparency work, I see a big problem with getting the transparency to be 'end-to-end', particularly with Google's insistence on no side channels and ultra-low latency. To me the important thing about transparency is that it is possible for anyone to audit the key signing process from publicly available information. Doing the audit at the relying party end prior to every reliance seems a lower priority. In particular, there are some type of audit that I don't think it is feasible to do in the endpoint. The validity of a CT audit is only as good as your newest notary timestamp value. It is really hard to guarantee that the endpoint is not being spoofed by a PRISM capable adversary without going to techniques like quorate checking which I think are completely practical in a specialized tracker but impractical to do in an iPhone or any other device likely to spend much time turned off or otherwise disconnected from the network. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On Mon, Sep 16, 2013 at 3:14 PM, Ben Laurie b...@links.org wrote: On 16 September 2013 18:49, Phillip Hallam-Baker hal...@gmail.com wrote: To me the important thing about transparency is that it is possible for anyone to audit the key signing process from publicly available information. Doing the audit at the relying party end prior to every reliance seems a lower priority. This is a fair point, and we could certainly add on to CT a capability to post-check the presence of a pre-CT certificate in a log. Yeah, not trying to attack you or anything. Just trying to work out exactly what the security guarantees provided are. In particular, there are some type of audit that I don't think it is feasible to do in the endpoint. The validity of a CT audit is only as good as your newest notary timestamp value. It is really hard to guarantee that the endpoint is not being spoofed by a PRISM capable adversary without going to techniques like quorate checking which I think are completely practical in a specialized tracker but impractical to do in an iPhone or any other device likely to spend much time turned off or otherwise disconnected from the network. I think the important point is that even infrequently connected devices can _eventually_ reveal the subterfuge. I doubt it is necessary to go very far to deter PRISM type surveillance. If that continues very long at all. The knives are out for Alexander, hence the story about his Enterprise bridge operations room. Now the Russians... Do we need to be able to detect PRISM type surveillance in the infrequently connected device or is is sufficient to be able to detect it somewhere? One way to get as good timestamp into a phone might be to use a QR code: This is I think as large as would be needed: [image: Inline image 1] -- Website: http://hallambaker.com/ qr-256.png___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Mon, Sep 16, 2013 at 2:48 PM, zooko zo...@zooko.com wrote: On Sun, Sep 08, 2013 at 08:28:27AM -0400, Phillip Hallam-Baker wrote: It think we need a different approach to source code management. Get rid of user authentication completely, passwords and SSH are both a fragile approach. Instead every code update to the repository should be signed and recorded in an append only log and the log should be public and enable any party to audit the set of updates at any time. This would be 'Code Transparency'. This is a very good idea, and eminently doable. See also Ben Laurie's blog post: http://www.links.org/?p=1262 Problem is we would need to modify GIT to implement. No, simply publish the git commits (hashes) in a replicated, append-only log. Well people bandwidth is always a problem. But what I want is not just the ability to sign, I want to have a mechanism to support verification and checking of the log etc. etc. So what's the next step? We just need the replicated, append-only log. Where I am headed is to first divide up the space for PRISM-PROOF email between parts that are solved and only need good execution (message formats, mail integration, etc) and parts that are or may be regarded as research (key distribution, key signing, PKI). Once that is done I am going to be building myself a very lightweight development testbed built on a SMTP/SUBMIT + IMAP proxy. But hopefully other people will see that there is general value to such a scheme and work on: [1] Enabling MUAs to make use of research built on the testbed. [2] Enabling legacy PKI to make use of the testbed. [3] Research schemes Different people have different skills and different interests. My interest is on the research side but other folk just want to write code to a clear spec. Anyone going for [3] has to understand at the outset that whatever they do is almost certain to end up being blended with other work before a final standard is arrived at. We cannot afford another PGP/SMIME debacle. On the research side, I am looking at something like Certificate Transparency but with a two layer notary scheme. Instead of the basic infrastructure unit being a CA, the basic infrastructure unit is a Tier 2 append only log. To get people to trust your key you get it signed by a trust provider. Anyone can be a trust provider but not every trust provider is trusted by everyone. A CA is merely a trust provider that issues policy and practices statements and is subject to third party audit. The Tier 2 notaries get their logs timestamped by at least one Tier 1 notary and the Tier 1 notaries cross notarize. So plugging code signing projects into a Tier 2 notary would make a lot of sense. We could also look at getting Sourceforge and GITHub to provide support maybe. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart bill.stew...@pobox.comwrote: At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote: Perfect Forward Secrecy is not perfect. In fact it is no better than regular public key. The only difference is that if the public key system is cracked then with PFS the attacker has to break every single key exchange and not just the keys in the certificates and if you use an RSA outer with an ECC inner then you double the cryptanalytic cost of the attack (theory as well as computation). I wouldn't mind if it had been called Pretty Good Forward Secrecy instead, but it really is a lot better than regular public key. My point was that the name is misleading and causes people to look for more than is there. It took me a long time to work out how PFS worked till I suddenly realized that it does not deliver what is advertised. The main difference is that cracking PFS requires breaking every single key exchange before the attack using cryptanalysis, while cracking the RSA or ECC outer layer can be done by compromising the stored private key, which is far easier to do using subpoenas or malware or rubber hoses than cryptanalysis. That is my point precisely. Though the way you put it, I have to ask if PFS deserves higher priority than Certificate Transparency. As in something we can deploy in weeks rather than years. I have no problem with Certificate Transparency. What I do have trouble with is Ben L.'s notion of Certificate Transparency and Automatic Audit in the End Client which I imposes a lot more in the way of costs than just transparency and moreover he wants to push out the costs to the CAs so he can hyper-tune the performance of his browser. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Summary of the discussion so far
I have attempted to produce a summary of the discussion so far for use as a requirements document for the PRISM-PROOF email scheme. This is now available as an Internet draft. http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt I have left out acknowledgements and references at the moment. That is likely to take a whole day going back through the list and I wanted to get this out. If anyone wants to claim responsibility for any part of the doc then drop me a line and I will have the black helicopter sent round. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The One True Cipher Suite
On Mon, Sep 9, 2013 at 3:58 AM, ianG i...@iang.org wrote: On 9/09/13 02:16 AM, james hughes wrote: I am honestly curious about the motivation not to choose more secure modes that are already in the suites? Something I wrote a bunch of years ago seems apropos, perhaps minimally as a thought experiment: Hypothesis #1 -- The One True Cipher Suite In cryptoplumbing, the gravest choices are apparently on the nature of the cipher suite. To include latest fad algo or not? Instead, I offer you a simple solution. Don't. There is one cipher suite, and it is numbered Number 1. Cypersuite #1 is always negotiated as Number 1 in the very first message. It is your choice, your ultimate choice, and your destiny. Pick well. If your users are nice to you, promise them Number 2 in two years. If they are not, don't. Either way, do not deliver any more cipher suites for at least 7 years, one for each hypothesis. And then it all went to pot... We see this with PGP. Version 2 was quite simple and therefore stable -- there was RSA, IDEA, MD5, and some weird padding scheme. That was it. Compatibility arguments were few and far between. Grumbles were limited to the padding scheme and a few other quirks. Then came Versions 3-8, and it could be said that the explosion of options and features and variants caused more incompatibility than any standards committee could have done on its own. Avoid the Champagne Hangover Do your homework up front. Pick a good suite of ciphers, ones that are Pareto-Secure, and do your best to make the combination strong [1]. Document the short falls and do not worry about them after that. Cut off any idle fingers that can't keep from tweaking. Do not permit people to sell you on the marginal merits of some crazy public key variant or some experimental MAC thing that a cryptographer knocked up over a weekend or some minor foible that allows an attacker to learn your aunty's birth date after asking a million times. Resist the temptation. Stick with The One. Steve Bellovin has made the same argument and I agree with it. Proliferation of cipher suites is not helpful. The point I make is that adding a strong cipher does not make you more secure. Only removing the option of using weak ciphers makes you more secure. There are good reasons to avoid MD5 and IDEA but at this point we are very confident of AES and SHA3 and reasonably confident of RSA. We will need to move away from RSA at some point in the future. But ECC is a mess right now. We can't trust the NIST curves any more and the IPR status is prohibitively expensive to clarify. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 8:53 PM, Gregory Perry gregory.pe...@govirtual.tvwrote: On 09/07/2013 07:52 PM, Jeffrey I. Schiller wrote: Security fails on the Internet for three important reasons, that have nothing to do with the IETF or the technology per-se (except for point 3). 1. There is little market for “the good stuff”. When people see that they have to provide a password to login, they figure they are safe... In general the consuming public cannot tell the difference between “good stuff” and snake oil. So when presented with a $100 “good” solution or a $10 bunch of snake oil, guess what gets bought. The IETF mandates the majority of the standards used on the Internet today. No they do not. There is W3C and OASIS both of which are larger now. And there has always been IEEE. And they have no power to mandate anything. In fact one of the things I have been trying to do is to persuade people that the Canute act commanding the tides to turn is futile. People need to understand that the IETF does not have any power to mandate anything and that stakeholders will only follow standards proposals if they see a value in doing so. If the IETF were truly serious about authenticity and integrity and confidentiality of communications on the Internet, then there would have been interim ad-hoc link layer encryption built into SMTP communications since the end of U.S. encryption export regulations. Like STARTTLS which has been in the standards and deployed for a decade now? There would have been an IETF-mandated requirement for Voice over IP transport encryption, to provide a comparable set of confidentiality with VoIP communications that are inherent to traditional copper-based landline telephones. There would at the very least be ad-hoc (read non-PKI integrated) DNSSEC. What on earth is that? DNS is a directory so anything that authenticates directory attributes is going to be capable of being used as a PKI. And then there is this Bitcoin thing. I say this as an individual that doesn't even like Bitcoin. For the record and clearly off topic, I hate Bitcoin with a passion and I believe that the global economic crisis could be easily averted by returning to a precious metal standard with disparate local economies and currencies, all in direct competition with each other for the best possible GDP. The value of all the gold in the world ever mined is $8.2 trillion. The NASDAQ alone traded $46 trillion last Friday. There are problems with bitcoin but I would worry rather more about the fact that the Feds have had no trouble at all shutting down every prior attempt at establishing a currency of that type and the fact that there is no anonymity whatsoever. So how does Bitcoin exist without the IETF? In its infancy, millions of dollars of transactions are being conducted daily via Bitcoin, and there is no IETF involved and no central public key infrastructure to validate the papers of the people trading money with each other. How do you counter this Bitcoin thing, especially given your tenure and experience at the IETF? Umm I would suggest that it has more to do with supply and demand and the fact that there is a large amount of economic activity that is locked out of the formal banking system (including the entire nation of Iran) that is willing to pay a significant premium for access to a secondary. Nonsense. Port 25 connects to another port 25 and exchanges a public key. Then a symmetrically keyed tunnel is established. This is not a complex thing, and could have been written into the SMTP RFC decades ago. RFC 3702 published in 2002. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 10:35 PM, Gregory Perry gregory.pe...@govirtual.tvwrote: On 09/07/2013 09:59 PM, Phillip Hallam-Baker wrote: Anyone who thinks Jeff was an NSA mole when he was one of the main people behind the MIT version of PGP and the distribution of Kerberos is talking daft. I think that the influence was rather more subtle and was more directed at encouraging choices that would make the crypto hopelessly impractical so people would not use it than in adding backdoors. One of the lessons of PRISM is that metadata is very valuable. In particular social network analysis. If I know who is talking to whom then I have pretty much 90% of the data needed to wrap up any conspiracy against the government. So lets make sure we all use PGP and sign each other's keys... 1) At the core of the initial PGP distribution authored by Philip R. Zimmermann, Jr. was the RSA public key encryption method 2) At that time, the Clinton administration and his FBI was advocating widespread public key escrow mechanisms, in addition to the inclusion of the Clipper chip to all telecommunication devices to be used for remote lawful intercepts 3) Shortly after the token indictment of Zimmerman (thus prompting widespread use and promotion of the RSA public key encryption algorithm), the Clinton administration's FBI then advocated a relaxation of encryption export regulations in addition to dropping all plans for the Clipper chip 4) On September 21, 2000, the patent for the RSA public key encryption algorithm expired, yet RSA released their open source version of the RSA encryption algorithm two weeks prior to their patent's expiry for use within the public domain 5) Based upon the widespread use and public adoption of the RSA public key encryption method via the original PGP debacle, RSA (now EMC) could have easily adjusted the initial RSA patent term under the auspice of national security, which would have guaranteed untold millions (if not billions) of additional dollars in revenue to the corporate RSA patent holder You do the math This is seriously off topic here but the idea that the indictment of Phil Zimmerman was a token effort is nonsense. I was not accusing Phil Z. of being a plant. Not only was Louis Freeh going after Zimmerman for real, he went against Clinton in revenge for the Clipper chip program being junked. He spent much of Clinton's second term conspiring with Republicans in Congress to get Clinton impeached. Clipper was an NSA initiative that began under Bush or probably even earlier. They got the incoming administration to endorse it as a fait accompli. Snowden and Manning on the other hand... Well I do wonder if this is all some mind game to get people to secure the Internet against cyberattacks. But the reason I discount that as a possibility is that what has been revealed has completely destroyed trust. We can't work with the Federal Government on information security the way that we did in the past any more. I think the administration needs to make a downpayment on restoring trust. They could begin by closing the gulag in Guantanamo. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] MITM source patching [was Schneier got spooked]
On Sun, Sep 8, 2013 at 1:42 AM, Tim Newsham tim.news...@gmail.com wrote: Jumping in to this a little late, but: Q: Could the NSA be intercepting downloads of open-source encryption software and silently replacing these with their own versions? A: (Schneier) Yes, I believe so. perhaps, but they would risk being noticed. Some people check file hashes when downloading code. FreeBSD's port system even does it for you and I'm sure other package systems do, too. If this was going on en masse, it would get picked up pretty quickly... If targeted, on the other hand, it would work well enough... But is the source compromised in the archive? It think we need a different approach to source code management. Get rid of user authentication completely, passwords and SSH are both a fragile approach. Instead every code update to the repository should be signed and recorded in an append only log and the log should be public and enable any party to audit the set of updates at any time. This would be 'Code Transparency'. Problem is we would need to modify GIT to implement. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 9:50 PM, John Gilmore g...@toad.com wrote: First, DNSSEC does not provide confidentiality. Given that, it's not clear to me why the NSA would try to stop or slow its deployment. DNSSEC authenticates keys that can be used to bootstrap confidentiality. And it does so in a globally distributed, high performance, high reliability database that is still without peer in the world. It was never clear to me why DNSSEC took so long to deploy, though there was one major moment at an IETF in which a member of the IESG told me point blank that Jim Bidzos had made himself so hated that the IETF would never approve a standard that required the use of the RSA algorithm -- even despite a signed blanket license for use of RSA for DNSSEC, and despite the expiration of the patent. I No, that part is untrue. I sat at the table with Jeff Schiller and Burt Kaliski when Burt pitched S/MIME at the IETF. He was Chief Scientist of RSA Labs at the time. Jim did go after Phil Z. over PGP initially. But Phil Z. was violating the patent at the time. That led to RSAREF and the MIT version of PGP. DNSSEC was (and is) a mess as a standard because it is an attempt to retrofit a directory designed around some very tight network constraints and with a very poor architecture to make it into a PKI. PS: My long-standing domain registrar (enom.com) STILL doesn't support DNSSEC records -- which is why toad.com doesn't have DNSSEC protection. Can anybody recommend a good, cheap, reliable domain registrar who DOES update their software to support standards from ten years ago? The Registrars are pure marketing operations. Other than GoDaddy which implemented DNSSEC because they are trying to sell the business and more tech looks kewl during due diligence, there is not a market demand for DNSSEC. One problem is that the Registrars almost invariably sell DNS registrations at cost or at a loss and make the money up on value added products. In particular SSL certificates. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Trapdoor symmetric key
Two caveats on the commentary about a symmetric key algorithm with a trapdoor being a public key algorithm. 1) The trapdoor need not be a good public key algorithm, it can be flawed in ways that would make it unsuited for use as a public key algorithm. For instance being able to compute the private key from the public or deduce the private key from multiple messages. 2) The trapdoor need not be a perfect decrypt. A trapdoor that reduced the search space for brute force search from 128 bits to 64 or only worked on some messages would be enough leverage for intercept purposes but make it useless as a public key system. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Trapdoor symmetric key
On Sun, Sep 8, 2013 at 12:19 PM, Faré fah...@gmail.com wrote: On Sun, Sep 8, 2013 at 9:42 AM, Phillip Hallam-Baker hal...@gmail.com wrote: Two caveats on the commentary about a symmetric key algorithm with a trapdoor being a public key algorithm. 1) The trapdoor need not be a good public key algorithm, it can be flawed in ways that would make it unsuited for use as a public key algorithm. For instance being able to compute the private key from the public or deduce the private key from multiple messages. Then it's not a symmetric key algorithm with a trapdoor, it's just a broken algorithm. But the compromise may only be visible if you have access to some cryptographic technique which we don't currently have. The point I am making is that a backdoor in a symmetric function need not be a secure public key system, it could be a breakable one. And that is a much wider class of function than public key cryptosystems. There are many approaches that were tried before RSA and ECC were settled on. 2) The trapdoor need not be a perfect decrypt. A trapdoor that reduced the search space for brute force search from 128 bits to 64 or only worked on some messages would be enough leverage for intercept purposes but make it useless as a public key system. I suppose the idea is that by using the same trapdoor algorithm or algorithm family and doubling the key size (e.g. 3DES style), you get a 256-bit symmetric key system that can be broken in 2^128 attempts by someone with the system's private key but 2^256 by someone without. If in your message you then communicate 128 bits of information about your symmetric key, the guy with the private key can easily crack your symmetric key, whereas others just can't. Therefore that's a great public key cryptography system. 2^128 is still beyond the reach of brute force. 2^64 and a 128 bit key which is the one we usually use on the other hand... Perhaps we should do a test, move to 256 bits on a specific date across the net and see if the power consumption rises near the NSA data centers. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Market demands for security (was Re: Opening Discussion: Speculation on BULLRUN)
On Sun, Sep 8, 2013 at 3:08 PM, Perry E. Metzger pe...@piermont.com wrote: On Sun, 8 Sep 2013 08:40:38 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: The Registrars are pure marketing operations. Other than GoDaddy which implemented DNSSEC because they are trying to sell the business and more tech looks kewl during due diligence, there is not a market demand for DNSSEC. Not to discuss this particular case, but I often see claims to the effect that there is no market demand for security. I'd like to note two things about such claims. 1) Although I don't think P H-B is an NSA plant here, I do wonder about how often we've heard that in the last decade from someone trying to reduce security. There is a market demand for security. But it is always item #3 on the list of priorities and the top two get done. I have sold seven figure crypto installations that have remained shelfware. The moral is that we have to find other market reasons to use security. For example simplifying administration of endpoints. I do not argue like some do that there is no market for security so we should give up, I argue that there is little market for something that only provides security and so to sell security we have to attach it to something they want. 2) I doubt that safety is, per se, anything the market demands from cars, food, houses, etc. When people buy such products, they don't spend much time asking so, this house, did you make sure it won't fall down while we're in it and kill my family? or this coffee mug, it doesn't leach arsenic into the coffee does it? People buy guns despite statistics that show that they are orders of magnitude more likely to be shot with the gun themselves rather than by an attacker. However, if you told consumers did you know that food manufacturer X does not test its food for deadly bacteria on the basis that ``there is no market demand for safety'', they would form a lynch mob. Consumers *presume* their smart phones will not leak their bank account data and the like given that there is a banking app for it, just as they *presume* that their toaster will not electrocute them. Yes, but most cases the telco will only buy a fix after they have been burned. To sell DNSSEC we should provide a benefit to the people who need to do the deployment. Problem is that the perceived benefit is to the people going to the site which is different... It is fixable, people just need to understand that the stuff does not sell itself. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Protecting Private Keys
On Sat, Sep 7, 2013 at 10:20 AM, Jeffrey I. Schiller j...@mit.edu wrote: If I was the NSA, I would be scavenging broken hardware from “interesting” venues and purchasing computers for sale in interesting locations. I would be particularly interested in stolen computers, as they have likely not been wiped. +1 And this is why I have been so peeved at the chorus of attack against trustworthy computing. All I have ever really wanted from Trustworthy computing is to be sure that my private keys can't be copied off a server. And private keys should never be in more than one place unless they are either an offline Certificate Signing Key for a PKI system or a decryption key for stored data. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Sat, Sep 7, 2013 at 5:19 AM, ianG i...@iang.org wrote: On 7/09/13 10:15 AM, Gregory Perry wrote: Correct me if I am wrong, but in my humble opinion the original intent of the DNSSEC framework was to provide for cryptographic authenticity of the Domain Name Service, not for confidentiality (although that would have been a bonus). If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. How much more obvious does it get [1] ? Good theory only the CA industry tried very hard to deploy and was prevented from doing so because Randy Bush abused his position as DNSEXT chair to prevent modification of the spec to meet the deployment requirements in .com. DNSSEC would have deployed in 2003 with the DNS ATLAS upgrade had the IETF followed the clear consensus of the DNSEXT working group and approved the OPT-IN proposal. The code was written and ready to deploy. I told the IESG and the IAB that the VeriSign position was no bluff and that if OPT-IN did not get approved there would be no deployment in .com. A business is not going to spend $100million on deployment of a feature that has no proven market demand when the same job can be done for $5 million with only minor changes. CAs do not make their money in the ways you imagine. If there was any business case for DNSSEC I will have no problem at all finding people willing to pay $50-100 to have a CA run their DNSSEC for them because that is going to be a lot cheaper than finding a geek with the skills needed to do the configuration let alone do the work. One reason that PGP has not spread very far is that there is no group that has a commercial interest in marketing it. At the moment revenues from S/MIME are insignificant for all the CAs. Comodo gives away S/MIME certs for free. Its just not worth enough to try to charge for right now. If we can get people using secure email or DNSSEC on a large scale then CAs will figure out how to make money from it. But right now nobody is making a profit from either. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
OK how about this: If a person at Snowden's level in the NSA had any access to information that indicated the existence of any program which involved the successful cryptanalysis of any cipher regarded as 'strong' by this community then the Director of National Intelligence, the Director of the NSA and everyone involved in those decisions should be fired immediately and lose their pensions. What was important in Ultra was the fact that the Germans never discovered they were being intercepted and decrypted. They would have strengthened their cipher immediately if they had known it was broken. So either the NSA has committed an unpardonable act of carelessness (beyond the stupidity of giving 50,000 people like Snowden access to information that should not have been shared beyond 500) or the program involves lower strength ciphers that we would not recommend the use of but are still there in the cipher suites. I keep telling people that you do not make a system more secure by adding the choice of a stronger cipher into the application. You make the system more secure by REMOVING the choice of the weak ciphers. I would bet that there is more than enough DES traffic to be worth attack and probably quite a bit on IDEA as well. There is probably even some 40 and 64 bit crypto in use. Before we assume that the NSA is robbing banks by using an invisibility cloak lets consider the likelihood that they are beating up old ladies and taking their handbags. On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Informed speculation means intelligent, technical ideas about what has been done. It does not mean wild conspiracy theories and the like. I will be instructing the moderators (yes, I have help these days) to ruthlessly prune inappropriate material. At the same time, I will repeat that reasonably informed technical speculation is appropriate, as is any solid information available. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 5, 2013 at 3:58 PM, Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Informed speculation means intelligent, technical ideas about what has been done. It does not mean wild conspiracy theories and the like. I will be instructing the moderators (yes, I have help these days) to ruthlessly prune inappropriate material. At the same time, I will repeat that reasonably informed technical speculation is appropriate, as is any solid information available. http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security • The NSA spends $250m a year on a program which, among other goals, works with technology companies to covertly influence their product designs. I believe this confirms my theory that the NSA has plants in the IETF to discourage moves to strong crypto. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On Thu, Sep 5, 2013 at 4:41 PM, Perry E. Metzger pe...@piermont.com wrote: On Thu, 5 Sep 2013 15:58:04 -0400 Perry E. Metzger pe...@piermont.com wrote: I would like to open the floor to *informed speculation* about BULLRUN. Here are a few guesses from me: 1) I would not be surprised if it turned out that some people working for some vendors have made code and hardware changes at the NSA's behest without the knowledge of their managers or their firm. If I were running such a program, paying off a couple of key people here and there would seem only rational, doubly so if the disclosure of their involvement could be made into a crime by giving them a clearance or some such. Or they contacted the NSA alumni working in the industry. 2) I would not be surprised if some of the slow speed at which improved/fixed hashes, algorithms, protocols, etc. have been adopted might be because of pressure or people who had been paid off. At the very least, anyone whining at a standards meeting from now on that they don't want to implement a security fix because it isn't important to the user experience or adds minuscule delays to an initial connection or whatever should be viewed with enormous suspicion. Whether I am correct or not, such behavior clearly serves the interest of those who would do bad things. I think it is subtler that that. Trying to block a strong cipher is too obvious. Much better to push for something that is overly complicated or too difficult for end users to make use of. * The bizare complexity of IPSEC. * Allowing deployment of DNSSEC to be blocked in 2002 by blocking a technical change that made it possible to deploy in .com. * Proposals to deploy security policy information (always send me data encrypted) have been consistently filibustered by people making nonsensical objections. 3) I would not be surprised if random number generator problems in a variety of equipment and software were not a very obvious target, whether those problems were intentionally added or not. Agreed, the PRNG is the easiest thing to futz with. It would not surprise me if we discovered kleptography at work as well. 4) Choices not to use things like Diffie-Hellman in TLS connections on the basis that it damages user experience and the like should be viewed with enormous suspicion. 5) Choices not to make add-ons available in things like chat clients or mail programs that could be used for cryptography should be viewed with suspicion. I think the thing that discouraged all that was the decision to make end user certificates hard to obtain (still no automatic spec) and expire after a year. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] tamper-evident crypto? (was: BULLRUN)
Sent from my difference engine On Sep 5, 2013, at 9:22 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: John Denker j...@av8n.com writes: To say the same thing the other way, I was always amazed that the Nazis were unable to figure out that their crypto was broken during WWII. There were experiments they could have done, such as sending out a few U-boats under strict radio silence and comparing their longevity to others. Cognitive dissonance. We have been..., sorry Ve haff been reassured zat our cipher is unbreakable, so it must be traitors, bad luck, technical issues, Not necessarily Anyone who raised a suspicion was risking their life. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Three kinds of hash: Two are still under ITAR.
While doing some research on the history of hashing for a client I discovered that it is described in the very first edition of the ACM journal and the paper is a translation of a Russian paper. One of the many problems with the ITAR mindset is the assumption that all real ideas are invented inside the US by white men wearing white lab coats and that the rest of the undeserving world is stealing them. Anyone with any grasp of history recognizes that the industrial scale industrial espionage practiced by China on the industrial powers is merely DIY reparations for the 19th century and the first half of the 20th. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Hashes into Ciphers
On a more theoretical basis, Phil Rogaway gave a presentation at MIT many years ago where he showed the use of a one-way function as the construction primitive for every other type of symmetric algorithm. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Tue, Sep 3, 2013 at 12:49 AM, Jon Callas j...@callas.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 2, 2013, at 3:06 PM, Jack Lloyd ll...@randombit.net wrote: On Mon, Sep 02, 2013 at 03:09:31PM -0400, Jerry Leichter wrote: a) The very reference you give says that to be equivalent to 128 bits symmetric, you'd need a 3072 bit RSA key - but they require a 2048 bit key. And the same reference says that to be equivalent to 256 bits symmetric, you need a 521 bit ECC key - and yet they recommend 384 bits. So, no, even by that page, they are not recommending equivalent key sizes - and in fact the page says just that. Suite B is specified for 128 and 192 bit security levels, with the 192 bit level using ECC-384, SHA-384, and AES-256. So it seems like if there is a hint to be drawn from the Suite B params, it's about AES-192. The real issue is that the P-521 curve has IP against it, so if you want to use freely usable curves, you're stuck with P-256 and P-384 until some more patents expire. That's more of it than 192 bit security. We can hold our noses and use P-384 and AES-256 for a while. Jon What is the state of prior art for the P-384? When was it first published? Given that RIM is trying to sell itself right now and the patents are the only asset worth having, I don't have good feelings on this. Well apart from the business opportunities for expert witnesses specializing in crypto. The problem is that to make the market move we need everyone to decide to go in the same direction. So even though my employer can afford a license, there is no commercial value to that license unless everyone else has access. Do we have an ECC curve that is (1) secure and (2) has a written description prior to 1 Sept 1993? Due to submarine patent potential, even that is not necessarily enough but it would be a start. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
Want to collaborate on an Internet Draft? This is obviously useful but it can only be made useful if everyone does it in the same way. On Tue, Sep 3, 2013 at 10:14 AM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: Phillip Hallam-Baker hal...@gmail.com writes: To backup the key we tell the device to print out the escrow data on paper. Let us imagine that there there is a single sheet of paper which is cut into six parts as follows: You read my mind :-). I suggested more or less this to a commercial provider a month or so back when they were trying to solve the same problem. Specifically it was if you lose your key/password/whatever, you can't call the helpdesk to get your data back, it's really gone, which was causing them significant headaches because users just weren't expecting this sort of thing. My suggestion was to generate a web page in printable format with the key shares in standard software-serial-number form (X-X-X etc) and tell people to keep one part at home and one at work, or something similar, and to treat it like they'd treat their passport or insurance documentation. Peter. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Backup is completely separate
On Mon, Sep 2, 2013 at 11:03 PM, John Kelsey crypto@gmail.com wrote: The backup access problem isn't just a crypto problem, it's a social/legal problem. There ultimately needs to be some outside mechanism for using social or legal means to ensure that, say, my kids can get access to at least some of my encrypted files after I drop dead or land in the hospital in a coma. Or that I can somehow convince someone that it's really me and I'd like access to the safe deposit box whose password I forgot and lost my backup copy of. Or whatever. This is complicated by the certainty that if someone has the power to get access to my encrypted data, they will inevitably be forced to do so by courts or national security letters, and will also be subject to extralegal pressures or attacks to make them turn over some keys. I suspect the best that can be workably done now is to make any key escrow service's key accesses transparent and impossible to hide from the owner of the key, and then let users decide what should and shoudn't be escrowed. But this isn't all that great an answer. To avoid mandated/coerced release substitute 'keep at bank' with 'bury at undisclosed location'. There is really no 100% reliable way to make things available to your heirs while avoiding government coercion. Particularly since the government issues the documents saying that you are dead. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
On Sun, Sep 1, 2013 at 10:35 PM, James A. Donald jam...@echeque.com wrote: On 2013-09-01 9:11 PM, Jerry Leichter wrote: Meanwhile, on the authentication side, Stuxnet provided evidence that the secret community *does* have capabilities (to conduct a collision attacks) beyond those known to the public - capabilities sufficient to produce fake Windows updates. Do we know they produced fake windows updates without assistance from Microsoft? Given the reaction from Microsoft, yes. The Microsoft public affairs people have been demonstrating real anger at the Flame attack in many forums. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
You know, if there was a completely ironclad legal opinion that made use of ECC possible without the risk of a lawsuit costing over $2 million from Certicom then I would be happy to endorse a switch to ECC like the NSA is pushing for as well. I would not therefore draw the conclusion that NSA advice to move to ECC is motivated by knowledge of a crack of RSA, if anything that would argue against moving from ECC. It is merely a consequence of the US government having a license which we don't have. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Separating concerns
On Thu, Aug 29, 2013 at 7:15 AM, Jerry Leichter leich...@lrw.com wrote: On Aug 28, 2013, at 2:04 PM, Faré wrote: My target audience, like Perry's is people who simply can't cope with anything more complex than an email address. For me secure mail has to look feel and smell exactly the same as current mail. The only difference being that sometime the secure mailer will say 'I can't contact that person securely right now because…' I agree with Perry and Phill that email experience should be essentially undisturbed in the normal case, though it's OK to add an additional authorization step. One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? I'm no ignoramus, yet I have, several times, lost data I cared about due to hardware failure or theft combined with improper backup. How is a total newbie to do? This is a broader problem, actually. If you've ever had to take care of someone's estate, you'll know that one of the problems is contacting all the banks, other financial institutions, service providers, and other such parties they dealt with in life. My experience dealing with my father's estate - a fairly simple one - was that having the *paper* statements was the essential starting point. (Even so, finding his safe deposit box - I had the unlabeled keys - could have been a real pain if my sister didn't remember which bank it was at.) Had he been getting email statements, just finding his mail accounts - and getting access to them - could have been a major undertaking. Which is one reason I refuse to sign up for email statements ... just send me the paper, thank you. (This is getting harder all the time. I expect to start getting charged for paper statements any time now.) Today at least, my executor, in principle, work with the mail provider to get access. But for truly secure mail, my keys presumably die with me, and it's all gone. You don't even have to consider the ultimate loss situation. If I'm temporarily disabled and can't provide my keys - how can someone take care of my bills for me? We can't design a system that can handle every variation and eventuality, but if we're going to design one that we intend to be broadly used, we have to include a way to handle the perfectly predictable, if unpleasant to think about, aspects of day to day life. Absolute security *creates* new problems as it solves old ones. There may well be aspects to my life I *don't* want revealed after I'm gone. But there are many things I *do* want to be easily revealed; my heirs will have enough to do to clean up after me and move on as it is. So, yes, we have to make sure we have backup mechanisms - as well as key escrow systems, much as the term key escrow was tainted by the Clipper experience. Systems do need to be usable in practice and too much security can be a bad thing. I am thinking about 'PRISM Proof' as a hierarchy of needs: 0 No confidentiality requirement 1 Content Confidentiality Passive intercept (met by STARTTLS) 2 Content Confidentiality Active Intercept (met by STARTTLS + validated recipient server cert) 3 Content Confidentiality Coercion or compromise of Mail service provider 4 Content Confidentiality Coercion or compromise of Trusted Third Party 5 MetaData Confidentiality 6 Traffic Analysis Confidentiality At present we only have a widely deployed solution for level 1. The constituency that has a requirement for level 6 is probably very small. Certainly none of us would benefit. Is is a hard goal or a stretch goal? It is certainly a desirable goal for people like journalists but the cost of meeting the requirement may not be acceptable. At any rate, I think that starting by trying to build something to level 4 would be a good start and provide an essential basis for getting through to levels 5 and 6. It might be that to get from level 4 to level 6 the solution is as simple as 'use a German ISP'. Since we are talking about Snowden and Greenwald, folk might be amused to learn that I was the other party who contacted Baghdad Boylen, General Pertreaus's spokesperson who sent Greenwald a bizarre email which he then lied about having sent (to me, Greenwald and Petreaus), apparently unaware that while an email message can indeed be faked, it is improbable that these particular message headers are faked. Further, had any such attempted impersonation of Boylan taken place it would have been a very serious matter requiring urgent investigation. Since I was never contacted it is clear that no investigation took place which can only mean that Boylen did send the emails and then lied about sending them. http://www.salon.com/2007/10/28/boylan/ If a UK military officer had sent a similar email he would be cashiered. But then again, in the British army Colonels are not minted by the thousand as in the US. --
Re: [Cryptography] IPv6 and IPSEC
On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote: On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? It is a stupid and incorrect requirement. The DNS has always allowed multiple A records to point to the same IP address. In the general case a mail server will support hundreds, possibly tens of thousands of receiving domains. A PTR record can only point to one domain. The reason that an MX record has a domain name as the target rather than an IP address is to facilitate administration. Forcing the PTR and record to match means that there has to be a one to one mapping and thus defeats many commonly used load balancing strategies. Google is attempting to impose a criteria that is simply wrong. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On Thu, Aug 29, 2013 at 1:30 PM, Perry E. Metzger pe...@piermont.comwrote: On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote: One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. Inevitably this means that said backups are going to either be protected by a fairly weak password or that the user is going to have to print the key out and put it in their desk drawer and risk having it lost or stolen or destroyed in a fire. I think I can live with either problem. Right now, most people have very little protection at all. I think making the perfect the enemy of the good is a mistake. If doing bad things to me requires breaking in to my individual home, that's fine. If it is merely much less likely that I lose my data rather than certain that I have no backup at all, that's fine. BTW, automation *does* do a good job of making such things invisible. I haven't lost any real data since I started using Time Machine from Apple, and I have non-technical friends who use it and are totally happy with the results. I wish there was an automated thing in Time Machine to let me trade backups with an offsite friend as well. Now this is an area where QR codes might be useful First point of simplification is that we only ever need to worry about symmetric key backup since we can always add a private key to the rest of our encrypted archive. We can encrypt the key and backup the encryption key or we can use a deterministic keygen algorithm and escrow the seed. either way we only need to escrow 256 bits. Second point is that we can reduce exposure to risk by using some sort of key splitting scheme. We can also use this to effect key transport between devices. The problem with 'end to end' encryption these days is that most of us have multiple devices we receive email on, which is why WebMail has become so attractive. I have to be able to read my email on any of my 5 principal machines (Windows, 2 MacBooks, iPhone, iPad). Any email scheme that does not support all of them is useless. Third point of simplification: ditch key rollover. Don't expire a key unless it is necessary because of a suspected or known compromise. Use a sufficiently strong key to make cryptanalysis infeasible. I know that key rollover is part of the ideology but it introduces more vulnerability than it eliminates. Any encryption key you have that ends up compromised is likely a maximum damage situation. So using ten keys in ten years gives the attacker ten opportunities to compromise you if you muck up the distribution or they manage to compromise a CA. Fourth point of simplification: Just duplicate the key into every end point rather than attempting a key service with split control and key shares. A better way to manage crypto in a mobile device like a phone would be to split the prime into two (or more parts) for each mobile device to be enabled. To decrypt data the device would have to ask a service(s) with the other part(s) of the key to do their work and then combine with the local result. So lets imagine the full key establishment sequence from the user's point of view. Key Generation. To generate my first key, I tell my MUA my email address and the CA domain name[1]. It checks to see if the email address already has a key registered. If so it will ask if I am really, really sure I want to replace it etc. Otherwise it generates for me a new keypair. The CA is hopefully going to do validation of my key before issuing the certificate. At minimum an email callback. We might push the encrypted escrowed key out to the CA at the same time. But that is orthogonal to the private key backup and distribution. To backup the key we tell the device to print out the escrow data on paper. Let us imagine that there there is a single sheet of paper which is cut into six parts as follows: 1) Three copies of the encrypted private key, either as raw data or a link to the raw data. 2) Three key shares allowing the key to be reconstructed from 2 of them. For a 256 bit key that would be no more than 512 bits doing it the simple way and there is probably a cleverer encoding. The data for each would be presented as both a QR code (for installing in a phone) and a BASE32 alphanumeric code (for installing on a machine without a camera. The user can easily escrow the keys by cutting the paper into 3 parts and storing them in an acceptably safe location. In my case that would probably mean mailing the shares to my parents and family for offsite backup. Or I might give them to my broker or a bank or... Banks are quite possibly going to be interested in helping this type of scheme because it helps them
Re: [Cryptography] IPv6 and IPSEC
On Thu, Aug 29, 2013 at 4:53 PM, Taral tar...@gmail.com wrote: Oh, wait. I misread the requirement. This is a pretty normal requirement -- your reverse DNS has to be valid. So if you are 3ffe::2, and that reverses to abc.example.com, then abc.example.com better resolve to 3ffe::2. On Thu, Aug 29, 2013 at 1:38 PM, Phillip Hallam-Baker hal...@gmail.com wrote: On Thu, Aug 29, 2013 at 1:59 PM, Taral tar...@gmail.com wrote: On Wed, Aug 28, 2013 at 12:08 PM, Lucky Green shamr...@cypherpunks.to wrote: Additional guidelines for IPv6 The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected. Because under ipv6 your prefix is supposed to be stable (customer identifier) and the namespace delegated to you on request. Have you asked your provider for an ipv6 namespace delegation? It is a stupid and incorrect requirement. The DNS has always allowed multiple A records to point to the same IP address. In the general case a mail server will support hundreds, possibly tens of thousands of receiving domains. A PTR record can only point to one domain. The reason that an MX record has a domain name as the target rather than an IP address is to facilitate administration. Forcing the PTR and record to match means that there has to be a one to one mapping and thus defeats many commonly used load balancing strategies. Google is attempting to impose a criteria that is simply wrong. So Lucky's problem seems to be that the ISPs providing IPv6 have decided on a convention that they identify residential IPv6 ranges by not filling in the reverse PTR info And the problem he has is that Google won't take email from a residential IPv6. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] The Case for Formal Verification
On Thu, Aug 29, 2013 at 4:46 PM, Perry E. Metzger pe...@piermont.comwrote: Taking a break from our discussion of new privacy enhancing protocols, I thought I'd share something I've been mumbling about in various private groups for a while. This is almost 100% on the security side of things, and almost 0% on the cryptography side of things. It is long, but I promise that I think it is interesting to people doing security work. Whitt Diffie was meant to be working on formal methods when he came up with public key crypto... My D.Phil Thesis was on applying formal methods to a large, non trivial real time system (raw input bandwidth was 6Tb/sec, the immediate fore-runner to the LHC data acquisition scheme). My college tutor was Tony Hoare but I was in the nuclear physics dept because they had the money to build the machine. The problemI saw with formal methods was that the skills required were already at the limit of what Oxford University grad students were capable of and building systems large enough to matter looked like it would take tools like category theory which are even more demanding. The code synthesis scheme I developed was an attempt to address the scaling problem from the other end. The idea being that to build a large system you create a very specific programming language that is targeted at precisely that class of problems. Then you write a back end that converts the specification into code for that very restricted domain. If you want a formal proof you have the synthesizer generate it from the specification as well. That approach finesses the problem of having to validate the synthesizer (which would likely take category theory) because only the final target code need be validated. That is the code I re-implemented in C after leaving VeriSign and released onto SourceForge earlier this year and the tool I used to build the JSON Schema tool. I would probably have released it earlier only I met this guy at CERN who had some crazy idea about hypertext. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Thu, Aug 29, 2013 at 3:31 PM, Callme Whatiwant nejuc...@gmail.comwrote: Hello, I'm new here, so I apologize if I'm repeating past arguments or asking old questions. On Tue, Aug 27, 2013 at 8:52 PM, Jerry Leichter leich...@lrw.com wrote: On Aug 27, 2013, at 9:48 PM, Perry E. Metzger wrote: On Tue, 27 Aug 2013 22:04:22 +0100 Wendy M. Grossman wen...@pelicancrossing.net wrote: On 08/27/2013 18:34, ianG wrote: Why do we need the 1980s assumption of being able to send freely to everyone, anyway? It's clear you're not a journalist or working in any other profession where you actually need to be able to communicate spontaneously with strangers. Of course, as a reporter, you are probably getting email addresses of people to talk to via referral, and that could be used to get past the barrier. The problem of people spontaneously contacting a published address is harder. Actually, it isn't, or shouldn't be. Email addresses were originally things you typed into a terminal. They had to be short, memorable, and easy to type. Published meant printed on paper, which implied typing the thing back in. But none of that matters much any more. This is (anecdotally) completely untrue. A great way to experience this personally is to start using a strange email address, like mine. You quickly realize how often you *say* or *write on paper* your email address. Because my email address is odd, almost every time I say it, the listener asks me to spell it. I suspect if I could just say bob at gmail I wouldn't notice how often this occurs. I have enough problems with mine. hal...@gmail.com, someone else registered hal...@gmail.com. But more generally, I want to make it easy for people to send me email. If they already have my address then it does not matter how easy it would be to add an encryption key, the opportunity to do so has passed. What I did realize would be useful is some sort of verification code. So this morning I was arranging a delivery of a screw for the shower. I give them the email address but they were going to do hallambaker@gmail.cominstead. So it would be nice if there was a code that someone could read back to tell you that they got the address right. It does not need to be particularly long, two maybe three letters. Just enough to provide a confirmation. And extending the concept. Let us imagine that I have a separate email address that I am only going to use for online purchases and that I have filled out a delivery address form somewhere for it and that agent will only give out the address to a party that presents an EV certificate to show that they are accountable and keep a record of everyone who asks. This does not really raise particular confidentiality concerns to me because it is simply a form of compression. My delivery addresses appear many times in my email inbox, I have a new entry every time I buy something online. If the mails travel through my ISP's server they will get that info soon enough (unless the sender encrypts). But it would make filling in online forms a lot easier and less error prone. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Source for protocol compiler
The source is up on sourceforge now. It does need some spring cleaning and documenting which I hope to get to next week. The documentation is in the following directory https://sourceforge.net/p/jsonschema/code/ci/master/tree/Web/ The origins of this work is that about 70% of the effort in working groups goes into debating 'bikeshed' type issues (as in what color to paint it) that really don't matter. Things like choice of encoding (just use JSON) or binding (Any reason to not use HTTP + SSL) and so on. And 70% of the effort of the editor would go into making changes to the spec which would need to be reflected accurately in six different parts of the document and the reference code and then conformant examples generated and inserted at the right place and then other folk would have to check it was all done right. So JSONSchema converts an abstract schema definition (in a programming language syntax, not JSON encoding!) and produces a stub client API and a stub server with the appropriate holes to plug in your semantics. You can then write documentation and insert examples from running code (provided you like documentation in either HTML or Internet Draft format at the moment). It is all written in C# and has been run on OSX and Linux under Mono (binary distributions to follow). The synth currently only generates code in C# but I plan to add C and probably Objective C down the line. The meta-synthesiser is also on sourceforge and open source: https://sourceforge.net/projects/goedel/ The compiler only supports RPC like interactions at the moment, i.e. query/response. But I am planning to expand the generator to support an additional interaction pattern in which the client opens a transaction and receives a series of async callbacks. That would be suited to supporting chat like protocols. One of the things I realized as I was doing all this is that all Web Services really consist of are glorified RPC calls in a different syntax. The code generated right now is targeted at being reference code but there is no reason why the synth should not generate production code. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Tue, Aug 27, 2013 at 5:04 PM, Wendy M. Grossman wen...@pelicancrossing.net wrote: On 08/27/2013 18:34, ianG wrote: Why do we need the 1980s assumption of being able to send freely to everyone, anyway? It's clear you're not a journalist or working in any other profession where you actually need to be able to communicate spontaneously with strangers. True, but you are probably willing to tolerate a higher level of spam getting through in that case. One hypothesis that I would like to throw out is that there is no point in accepting encrypted email from someone who does not have a key to encrypt the response. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Tue, Aug 27, 2013 at 10:18 PM, Perry E. Metzger pe...@piermont.comwrote: On Tue, 27 Aug 2013 19:57:30 -0600 Peter Saint-Andre stpe...@stpeter.im wrote: On 8/27/13 7:47 PM, Jonathan Thornburg wrote: On Tue, 27 Aug 2013, Perry E. Metzger wrote: Say that you want to distribute a database table consisting of human readable IDs, cryptographic keys and network endpoints for some reason. Say you want it to scale to hundreds of millions of users. This sounds remarkably like a description of DNSSEC. Assuming it were widely deployed, would DNSSEC-for-key-distribution be a reasonable way to store email_address -- public_key mappings? You mean something like this (email address -- OTR key)? https://datatracker.ietf.org/doc/draft-wouters-dane-otrfp/ My problem with the use of DNSSEC for such things is the barrier to entry. It requires that a systems administrator for the domain your email address is in cooperate with you. This has even slowed DNSSEC deployment itself. How about the fact that the US govt de facto controls the organization controlling the root key and it is a single rooted hierarchy of trust? But in general, the DNS is an infrastructure for making assertions about hosts and services. It is not a good place for assertions about users or accounts. So it is a good place to dump DANE records for your STARTTLS certs but not for S/MIME certs. It is, of course, clearly the correct way to do such things, but trying to do things architecturally correctly sometimes results in solutions that don't deploy. I prefer solutions that require little or no buy in from anyone other than yourself. One reason SSH deployed so quickly was it needed no infrastructure -- if you controlled a single server, you could log in to it with SSH and no one needed to give you permission. This is a guiding principle in the architectures I'm now considering. I very much agree that deployment is all. One thing I would like to do is to separate the email client from the crypto decision making even if this is just a temporary measure for testbed purposes. I don't want to hack plugs into a dozen email clients for a dozen experiments and have to re-hack them for every architectural tweak. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Sun, Aug 25, 2013 at 7:42 PM, Christian Huitema huit...@huitema.netwrote: My knowledge of the field is pretty spotty in general as I've never paid much attention up until now -- mostly I know about how people have built DHTs in non-hostile environments. I'm close enough to starting from scratch that I don't know yet what I don't know. I studied such systems intensely, and designed some (http://en.wikipedia.org/wiki/Peer_Name_Resolution_Protocol). Using a distributed hash table securely is really hard. The basic idea of DHT is that information is spread on the network based on matches between the hash of a resource identifier and the hash of a node identifier. All nodes are effectively relying on every other node. In an open network, that is pretty much equivalent to relying on the goodness of strangers. You can be sure that if our buddies at the NSA set up to watch the content of a DHT, they will succeed. I am doing a history of the Web. I came to the conclusion that the clever part is the problems it decides not to solve. Ted Nelson was absolutely right on what was desirable, but what he considered 'essential' turned out to be easily added as layers (search for example). A confidentiality solution that tells the user 'you can't send mail right now because you may be subject to an intercept' is more than acceptable. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Using Raspberry Pis
I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. However that said, the pros are: * Small, cheap, reasonably fast, has ethernet and even a monitor output * Boot from an SD card which can be preloaded with the OS and application build. So it is really easy to use RPi as an embedded device controller. The main con is that they are not so fast that you want to be routing packets through them unnecessarily. So they are a great device to make use of for connection brokering, not such a great idea to tunnel video packets through them. It is entirely reasonable to tell someone to get an RPi, download a config onto an SD card, plug it into their network and apply power and ethernet. And they take so little power that we could even tell them to install a pair so that they had a fault tolerant setup (although they are low enough power, low enough complexity that this may not be necessary or helpful). In the home of the future there will be hundreds of devices on the network rather than just the dozens I have today. So trying to configure security at every point is a non starter. Peer to peer network configurations tend to end up being unnecessarily chatty and are hard to debug because you can't tell who is meant to be in command. The approach that makes most sense to me is to have one or two network controller devices built on something like RPis and vest all the trust decisions in those. So rather than trying to configure PKI at hundreds of devices, concentrate those decisions in just one logical point. So I would like at minimum such a device to be my DNS + DHCP + PKI + NTP configuration service and talk a consistent API to the rest of the network. Which is the work I am doing on Omnibroker. Putting a mail server on the system as well would be logical, though it would increase complexity and more moving parts on a trusted system makes me a little nervous. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Using Raspberry Pis
On Mon, Aug 26, 2013 at 5:43 PM, Perry E. Metzger pe...@piermont.comwrote: On Mon, 26 Aug 2013 16:12:22 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: I really like RPis as a cryptographic tool. The only thing that would make them better is a second Ethernet interface so they could be used as a firewall type device. You can of course use a USB ethernet with them, but to me, they're more a proof of what you can do with a very small bill of materials. If you're designing your own, adding another ethernet (and getting rid of unneeded things like the video adapter) is easy. Custom built hardware will probably be the smartest way to go for an entrepreneur trying to sell these in bulk to people as home gateways anyway -- you want the nice injection molded case, blinkylights and package as well. :) I don't think the video adds much to the cost. I do have a USB ethernet adapter... but that cost me as much as the Pi. Problem with all these things is that the Pi is cheap because they have the volume. Change the spec and the price shoots up :( -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Traffic Analysis (was Re: PRISM PROOF Email)
There has to be a layered approach. Traffic analysis is probably going to demand steganography and that is almost by definition outside standards work. The part of Prism that I consider to be blatantly unconstitutional is that they keep all the emails so that they can search them years later should the need arise. Strikes me that is the type of sophistry that John Yoo used when he wrote those memos claiming that torture isn't torture. There will be a reckoning in the end. Takes about twenty to thirty years before the point is reached that nobody in the establishment has a reason to protect the war criminals of years past. I have a little theory about the reason the CIA engineered coups were so successful from 53 to 73 and then suddenly stopped working. Seems to me that the CIA would have been nuts to try operation Ajax without some very powerful intel like being able to break the Persian codes. CIa stopped being able to mount those exercises after electronic ciphers were introduced. Given how the NSA used their powers last time round to topple democracies and install dictators I don't think they deserve a second chance. On Sun, Aug 25, 2013 at 3:34 PM, Perry E. Metzger pe...@piermont.comwrote: On Fri, 23 Aug 2013 09:38:21 -0700 Carl Ellison c...@acm.org wrote: Meanwhile PRISM was more about metadata than content, right? How are we going to prevent traffic analysis worldwide? The best technology for that is mix networks. At one point, early in the cypherpunks era, mix networks were something of an expensive idea. Now, however, everyone in sight is connected 24x7 to the internet. Similarly, at one point, bandwidthwas scarce, but now, most traffic is video, and even if instant messages and email equivalents took many hops through the network, the bandwidth used (except for mobiles, which need not be interior mix nodes per se) is negligible. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What is the state of patents on elliptic curve cryptography?
On Thu, Aug 22, 2013 at 1:20 AM, Daira Hopwood da...@jacaranda.org wrote: On 20/08/13 19:26, Phillip Hallam-Baker wrote: It is almost certain that most uses of EC would not infringe the remaining patents. But the patent holder can force anyone attempting to use them to spend about $3-5 million to defend their right to use EC and so there is very little incentive to do so given that RSA 2048 is sufficient for almost any need. In principle there's no way to be sure of anything being free from patents, so why treat EC as a special case? Seems like you're just doing Certicom's FUD-spreading for them :-( Given that I am an expert witness specialising in finding prior art for patent defences, my original post was a statement against interest as I would be in with a good shot of getting a $100K gig if someone did decided to test patentability of EC. There is no way to be sure that anything is free of patents, but in this case we are pretty sure that there will be a suit. This is not an exception to the usual approach either, quite a few of my design proposals in IETF have been shot down as 'too clever', i.e. someone might have filed a patent. What worries me on the Certicom patents is whether the 20 year from filing or 17 years from issue applies since they are continuations in part on a filing made prior to 7 June 1995. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On Fri, Aug 23, 2013 at 6:02 PM, Philip Whitehouse phi...@whiuk.com wrote: Let me just see if I get where you're going: So essentially you've increased the number of CAs to the number of companies without really solving the PRISM problem. The sheer number mean it's impractical to do much more than a cursory check before approval. The number of CAs would not need to be very large, I would expect it to be in the hundreds in a global system but that is pretty much a function of their being hundreds of countries. If example.com wanted to run their own CA for their own email certs then the way to do it would be to issue them a cert signing cert that has name constraints to limit its use to just n...@example.com. The idea is that there are multiple CAs but their actions are all vetted for transparency and they all check up on each other. Any one CA can be served with an NSL, but if they issue a coerced certificate it will be immediately visible to the target. So a government can perform a DoS attack but not get away with an impersonation attack. PRISM for email is bad because we don't even know who we can trust. I can't trust the provider because they could have been served an NSL. The provider has to see the metadata or they can't route the email. So I'm doomed. Best case is I can secure the contents and use an alternate name. At that point I need an organization I trust to act as my Omnibroker who for some reason I don't trust with the mail itself. One other question: PPE = Prism Proof Email? Nor do I think key chain length was the problem - initial key authentication and distribution is the first issue. Philip Whitehouse Well the way that was solved in practice for PGP was Brian LaMachia's PGP Key server :-) Which turned into a node of very high degree... -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On Fri, Aug 23, 2013 at 6:42 PM, Joe St Sauver j...@oregon.uoregon.eduwrote: I wouldn't take Snowden's alleged opsec practice, or lack thereof, as a demonstration proof that PGP and/or S/MIME are impossibly difficult for technical people (or even motivated NON-technical people) to use when necessary or appropriate. Thats what the IETF folk told us when I worked on HTTP 0.9 against Gopher and FTP. Usability matters. In fact it is all that matters for adoption. Angry Birds has made a billion dollars because it is so nice to use that people will pay to use it. -- most email clients only integrate support for S/MIME; if you want to try to push anything else, your mission effectively devolves to advocating for native support for PGP in popular email clients (such as Thunderbird and Outlook), but when you do so, be prepared for pushback. Yep, I see no particular value in pushing PGP over S/MIME. Other than the fact that it has mind share. -- PRISM-proofing isn't just about encryption, since traffic analysis doesn't require full contents (and in fact, arguably, encryption ENHANCES traffic analysis in some ways, depending on how it ends up being used). Thats why message layer security is not a substitute for TLS. And the TLS should be locked to the email service via a policy statement such as DANE. #Everything has to be transparent to the #end user who is not a crypto expert and may well be a bit of a doof. You simply cannot produce doof-proof message-level crypto (I'd be surprised if there isn't already a CafePress tee shirt with this meme, in fact), any more than you can keep doofs from driving their cars into other vehicles, etc. I disagree. I think it is entirely tractable. If I understand your architecture correctly, it isn't end-to-end, is it? If it isn't end-to-end, that just means that the attack point shifts, it doesn't get eliminated. Depends on what you call the ends. The messages are encrypted email client to email client. But the trust relationships run from the CA to the Omnibroker. If you want to have full control then you would run your own omnibroker and configure it with the appropriate policy. If you are worried about foreign governments intercepting your email but not your own then a Symantec or Comodo provided Omnibroker service would be acceptable. People who trust us sufficiently to run our anti-virus are already trusting us to a far greater degree. And remember, end-to-end encryption isn't free. You may be reducing the risk of message eavesdropping, but the tradeoff may be that malicious content doesn't get scanned and blocked prior to delivery, just to mention one potential concern. (And of course, if your endpoint gets 0wn3d, your privacy expectations shouldn't be very high, right?) Which is one reason people would run their own omnibroker in certain situations (like enterprise) and encrypted mail is likely to be subject to policy controls (no executables) and only accepted from known parties with established reputations. #For spam control reasons, every email sent has to be authenticated which #means using digital signatures on the message (and likely DKIM + SSL client #auth). Auth doesn't prevent spam. Auth just enables the accumulation of reputation, which can then drive filtering decisions. Which is what most spam filtering works of these days, content filtering is not a very successful anti-spam strategy. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM PROOF Email
On Fri, Aug 23, 2013 at 3:34 PM, Ben Laurie b...@links.org wrote: On 22 August 2013 10:36, Phillip Hallam-Baker hal...@gmail.com wrote: Preventing key substitution will require a combination of the CT ideas proposed by Ben Laurie (so catenate proof notaries etc) and some form of 'no key exists' demonstration. We have already outline how to make verifiable maps as well as verifiable logs, which I think is all you need. http://www.links.org/files/RevocationTransparency.pdf. Yeah, I think it is just a matter of being clear about the requirements and making sure that we fully justify the requirements for email rather than assume that email is the same. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] What is the state of patents on elliptic curve cryptography?
It is almost certain that most uses of EC would not infringe the remaining patents. But the patent holder can force anyone attempting to use them to spend about $3-5 million to defend their right to use EC and so there is very little incentive to do so given that RSA 2048 is sufficient for almost any need. The situation might change depending on who buys RIM. On Tue, Aug 20, 2013 at 1:38 PM, Perry E. Metzger pe...@piermont.comwrote: What is the current state of patents on elliptic curve cryptosystems? (It would also be useful to know when the patents on such patents as exist end.) Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Snowden fabricated digital keys to get access to NSA servers?
I think that fabricating a key here is more likely to mean fabricating an authentication 'key' rather than an encryption key. Alexander is talking to Congress and is deliberately being less than precise. So I would think in terms of application level vulnerabilities in Web based document servers. One of the things that I have thought weak in our current approach to use of crypto is the way that we divide up access control into authentication and authorization. So basically if Bradley had a possible need to see a file then he has an authorization letting him see it. Using access control alone encourages permissions to be given out promiscuously. The Snowden situation sounds like something slightly different. Alexander says he was not authorized but he was able to get access. The common way that happens on the Web is that Alice has account number 1234 and authenticates herself to the server and gets back a URI ending something like ?acct=1234 To get access to Bob's account she simply changes that to ?acct=1235... It should not work, but it works very often in the real world. Having worked with contractors I have seen people hired out as 'programers' at $1500 per day whose only coding experience was hacking Dephi databases. No C, C++, Java or C#. Not even a scripting language. So it would not shock me to find out that their document security comes undone in the same way that it does in commercial systems. Heads should be rolling on this one. But they won't. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Snowden fabricated digital keys to get access to NSA servers?
I read an article today that claims one and a half million people have a Top Secret clearance. That kind of demonstrates how little Top Secret now means. On Sun, Jun 30, 2013 at 2:16 PM, Florian Weimer f...@deneb.enyo.de wrote: * John Gilmore: [John here. Let's try some speculation about what this phrase, fabricating digital keys, might mean.] Most likely, as part of his job at the contractor, he had administrator access to a system which was used for key management, perhaps to apply security updates, manage backups or fix the occasional glitch. This is precisely the kind of low-level grunt work that I expect is outsourced to contractors. It's also possible that he was directly charged with key management. I can image that someone thought that as long as some agency committee made the actual decisions, it was fine to hire an external data typist who entered the committee decision in to the key management system. It's really funny that NSA-level security has now turned pejorative. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
