Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 9:41 AM, Mark Atwood m...@mark.atwood.name wrote: Well, there are Protobufs, and there is Thrift, and there is MessagePack, and there is Avro... Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Mon, Sep 30, 2013 at 06:35:24PM -0400, John Kelsey wrote: Having read the mail you linked to, it doesn't say the curves weren't generated according to the claimed procedure. Instead, it repeats Dan Bernstein's comment that the seed looks random, and that this would have allowed NSA to generate lots of curves till they found a bad one. That is itself a problem, the curves are in fact, not fully veriably fairly chosen. Our current inability to design a plausible mechanism by which this could have been done is not proof that it was not done. Also bear in mind unlike the NSA the crypto community has focused more on good faith (how to make thing secure) and less on bad faith (how to make things trapdoor insecure while providing somewhat plausible evidence that no sabotage took place). Ie we didnt spend as much effort examining that problem. Now that we have a reason to examine it, maybe such methods can be found. Kleptography is a for the open community a less explored field of study. Conversely it would have been easy to prove that the curve parameters WERE fairly chosen as Greg Maxwell described his surprise that the seed was big and random looking: Considering the stated purpose I would have expected the seed to be some small value like … “6F” and for all smaller values to fail the test. Anything else would have suggested that they tested a large number of values, and thus the parameters could embody any undisclosed mathematical characteristic whos rareness is only bounded by how many times they could run sha1 and test. So the question is rather why on earth if they claim good faith, did they not do that? Another plausible explanation that Greg mentions also, is that perhaps it was more about protecting the then secrecy of knowledge. eg weak curves and avoiding them without admitting the rules for which curves the knew were weak. Clearly its easier to weaken a system in symmetric way that depends only on analysis (ie when someone else figures out the class of weak curves they gain the advantage also, if its public then everyone suffers), vs a true trapdoor weakening, as in the EC DRBG fiasco. So if that is their excuse, that the utility of NSA input one can get due to institutional mentality of secrecy, is hardening but with undisclosed rationale, I think we'd sooner forgoe their input and have fully open verifiable reasoning. Eg maybe they could still prove good faith if they chose to disclose their logic (which may now be public information anyway) and the actual seed and the algorithm that rejected all iterations below the used value. However that depends on the real algorithm - maybe there is no way to prove it, if the real seed was itself random. But I do think it is a very interesting and pressing research question as to whether there are ways to plausibly deniably symmetrically weaken or even trapdoor weaken DL curve parameters, when the seeds are allowed to look random as the DSA FIPS 186-3 ones do. Adam ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Found at: http://www.nytimes.com/2007/02/05/technology/05secure.html?ex=1328331600en=295ec5d0994b0755ei=5090partner=rssuserlandemc=rss To quote from the above: The idea is that if customers do not see their [preselected] image, they could be at a fraudulent Web site, dummied up to look like their bank’s, and should not enter their passwords. The Harvard and M.I.T. researchers tested that hypothesis. In October, they brought 67 Bank of America customers in the Boston area into a controlled environment and asked them to conduct routine online banking activities, like looking up account balances. But the researchers had secretly withdrawn the images. Of 60 participants who got that far into the study and whose results could be verified, 58 entered passwords anyway. Only two chose not to log on, citing security concerns. This approach requires the customer to verify the image every log on. Conning them by replacing the image with, Site undergoing maintenance[1] is fairly easy. With my approach, I would authenticate the bank's key once, when I establish an account or sign up for online banking. My software would check that authentication every time I log on after that. (If the bank decides to change it's key every year, I might need a new piece of paper every year -- which might get old after a few years.) and http://en.wikipedia.org/wiki/Phishing#cite_note-88 which say simple things like show the right image don't work. Found at: http://web.archive.org/web/20080406062154/http://people.seas.harvard.edu/~rachna/papers/emperor-security-indicators-bank-sitekey-phishing-study.pdf It's also worth pointing out that common browser ad blocking / script blocking / and site redirection add-on's and plugins (NoScript, AdBlockPlus, Ghostery, etc...) can interfere with the identification image display. My bank uses this sort of technology and it took me a while to identify exactly which plug-in was blocking the security image and then time to sort out an exception rule to not block it. The point being - end users *will* install plug-ins and extensions that may interfere with your verification tools. Dave -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSSh7jAAoJEDMbeBxcUNAel+AIAIx5Y1M0zlQtPU14aKaIE0Eo jpQRCRgY4X/g30EnNt5wh+umKPS7ZSwPg62GfLpmntijPsGCThXVxY62OfJpnZU9 uWh+AwNG3RkMn90w2at1YaCbOyXiPEwN/2PuRsJ+RRQRKu4hbJmF1/1X36ykoIAc s6LZ44a1FpIX8uGg5D6yo/emse3ZaKB6XlhoYZfbNlEnUc63/Sj8mC8K7ErhQbRu qM8/LayQHLNDy+xHFfHLS2v8EJUz8DOVXKWBxxNY6Ig2Z4g4oUbbrhP1pAo2S9J9 YIR/DO4I+epiAy6WvLl/H31EHqnne5qN7B+nOz8mXxH/yg3zMliVmNKI6UCypyM= =PXyH -END PGP SIGNATURE- ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
Op 30 sep. 2013, om 05:12 heeft Christoph Anton Mitterer cales...@scientia.net het volgende geschreven: Not sure whether this has been pointed out / discussed here already (but I guess Perry will reject my mail in case it has): https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3 This makes NIST seem somehow like liars,... on the one hand they claim Do keep in mind that in this case the crux is not around SHA-3 as a specification/algorithm - but about the number of bits one should use. One aspect in all this is into what engineering culture standards (such as those created by NIST) finally land. Is it in one which is a bit insecure and just does the absolute minimum; or is it in one where practitioners have certain gut-feels - and take them as absolute minimums ? I do note that in crypto (possibly driven by the perceived expense of too many bits) we tend to very carefully observe the various bit lengths found in 800-78-3, 800-131A , etc etc. And rarely go much beyond it*. While in a lot of other fields - it is very common for 'run of the mill' constructions; such as when calculating a floor, wooden support beam, a joist, to take the various standards and liberally apply safety factors. A factor 10 or 20x too strong is quite common *especially* in 'consumer' constructions. It is only when one does large/complex engineering works that you take the time to really calculate strength; and even then - a factor 2 or 3 is still very common; and barely raises an eyebrow with a cost conscious customer. So perhaps we need to look at those NIST et.al. standards in crypto and do the same - take them as a absolute minimum; but by default and routinely not feel guilty when we add a 10x or more. And at the same time evoke a certain 'feeling' of strength with our users. A supporting column can just 'look' right or too thin; a BMW car door can just make that right sound on closing***. And :) :) people like (paying for/owning) tools that look fit for purpose :) :) :). Dw *) and yes; compute power may have been an issue - but rarely is these days; I have a hard time measuring symmetric AES on outbound packet flows relative to all other stuff. **) and yes; compute, interaction/UI/UX joules may be a worry - but at the same time - CPU's have have gotten faster and clever UI's can background things or good engineers can device async/queues and what not. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
excerpting, we have James A. Donald wrote: Weaker in ways that the NSA has examined, and the people that chose the winning design have not. Viktor Dukhovni replies: Just because they're after you, doesn't mean they're controlling your brain with radio waves. Don't let FUD cloud your judgement. As we (here) are fond of saying, anything can be broken, therefore the question at hand is Who can break what at this strength? This question does not have a time-invariant answer, and, in any case, as Adi Shamir so adequately said, Cryptography is typically bypassed, not penetrated.[*] Nevertheless, the value of scepticism is profound; it is the chastity of the intellect. --dan [*] www.financialcryptography.com/mt/archives/000147.html ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
On 2013-10-01 08:51, Watson Ladd wrote: On Mon, Sep 30, 2013 at 2:21 PM, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: Weaker in ways that the NSA has examined, and the people that chose the winning design have not. This isn't true: Keccak's designers proposed a wide range of capacity parameters for different environments. This is not Keccak's design. This a new unexamined design somewhat resembling Keccak's design. Or perhaps Keccak's design somewhat resembled what the NSA had already decided to do. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 1/10/13 02:01 AM, Tony Arcieri wrote: On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. Sounds like you want CurveCP? http://curvecp.org/ Yes, EXACTLY that. Proposals like CurveCP. iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why is emailing me my password?
This falls somewhere in the land of beyond-the-absurd.
Just got this message from your robot:
On Oct 1, 2013, at 5:00 AM, mailman-ow...@metzdowd.com wrote:
If you have questions, problems, comments, etc, send them to
mailman-ow...@metzdowd.com. Thanks!
Passwords for g...@kinostudios.com:
List Password // URL
cryptography@metzdowd.comiPoopInYourHat
http://www.metzdowd.com/mailman/options/cryptography/greg%40kinostudios.com
So, my password, iPoopInYourHat, is being sent to me in the clear by your
servers.
Of all the places on the internet, this would be on the last places I would
expect this to happen.
- Greg
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
On 2013-10-01 10:17, John Kelsey wrote: Yeah, that plot to weaken sha3 is so secretive, we've been discussing it in public slide presentations and on public mailing lists for six months. All big conspiracies get exposed - I would make a list, but that would derail the conversation. It does not follow that there are no big powerful conspiracies. On the contrary, we have compelling evidence of more big powerful conspiracies than one can shake a stick at. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 1 October 2013 01:10, James A. Donald jam...@echeque.com wrote: On 2013-10-01 04:22, Salz, Rich wrote: designate some big player to do it, and follow suit? Okay that data encoding scheme from Google protobufs or Facebook thrift. Done. We have a complie to generate C code from ASN.1 code Google has a compiler to generate C code from protobufs source The ASN.1 compiler is open source. Google's compiler is not. Ahem: https://code.google.com/p/protobuf/downloads/list. Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Wat? Sez who? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 30 September 2013 23:24, John Kelsey crypto@gmail.com wrote: Maybe you should check your code first? A couple nist people verified that the curves were generated by the described process when the questions about the curves first came out. If you don't quote the message you're replying to, its hard to guess who should check what code - perhaps you could elaborate? Don't trust us, obviously--that's the whole point of the procedure. But check your code, because the process worked right when we checked it. --John ___ 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] Sha3
On 2013-10-01 10:24, John Kelsey wrote: If you want to understand what's going on wrt SHA3, you might want to look at the nist website If you want to understand what is going on with SHA3, and you believe that NIST is frank, open, honest, and has no ulterior motives, you might want to look at the NIST website. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 1 October 2013 09:46, James A. Donald jam...@echeque.com wrote: On 2013-10-01 18:06, Ben Laurie wrote: On 1 October 2013 01:10, James A. Donald jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Wat? Sez who? Protobufs is code generating code. Not allowed by google style guide. News to me - where does it say that? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 6:04 PM, Mark Atwood m...@mark.atwood.name wrote: YAML? YAML is a bit insane ;) There's JSON, and also TOML: https://github.com/mojombo/toml -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
On 1/10/13 00:21 AM, James A. Donald wrote: On 2013-10-01 00:44, Viktor Dukhovni wrote: Should one also accuse ESTREAM of maliciously weakening SALSA? Or might one admit the possibility that winning designs in contests are at times quite conservative and that one can reasonably standardize less conservative parameters that are more competitive in software? less conservative means weaker. Weaker in ways that the NSA has examined, and the people that chose the winning design have not. Why then hold a contest and invite outside scrutiny in the first place.? This is simply a brand new unexplained secret design emerging from the bowels of the NSA, which already gave us a variety of backdoored crypto. The design process, the contest, the public examination, was a lie. Therefore, the design is a lie. This could be the uninformed opinion over unexpected changes. It could also be the truth. How then to differentiate? Do we need to adjust the competition process for a tweak phase? Let's whiteboard. Once The One is chosen, have a single round + conference where each of the final contestants propose their optimised version. They then vote on the choice. (OK, we can imagine many ways to do this ... point being that if NIST are going to tweak the SHA3 then we need to create a way for them to do this, and have that tweaking be under the control of the submitters, not NIST itself. In order to maintain the faith of the result.) iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
What I don't understand here is why the process of selecting a standard algorithm for cryptographic primitives is so highly focused on speed. We have machines that are fast enough now that while speed isn't a non issue, it is no longer nearly as important as the process is giving it precedence for. Our biggest problem now is security, not speed. I believe that it's a bit silly to aim for a minimum acceptable security achievable within the context of speed while experience shows that each new class of attacks is usually first seen against some limited form of the cipher or found to be effective only if the cipher is not carried out to a longer process. Original message From: John Kelsey crypto@gmail.com Date: 09/30/2013 17:24 (GMT-08:00) To: cryptography@metzdowd.com List cryptography@metzdowd.com Subject: [Cryptography] Sha3 If you want to understand what's going on wrt SHA3, you might want to look at the nist website, where we have all the slide presentations we have been giving over the last six months detailing our plans. There is a lively discussion going on at the hash forum on the topic. This doesn't make as good a story as the new sha3 being some hell spawn cooked up in a basement at Fort Meade, but it does have the advantage that it has some connection to reality. You might also want to look at what the Keccak designers said about what the capacities should be, to us (they put their slides up) and later to various crypto conferences. Or not. --John ___ 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] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 6:17 PM, Mark Atwood m...@mark.atwood.name wrote: YAML is a superset of JSON C++ is a (not completely proper) superset of C. Does that make it better? ;) is more human readable, and, unlike JSON, has internal references. YAML also has the property that indentation mistakes can radically alter the interpretation of a file. And on Ruby, it was a remote code execution vulnerability waiting to happen. -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 3:08 AM, Adam Back a...@cypherspace.org wrote: But I do think it is a very interesting and pressing research question as to whether there are ways to plausibly deniably symmetrically weaken or even trapdoor weaken DL curve parameters, when the seeds are allowed to look random as the DSA FIPS 186-3 ones do. See slide #28 in this djb deck: http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf Specifically: http://i.imgur.com/C7mg3T4.png If e.g. the NSA knew of an entire class of weak curves, they could perform a brute force search with random looking seeds, continuing until the curve parameters, after the seed is run through SHA1, fall into the class that's known to be weak to them. -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
Okay, I didn't express myself very well the first time I tried to say this. But as I see it, we're still basing the design of crypto algorithms on considerations that had the importance we're treating them as having about twelve years ago. To make an analogy, it's like making tires when you need to have a ten thousand mile warranty. When rubber is terribly expensive and the cars are fairly slow, you make a tire that probably won't be good for twelve thousand miles. But it's now years later. Rubber has gotten cheap and the cars are moving a lot faster and the cost of repairing or replacing crashed vehicles is now dominating the cost of rubber. Even if tire failure accounts for only a small fraction of that cost, why shouldn't we be a lot more conservative in the design of our tires? A little more rubber is cheap and it would be nice to know that the tires will be okay even if the road turns out to be gravel. This is where I see crypto designers. Compute power is cheaper than it's ever been but we're still treating it as though its importance hasn't changed. More is riding on the cost of failures and we've seen how failures tend to happen. Most of the attacks we've seen wouldn't have worked on the same ciphers if the ciphers had been implemented in a more conservative way. A few more rounds of a block cipher or a wider hidden state for a PRNG, or longer RSA keys, even though we didn't know at the time what we were protecting from, would have kept most of these things safe for years after the attacks or improved factoring methods were discovered. Engineering is about achieving the desired results using a minimal amount of resources. When compute power was precious that meant minimizing compute power. But the cost now is mostly in redeploying and upgrading extant infrastructure. And in a lot of cases we're having to do that because the crypto is now seen to be too weak. When we try to minimize our use of resources, we need to value them accurately. To me that means making systems that won't need to be replaced as often. And just committing more of the increasingly cheap resource of compute power would have achieved that given most of the breaks we've seen in the past few years. To return to our road safety metaphor, we're now asking ourselves if we're still confident in that ten thousand mile warranty now that we've discovered that the company that puts up road signs has also been contaminating our rubber formula, sneakily cutting brake lines, and scattering nails on the road. Damn, it's enough to make you wish you'd overdesigned, isn't it? Original message From: John Kelsey crypto@gmail.com Date: 09/30/2013 17:24 (GMT-08:00) To: cryptography@metzdowd.com List cryptography@metzdowd.com Subject: [Cryptography] Sha3 If you want to understand what's going on wrt SHA3, you might want to look at the nist website, where we have all the slide presentations we have been giving over the last six months detailing our plans. There is a lively discussion going on at the hash forum on the topic. This doesn't make as good a story as the new sha3 being some hell spawn cooked up in a basement at Fort Meade, but it does have the advantage that it has some connection to reality. You might also want to look at what the Keccak designers said about what the capacities should be, to us (they put their slides up) and later to various crypto conferences. Or not. --John ___ 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] Why is emailing me my password?
On Tue, Oct 01, 2013 at 10:28:48AM -0400, Greg wrote: So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. All mailman lists do this by default. It does tell you on the sign up page that it will do so, and that you shouldn't use a 'valuable' (e.g. used elsewhere) password - see http://www.metzdowd.com/mailman/listinfo/cryptography It is an annoying default, but so long as you don't use a password attached to anything else you care about, I don't think it should be too much of a worry. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
On 9/30/13 at 4:09 PM, cryptogra...@dukhovni.org (Viktor Dukhovni) wrote: Just because they're after you, doesn't mean they're controlling your brain with radio waves. Don't let FUD cloud your judgement. ROTFLOL! --- Bill Frantz| Since the IBM Selectric, keyboards have gotten 408-356-8506 | steadily worse. Now we have touchscreen keyboards. www.pwpconsult.com | Can we make something even worse? ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Sep 30, 2013, at 8:10 PM, James A. Donald wrote: We have a complie to generate C code from ASN.1 code Google has a compiler to generate C code from protobufs source The ASN.1 compiler is open source. Google's compiler is not. http://code.google.com/p/protobuf/source/checkout. BSD 3-clause license. Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. I have no idea what this means. I can tell you with certainty that all kinds of clever code is being developed and deployed within Google (though I can't give you any details, of course). Some of it may eventually get described in the open literature; some of it may be open-sourced. Personally, I have no deep objections to ASN.1 - though much of its complexity has been proved unnecessary by the usage of other, much simpler, approaches, like protobufs. Still, once you have compiler for it, it doesn't really matter all that much either way. For crypto algorithms, you're unlikely to want or need the more obscure corners. Do keep in mind, however, that having just a way to generate C from ASN.1 no longer covers much of the necessary space, as there are now many popular languages that are no C-like. Some are easy to bind to C libraries (e.g., Python); others are much more difficult (e.g., Java). For ease of use, you really want generators that produce code well integrated into the target language, no some barely functional glued-together thing. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On Sep 30, 2013, at 9:01 PM, d.nix d@comcast.net wrote: It's also worth pointing out that common browser ad blocking / script blocking / and site redirection add-on's and plugins (NoScript, AdBlockPlus, Ghostery, etc...) can interfere with the identification image display. My bank uses this sort of technology and it took me a while to identify exactly which plug-in was blocking the security image and then time to sort out an exception rule to not block it. The point being - end users *will* install plug-ins and extensions that may interfere with your verification tools. It goes beyond that. A company named Iovation sells a service that's supposed to check a fingerprint of your machine against a database so that someone like a bank can determine if your login is supposed to come from this machine. (It also leaves behind a cookie, and may blacklist some addresses). Anyway, the result is a connection to iesnare.something when you go to your bank. I run a Little Snitch on my Mac's; it reports and ask for approval for unknown connections. So I see alerts pop up when I go to my bank and similar sites. Sometimes I block the connection, sometimes I let it through. (Actually, it doesn't seem to affect the site's behavior either way.) -- Jerry ___ 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 Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik di...@webweaving.org wrote: ...I do note that in crypto (possibly driven by the perceived expense of too many bits) we tend to very carefully observe the various bit lengths found in 800-78-3, 800-131A , etc etc. And rarely go much beyond it*. While in a lot of other fields - it is very common for 'run of the mill' constructions; such as when calculating a floor, wooden support beam, a joist, to take the various standards and liberally apply safety factors. A factor 10 or 20x too strong is quite common *especially* in 'consumer' constructions It's clear what 10x stronger than needed means for a support beam: We're pretty good at modeling the forces on a beam and we know how strong beams of given sizes are. We have *no* models for the strength of a crypto system that would allow one to meaningfully make such comparisons in general. It's like asking that houses be constructed to survive intact even when hit by the Enterprise's tractor beam. Oh, if you're talking brute force, sure, 129 bits takes twice as long as 128 bits. But even attacking a 128-bit cipher by brute force is way beyond anything we can even sketch today, and 256 bits is getting into if you could use the whole known universe as a computer it would talk you more than the life of the universe territory. If, on the other hand, you're talking analytic attacks, there's no way to know ahead of time what matters. The ultimate example of this occurred back when brute force attacks against DES, at 56 bits, were clearly on the horizon - so people proposed throwing away the key schedule and making the key the full expanded schedule of 448 bits, or whatever it came to. Many times more secure - except then differential cryptography was (re-)discovered and it turned out that 448-bit DES was no stronger than 56-bit DES. There are three places I can think of where the notion of adding a safety factor makes sense today; perhaps someone can add to the list, but I doubt it will grow significantly longer: 1. Adding a bit to the key size when that key size is small enough; 2. Using multiple encryption with different mechanisms and independent keys; 3. Adding rounds to a round-based symmetric encryptor of the design we currently use pretty universally (multiple S and P transforms with some keying information mixed in per round, repeated for multiple rounds). In a good cipher designed according to our best practices today, the best attacks we know of extend to some number of rounds and then just die - i.e., after some number of rounds they do no better than brute force. Adding a few more beyond that makes sense. But ... if you think adding many more beyond that makes sense, you're into tin-foil hat territory. We understand what certain attacks look like and we understand how they (fail to) extend beyond some number of rounds - but the next attack down the pike, about which we have no theory, might not be sensitive to the number of rounds at all. These arguments apply to some other primitives as well, particularly hash functions. They *don't* apply to asymmetric cryptography, except perhaps for case 2 above - though it may not be so easy to apply. For asymmetric crypto, the attacks are all algorithmic and mathematical in nature, and the game is different. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner YAML? On Mon, Sep 30, 2013 at 5:48 PM, Tony Arcieri basc...@gmail.com wrote: On Mon, Sep 30, 2013 at 9:41 AM, Mark Atwood m...@mark.atwood.name wrote: Well, there are Protobufs, and there is Thrift, and there is MessagePack, and there is Avro... Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
YAML is a superset of JSON, is more human readable, and, unlike JSON, has internal references. On Mon, Sep 30, 2013 at 6:14 PM, Tony Arcieri basc...@gmail.com wrote: On Mon, Sep 30, 2013 at 6:04 PM, Mark Atwood m...@mark.atwood.name wrote: YAML? YAML is a bit insane ;) There's JSON, and also TOML: https://github.com/mojombo/toml -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 28/09/13 22:06 PM, ianG wrote: On 27/09/13 18:23 PM, Phillip Hallam-Baker wrote: 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? What's in Suite A? Will probably illuminate that question... Just to clarify my original poser -- which *public key methods* are suggested in Suite A? RSA? EC? diversified keys? Something new? The answer will probably illuminate what the NSA really thinks about EC. (As well as get us all put in jail for thought-crime.) iang ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
1. okt. 2013 kl. 02:00 skrev James A. Donald jam...@echeque.com: On 2013-10-01 08:24, John Kelsey wrote: Maybe you should check your code first? A couple nist people verified that the curves were generated by the described process when the questions about the curves first came out. And a non NIST person verified that the curves were not generated by the described process after the scandal broke. Checking the verification code may be a good idea. I just checked that the verification process described in Appendix 5 in the document RECOMMENDED ELLIPTIC CURVES FOR FEDERAL GOVERNMENT USE, July 1999 (http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf) accepts the NIST prime field curves listed in that document. Trivial python script follows. I am certainly not the first non-US non-government person to check. There is solid evidence that the US goverment does bad things. This isn't it. -- Kristian Gjøsteen import hashlib def string_to_integer(s): n = 0 for byte in s: n = n*256 + ord(byte) return n def integer_to_string(n): if n == 0: return return integer_to_string(n/256) + chr(n%256) def verify_generation(s, p, l, b): assert(len(s) == 160/8) v = (l-1)/160 w = l - 160*v - 1 h = hashlib.sha1(s).digest() hh = integer_to_string(string_to_integer(h) % (2**w)) z = string_to_integer(s) + 1 # +1 because for loop goes from 0 to v-1 for i in range(v): hh = hh + hashlib.sha1(integer_to_string(z+i)).digest() c = string_to_integer(hh) if (b*b*c + 27)%p == 0: return True else: return False curve_data = [ (P-192 wrong, 6277101735386680763835789423207666416083908700390324961279, 192, 0x3045ae6fc822f64ed579528d38120eae12196d5, 0x64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1), (P-192, 6277101735386680763835789423207666416083908700390324961279, 192, 0x3045ae6fc8422f64ed579528d38120eae12196d5, 0x64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1), (P-224, 26959946667150639794667015087019630673557916260026308143510066298881, 224, 0xbd71344799d5c7fcdc45b59fa3b9ab8f6a948bc5, 0xb4050a850c04b3abf54132565044b0b7d7bfd8ba270b39432355ffb4), (P-256, 115792089210356248762697446949407573530086143415290314195533631308867097853951, 256, 0xc49d360886e704936a6678e1139d26b7819f7e90, 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b), (P-256 wrong, 115792089210356248762697446949407573530086143415290314195533631308867097853951, 256, 0xc49d360886e704936a6678e1139d26b7819f7e90, 0x7efba1662985be9403cb055c75d4f7e0ce8d84a9c5114abcaf3177680104fa0d), (P-384, 39402006196394479212279040100143613805079739270465446667948293404245721771496870329047266088258938001861606973112319, 384, 0xa335926aa319a27a1d00896a6773a4827acdac73, 0xb3312fa7e23ee7e4988e056be3f82d19181d9c6efe8141120314088f5013875ac656398d8a2ed19d2a85c8edd3ec2aef), (P-521, 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151, 521, 0xd09e8800291cb85396cc6717393284aaa0da64ba, 0x051953eb9618e1c9a1f929a21a0b68540eea2da725b99b315f3b8b489918ef109e156193951ec7e937b1652c0bd3bb1bf073573df883d2c34f1ef451fd46b503f00) ] for cd in curve_data: (name, p, l, s, b) = cd print name, verify_generation(integer_to_string(s), p, l, b) ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On Tue, Oct 1, 2013 at 10:28 AM, Greg g...@kinostudios.com wrote: This falls somewhere in the land of beyond-the-absurd. Just got this message from your robot: ... So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. Of all the places on the internet, this would be on the last places I would expect this to happen. From http://www.metzdowd.com/mailman/listinfo/cryptography === You may enter a privacy password below. This provides only mild security, but should prevent others from messing with your subscription. Do not use a valuable password as it will occasionally be emailed back to you in cleartext. === You can also turn off password reminders, but the password will be kept in plaintext. -- Eitan Adler ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-01 18:06, Ben Laurie wrote: On 1 October 2013 01:10, James A. Donald jam...@echeque.com mailto:jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Wat? Sez who? Protobufs is code generating code. Not allowed by google style guide. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
It's reasonable as it's not a security sensitive environment. Please for the love of god let some environments stay low-sec. 2013/10/1 Nick cryptography-l...@njw.me.uk On Tue, Oct 01, 2013 at 10:28:48AM -0400, Greg wrote: So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. All mailman lists do this by default. It does tell you on the sign up page that it will do so, and that you shouldn't use a 'valuable' (e.g. used elsewhere) password - see http://www.metzdowd.com/mailman/listinfo/cryptography It is an annoying default, but so long as you don't use a password attached to anything else you care about, I don't think it should be too much of a worry. ___ 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] Why is emailing me my password?
On 10/01/2013 10:28 AM, Greg wrote: This falls somewhere in the land of beyond-the-absurd. I noticed the password would be mailed in the clear when I signed up, but even if I had not, I would not have been bothered to later discover it. What is the harm? The sensitivity of this password is extremely limited. That is, unless you are someone who recycles one password in other places. You wouldn't do that, though, would you? -kb ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 01, 2013 at 08:47:49AM -0700, Tony Arcieri wrote: On Tue, Oct 1, 2013 at 3:08 AM, Adam Back [1]a...@cypherspace.org wrote: But I do think it is a very interesting and pressing research question as to whether there are ways to plausibly deniably symmetrically weaken or even trapdoor weaken DL curve parameters, when the seeds are allowed to look random as the DSA FIPS 186-3 ones do. See slide #28 in this djb deck: If e.g. the NSA knew of an entire class of weak curves, they could perform a brute force search with random looking seeds, continuing until the curve parameters, after the seed is run through SHA1, fall into the class that's known to be weak to them. Right but weak parameter arguments are very dangerous - the US national infrastructure they're supposed to be protecting could be weakened when someone else finds the weakness. Algorithmic weaknesses cant be hidden with confidence, how do they know the other countries defense research agencies arent also sitting on the same weakness even before they found it. Thats a strong disincentive. Though if its a well defined partial weakening they might go with it - eg historically they explicitly had a go at in public requiring use of eg differential cryptography where some of the key bits of lotus notes were encrypted to the NSA public key (which I have as a reverse-engineering trophy here[1]). Like for examle they dont really want foreign infrastructure to have more than 80 bits or something close to the edge of strength and they're willing to tolerate that on US infratructure also. Somewhat plausible. But the more interesting question I was referring to is a trapdoor weakness with a weak proof of fairness (ie a fairness that looks like the one in FIPS 186-3/ECDSA where we dont know how much grinding if any went into the magic seed values). For illustration though not applicable to ECDSA and probably outright defective eg can they start with some large number of candidate G values where G=xH (ie knowing the EC discrete log of some value H they pass off as a random fairly chosen point) and then do a birthday collision between the selection of G values and diffrent seed values to a PRNG to find a G value that they have both a discrete log of wrt H and a PRNG seed. Bearing in mind they may be willing to throw custom ASIC or FPGA supercomputer hardware and $1bil budgt at the problem as a one off cost. Adam [1] http://www.cypherspace.org/adam/hacks/lotus-nsa-key.html ___ 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?
Op 1 okt. 2013, om 17:59 heeft Jerry Leichter leich...@lrw.com het volgende geschreven: On Oct 1, 2013, at 3:29 AM, Dirk-Willem van Gulik di...@webweaving.org wrote: ...I do note that in crypto (possibly driven by the perceived expense of too many bits) we tend to very carefully observe the various bit lengths found in 800-78-3, 800-131A , etc etc. And rarely go much beyond it*. While in a lot of other fields - it is very common for 'run of the mill' constructions; such as when calculating a floor, wooden support beam, a joist, to take the various standards and liberally apply safety factors. A factor 10 or 20x too strong is quite common *especially* in 'consumer' constructions…. It's clear what 10x stronger than needed means for a support beam: We're pretty good at modeling the forces on a beam and we know how strong beams of given sizes are. Actually - do we ? I picked this example as it is one of those where this 'we know' falls apart on closer examination. Wood varies a lot; and our ratings are very rough. We drill holes through it; use hugely varying ways to glue/weld/etc. And we liberally apply safety factors everywhere; and a lot of 'otherwise it does not feel right' throughout. And in all fairness - while you can get a bunch of engineers to agree that 'it is strong enough' - they'd argue endlessly and have 'it depends' sort of answers when you ask them how strong is it 'really' ? Oh, if you're talking brute force, sure, 129 bits takes twice as long as 128 bits. ... If, on the other hand, you're talking analytic attacks, there's no way to know ahead of time what matters. So I think you are hitting the crux of the matter - the material, like most, we work with, is not that easy to gauge. But then when we consider your example of DES: The ultimate example of this occurred back when brute force attacks against DES, at 56 bits, were clearly on the horizon - so people proposed throwing away the key schedule and making the key the full expanded schedule of 448 bits, or whatever it came to. Many times more secure - except then differential cryptography was (re-)discovered and it turned out that 448-bit DES was no stronger than 56-bit DES. with hindsight we can conclude that despite all this - despite all the various instutitions and interests conspiring, fighting and collaborating roughly yielded us a fair level of safety for a fair number of years - and that is roughly what we got. Sure - that relied on 'odd' things; like the s-boxes getting strengthened behind the scenes, the EFF stressing that a hardware device was 'now' cheap enough. But by and large - these where more or less done 'on time'. So I think we roughly got the minimum about right with DES. The thing which facinates/strikes me as odd - is that that is then exactly what we all implemented. Not more. Not less. No safety; no nothing. Just a bit of hand waving to how complex it all is; how hard it is to predict; so we listen to NIST* et.al. and that is it then. *Despite* the fact that, as you so eloquently argue, the material we work with is notoriously unpredictable, finnicky and has many an uncontrolled unknown. And any failures or issues come back to haunt us, not NIST et.al. There are three places I can think of where the notion of adding a safety factor makes sense today; perhaps someone can add to the list, but I doubt it will grow significantly longer: 1. Adding a bit to the key size when that key size is small enough; 2. Using multiple encryption with different mechanisms and independent keys; 3. Adding rounds to a round-based symmetric encryptor of the design we currently use pretty universally (multiple S and P transforms with some keying information mixed in per round, repeated for multiple rounds). In a good cipher designed according to our best practices today, the best attacks we know of extend to some number of rounds and then just die - i.e., after some number of rounds they do no better than brute force. Adding a few more beyond that makes sense. But ... if you think adding many more beyond that makes sense, you're into tin-foil hat territory. We understand what certain attacks look like and we understand how they (fail to) extend beyond some number of rounds - but the next attack down the pike, about which we have no theory, might not be sensitive to the number of rounds at all. Agreed - and perhaps develop some routine practices around which way you layer; i.e. what is best wrapped inside which; and where do you (avoid) padding; or get the most out of IVs. These arguments apply to some other primitives as well, particularly hash functions. They *don't* apply to asymmetric cryptography, except perhaps for case 2 above - though it may not be so easy to apply. For asymmetric crypto, the attacks are all algorithmic and mathematical in nature, and the game is different. Very good point (I did
Re: [Cryptography] NIST about to weaken SHA3?
On Oct 1, 2013, at 4:48 AM, ianG i...@iang.org wrote: ... This could be the uninformed opinion over unexpected changes. It could also be the truth. How then to differentiate? Do we need to adjust the competition process for a tweak phase? Let's whiteboard. Once The One is chosen, have a single round + conference where each of the final contestants propose their optimised version. They then vote on the choice. I like the general idea here, but I suspect a vote at the end of a conference isn't going to yield great results. I'd hate to see something the designers opposed get adopted because they were outvoted by (say) a larger team. (OK, we can imagine many ways to do this ... point being that if NIST are going to tweak the SHA3 then we need to create a way for them to do this, and have that tweaking be under the control of the submitters, not NIST itself. In order to maintain the faith of the result.) The Keccak designers proposed reducing the capacity. You can find public statements about this online, including in the slides on their website. Also, the capacity is a parameter defined in the standard to allow an easy to understand performance/security tradeoff. Setting c=256 gives an across the board security level of 128 bits, if you believe the underlying Keccak permutation is good. The actual technical question is whether an across the board 128 bit security level is sufficient for a hash function with a 256 bit output. This weakens the proposed SHA3-256 relative to SHA256 in preimage resistance, where SHA256 is expected to provide 256 bits of preimage resistance. If you think that 256 bit hash functions (which are normally used to achieve a 128 bit security level) should guarantee 256 bits of preimage resistance, then you should oppose the plan to reduce the capacity to 256 bits. If you think a 256 bit hash function should only promise 128 bits of security, except in specific applicaitons like keyed hashes where it has been analyzed specifically and shown to get more, then you should (at least on technical grounds) like the proposal to reduce the capacity to 256 bits for a 256-bit hash output. --John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On Tue, 1 Oct 2013 10:28:48 -0400 Greg g...@kinostudios.com wrote: So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. Two things to keep in mind: 1. The damage one can do to you with knowledge of this password is beyond minimal. You might have your list subscriptions changed; so what? 2. The password is sent just in case you forgot it and want to unsubscribe. Without the password, any troll might unsubscribe you from the list by simply forging headers. Were this to be encrypted, you would wind up with the classic problem of lost private keys, leaving people who forgot their password unable to unsubscribe (at least in any automated fashion). -- Ben -- Benjamin R Kreuter UVA Computer Science brk...@virginia.edu KK4FJZ -- If large numbers of people are interested in freedom of speech, there will be freedom of speech, even if the law forbids it; if public opinion is sluggish, inconvenient minorities will be persecuted, even if laws exist to protect them. - George Orwell signature.asc Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-01 22:08, Salz, Rich wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Got any documentation for this assertion? The google style guide prohibits too-clever code. protobufs and gmock is too-clever code. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
There is nothing difficult about the right course of action here: Don't send the password. Disable this silly default. The attitude expressed in these replies is a disgrace to the profession of software security, and a disgrace to the list. It doesn't matter whether or not I should be using a unique password. I might not be, and even if I am, a nerd next to me shouldn't be able to change my subscription settings because of the listserv's idiotic setting. It is NOT the user's responsibility to compensate for the incompetence of sys admins or software developers. They are the ones who are failing their jobs. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 1, 2013, at 12:03 PM, Lodewijk andré de la porte l...@odewijk.nl wrote: It's reasonable as it's not a security sensitive environment. Please for the love of god let some environments stay low-sec. 2013/10/1 Nick cryptography-l...@njw.me.uk On Tue, Oct 01, 2013 at 10:28:48AM -0400, Greg wrote: So, my password, iPoopInYourHat, is being sent to me in the clear by your servers. All mailman lists do this by default. It does tell you on the sign up page that it will do so, and that you shouldn't use a 'valuable' (e.g. used elsewhere) password - see http://www.metzdowd.com/mailman/listinfo/cryptography It is an annoying default, but so long as you don't use a password attached to anything else you care about, I don't think it should be too much of a worry. ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 9:51 AM, Adam Back a...@cypherspace.org wrote: Right but weak parameter arguments are very dangerous - the US national infrastructure they're supposed to be protecting could be weakened when someone else finds the weakness. As the fallout from the Snowden debacle has shown (with estimates of the damage to US businesses in the tens of billions) the NSA seems to be unconcerned with the blowback potential of doing things that are potentially damaging when discovered. I wouldn't put it past them to intentionally weaken the NIST curves. That said, my gut feeling is they probably didn't. -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] RSA equivalent key length/strength
On 01/10/13 08:49, Kristian Gjøsteen wrote: 1. okt. 2013 kl. 02:00 skrev James A. Donald jam...@echeque.com: On 2013-10-01 08:24, John Kelsey wrote: Maybe you should check your code first? A couple nist people verified that the curves were generated by the described process when the questions about the curves first came out. And a non NIST person verified that the curves were not generated by the described process after the scandal broke. Checking the verification code may be a good idea. I just checked that the verification process described in Appendix 5 in the document RECOMMENDED ELLIPTIC CURVES FOR FEDERAL GOVERNMENT USE, July 1999 (http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf) accepts the NIST prime field curves listed in that document. Trivial python script follows. I am certainly not the first non-US non-government person to check. There is solid evidence that the US goverment does bad things. This isn't it. Agreed (though did you also check whether the supposed verification process actually matches the supposed generation process?). Also agreed, NSA could not have reverse-engineered the parts of the generating process from random source to the curve's b component, ie they could not have started with a chosen b component and then generated the random source. However they could easily have cherry-picked a result for b from trying several squillion source numbers. There is no real reason not to use something like the digits of pi as the source - which they did not do. Also, the method by which the generators (and thus the actual groups in use, not the curves) were chosen is unclear. Even assuming NSA tried their hardest to undermine the curve selection process, there is some doubt as to whether these two actual and easily verifiable failings in a supposedly open generation process are enough to make the final groups selected useful for NSA's nefarious purposes. But there is a definite lack of clarity there. -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Linux /dev/random and /dev/urandom
On 09/30/2013 09:28 AM, d...@geer.org wrote: If there is anything I've learned about the Internet it is that if you ask a difficult question you will get very little in the way of answers you can trust a priori. However, if you make a false claim, then people will come out of the woodwork to tell you that You are a doofus and here is why. That reminds me of the Linux device driver for /dev/random and /dev/urandom. We know it is highly reliable, because it is used for a wide range of critical applications, and nobody would use it if it weren't reliable. Users -- as well as kernel developers -- are all keenly aware of how much modern cryptography depends on random numbers ... and how much security depends on attention to detail. We know it is a strong RNG, because it says so, right at the top of the file, the drivers/char/random.c file. Therefore there is no need for anybody to review the code, let alone measure its performance under real-world conditions. I'm sure the driver was written by highly proficient cryptographers, and subjected to a meticulous code review. There is no way the code could have bugs that waste entropy. There is no way the code could have bugs that waste buffer capacity, degrading the response to peak demand. There is no way a variable could be used with one undocumented meaning and then used with a different undocumented meaning a few lines later. There is no way anybody would ever create a PRNG with no lower bound on how often it gets reseeded. I haven't looked at the code -- heaven forbid -- but it must be well commented, in accordance with the high standards found throughout the kernel. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Linux /dev/random and /dev/urandom
On Tue, Oct 1, 2013 at 11:10 AM, Isaac Bickerstaff j...@av8n.com wrote: I'm sure the driver was written by highly proficient cryptographers, and subjected to a meticulous code review. I'll just leave this here: http://eprint.iacr.org/2013/338.pdf -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Oct 1, 2013, at 12:28 PM, James A. Donald jam...@echeque.com wrote: Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again. Got any documentation for this assertion? The google style guide prohibits too-clever code. protobufs and gmock is too-clever code. To be blunt, you have no idea what you're talking about. I worked at Google until a short time ago; Ben Laurie still does. Both of us have written, submitted, and reviewed substantial amounts of code in the Google code base. Do you really want to continue to argue with us about what the Google Style Guide is actually understood within Google? -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 01/10/13 08:54, ianG wrote: On 1/10/13 02:01 AM, Tony Arcieri wrote: On Mon, Sep 30, 2013 at 1:02 AM, Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; encrypt and then MAC only, no non-forward secret ciphersuites, no baked in key length limits. I think I'd also vote for a lot less modes and ciphers. And probably non-NIST curves while we're at it. Sounds like you want CurveCP? http://curvecp.org/ Yes, EXACTLY that. Proposals like CurveCP. I have said this first part before: Dan Boneh was talking at this years RSA cryptographers track about putting some sort of quantum-computer-resistant PK into browsers - maybe something like that should go into TLS2 as well? We need to get the browser makers - Apple, Google, Microsoft, Mozilla - and the webservers - Apache, Microsoft, nginx - together and get them to agree we must all implement this before writing the RFC. Also, the banks and the CA's should have an input. But not a say. More rules: IP-free, open source code, no libraries (*all* functions internal to each suite) a compiler which gives repeatable binary hashes so you can verify binary against source. Note to Microsoft - open source does not always mean free. But in this case it must be free. Maximum of four crypto suites. Each suite has fixed algorithms, protocols, key and group sizes etc. Give them girls' names, not silly and incomplete crypto names - This connection is protected by Alice. Ability to add new suites as secure browser upgrade from browser supplier. ?New suites must be signed by working group?. Signed new suites must then be available immediately on all platforms, both browser and webserver. Separate authentication and sessionkeysetup keys mandatory. Maybe use existing X.509? but always for authentication only, never sessionkeysetup. No client authentication. None. Zero. That's too hard for an individual to manage - remembering passwords or whatever, yes, global authentication, no. That does not belong in TLS. I specifically include this because the banks want it, now, in order to shift liability to their customers. And as to passwords being near end-of-life? Rubbish. Keep the password database secure, give the user a username and only three password attempts, and all your GPUs and ASIC farms are worth nothing. -- Peter Fairbrother ___ 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 10/1/13 at 12:29 AM, di...@webweaving.org (Dirk-Willem van Gulik) wrote: While in a lot of other fields - it is very common for 'run of the mill' constructions; such as when calculating a floor, wooden support beam, a joist, to take the various standards and liberally apply safety factors. A factor 10 or 20x too strong is quite common *especially* in 'consumer' constructions. In cave rescue the National Cave Rescue Commission (a training organization) uses a 7:1 system safety ratio in its trainings. This is for building systems where people could be seriously hurt or killed if the system fails. Cheers - Bill, NCRC instructor --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On 10/1/13 at 8:47 AM, basc...@gmail.com (Tony Arcieri) wrote: If e.g. the NSA knew of an entire class of weak curves, they could perform a brute force search with random looking seeds, continuing until the curve parameters, after the seed is run through SHA1, fall into the class that's known to be weak to them. Or NSA could have done what it did with DES and chosen a construct that didn't have that weakness. We just don't know. Cheers - Bill --- Bill Frantz| I don't have high-speed | Periwinkle (408)356-8506 | internet. I have DSL.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On 10/01/2013 06:56 PM, Benjamin Kreuter wrote: 2. The password is sent just in case you forgot it and want to unsubscribe. Without the password, any troll might unsubscribe you from the list by simply forging headers. Were this to be encrypted, you would wind up with the classic problem of lost private keys, leaving people who forgot their password unable to unsubscribe (at least in any automated fashion). Agreed, that's a good point against PKI in this case. However, why use a password at all? I'd also argue it gives a false sense of security. For that very reason I prefer mailing list software that works via email (rather than web interface) and authenticates by the ability to receive mails under the given email. Forging headers doesn't quite suffice there, either. Regards Markus Wanner ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
I think that's absurd to say that it gives a false sense of security. It only gives a sense of security if you didn't read the text when you entered the password in the first place. It keeps people from doing mass unsubscribes trivially. If someone was targeting you, yes, they would be able to delete your subscription, but that would likely be true with little effort to begin with if you are of the type that doesn't read that your password is stored insecurely and sent in plain text when you enter it. On 01/10/2013 2:17 PM, Markus Wanner wrote: On 10/01/2013 06:56 PM, Benjamin Kreuter wrote: 2. The password is sent just in case you forgot it and want to unsubscribe. Without the password, any troll might unsubscribe you from the list by simply forging headers. Were this to be encrypted, you would wind up with the classic problem of lost private keys, leaving people who forgot their password unable to unsubscribe (at least in any automated fashion). Agreed, that's a good point against PKI in this case. However, why use a password at all? I'd also argue it gives a false sense of security. For that very reason I prefer mailing list software that works via email (rather than web interface) and authenticates by the ability to receive mails under the given email. Forging headers doesn't quite suffice there, either. Regards Markus Wanner ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography -- Kelly John Rose Mississauga, ON Phone: +1 647 638-4104 Twitter: @kjrose Document contents are confidential between original recipients and sender. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] are ECDSA curves provably not cooked? (Re: RSA equivalent key length/strength)
On Tue, Oct 1, 2013 at 12:00 PM, Jeffrey Goldberg jeff...@goldmark.orgwrote: If the NSA had the capability to pick weak curves while covering their tracks in such a way, why wouldn’t they have pulled the same trick with Dual_EC_DRBG? tinfoilhatThey wanted us to think they were incompetent, so we would expect that Dual_EC_DRBG was their failed attempt to tamper with a cryptographic standard, and so we would overlook the more sinister and subtle attempts to tamper with the NIST curves/tinfoilhat -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
At 02:27 PM 9/30/2013, James A. Donald wrote: On 2013-09-30 18:02, Adam Back wrote: If we're going to do that I vote no ASN.1, and no X.509. Just BNF format like the base SSL protocol; Granted that ASN.1 is incomprehensible and horrid, but, since there is an ASN.1 compiler that generates C code we should not need to comprehend it. Unfortunately, you have to be able to comprehend all of the failure modes and attacks on ASN.1. The object descriptions themselves are a bit bloaty, with their main weakness being that either you have to get permission to attach your data into the official tree, or else do a vendor-specific branch, but they're not all that broken. It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On 10/01/2013 10:26 PM, Kelly John Rose wrote: I think that's absurd to say that it gives a false sense of security. It only gives a sense of security if you didn't read the text when you entered the password in the first place. Well, that applies to at least 90% of people for 90% the cases. Yes, often enough including myself. It keeps people from doing mass unsubscribes trivially. As I pointed out, there are other ways to achieve that, without the need for a password. Or actually rather with one-time passwords, instead. If someone was targeting you, yes, they would be able to delete your subscription, Sure. That's the case either way. but that would likely be true with little effort to begin with if you are of the type that doesn't read that your password is stored insecurely and sent in plain text when you enter it. Let's compare apples to apples: even if you manage to actually read the instructions, you actually have to do so, have to come up with a throw-away-password, and remember it. For no additional safety compared to one-time tokens. The positive point I see for the web front-end is that people are more used to it. And have a hard time reading instructions on emails and hitting reply to send back a confirmation token. But your hypothesis is that people do read instructions, so... Regards Markus Wanner ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Passwords
On Oct 1, 2013, at 4:13 PM, Peter Fairbrother wrote: And as to passwords being near end-of-life? Rubbish. Keep the password database secure, give the user a username and only three password attempts, and all your GPUs and ASIC farms are worth nothing. Yup. I've (half-)jokingly suggested that any business maintaining a database of usernames and passwords must, by law, include within that database, under a set of fixed fake user names using exactly the same format and algorithms as is used for all other user accounts, such things as (a) the business's bank account data, including account numbers and full authentication information; (b) similar information about the top executives in the company and everyone on the management chain who has any responsibility for the database. Once that information is in the database, the business can protect it or not, as they wish. Let them sink or swim along with their users. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On Mon, Sep 30, 2013 at 1:41 AM, ianG i...@iang.org wrote: Experience suggests that asking a standards committee to do the encoding format is a disaster. I just looked at my code, which does something we call Wire, and it's 700 loc. Testing code is about a kloc I suppose. Writing reference implementations is a piece of cake. Why can't we just designate some big player to do it, and follow suit? Why argue in committee? Well, the details are important ;) If someone is particularly fond of arguing over certificate formats, ZeroMQ is trying to design one. I'm also trying to design one as well! It would be nice to consolidate efforts on an X.509 replacement, even if it's a limited capacity one. Here's the original email to the 0MQ list: http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/022975.html Here's my response: http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/023009.html -- Tony Arcieri ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Sha3
On Tue, 2013-10-01 at 02:34 -0700, 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. We have machines that are fast enough now that while speed isn't a non issue, it is no longer nearly as important as the process is giving it precedence for. Our biggest problem now is security, not speed. I believe that it's a bit silly to aim for a minimum acceptable security achievable within the context of speed while experience shows that each new class of attacks is usually first seen against some limited form of the cipher or found to be effective only if the cipher is not carried out to a longer process. Absolutely agreeing... I mean that is the most important point about crypto at all - being secure. And if one is in doubt (and probably even when not), better use a very big security margin, which in the SHA3 case would mean, rather take high multiples of bit lengths and capacity than what seems conservatively secure enough. The argument, that attackers don't penetrate but rather circumvent cryptography doesn't count much at all, IMHO. Sure that's what happens in practise, but if we hook up on that, we could more or less drop any cryptography for say 98% of mankind which use insecure (or even backdoored) systems like Windows, MacOS, Flash, etc. pp.. Obviously, performance is an issue for some systems (especially embedded) but an algo that is fast enough, but potentially not secure enough is absolutely worthless[0]. Sure, some people utilise the FUD argument now,... basically pointing that we have no strong reason to believe that e.g. Keccack with the newly proposed parameters from NIST isn't secure enough. But when we should have learned one thing from the whole NSA/friends scandal is ... we really don't have much of an idea how far these guys are up to - neither in terms of mathematics, nor in terms of raw computing power (when the public already knows about facilities like that Utah data centre - one can probably fairly well expect that dozens of these exist which are unknown). Cheers, Chris. [0] And if you want a fast hash algorithm that is not to be used in cryptography, we have plenty of other solutions already. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NIST about to weaken SHA3?
On Tue, 2013-10-01 at 12:47 -0400, John Kelsey wrote: The actual technical question is whether an across the board 128 bit security level is sufficient for a hash function with a 256 bit output. This weakens the proposed SHA3-256 relative to SHA256 in preimage resistance, where SHA256 is expected to provide 256 bits of preimage resistance. If you think that 256 bit hash functions (which are normally used to achieve a 128 bit security level) should guarantee 256 bits of preimage resistance, then you should oppose the plan to reduce the capacity to 256 bits. If you think a 256 bit hash function should only promise 128 bits of security, except in specific applicaitons like keyed hashes where it has been analyzed specifically and shown to get more, then you should (at least on technical grounds) like the proposal to reduce the capacity to 256 bits for a 256-bit hash output. I think the question is rather, what is the exact benefit NIST expects from this? AFAIU, performance wasn't the major priority during the competition, was it? And even were, then Keccak has won already with the higher values, hasn't it? So when c roughly gives the performance/security tradeoff... then from a pure security POV, we should obviously set a high c, right? So has NIST experienced some real world scenarios where the previous values of c yielded in a too slow algorithm, that made it unusable for the job? Cause if not,... then I'm back to the argument, why moving the performance/security tradeoff towards performance, if there was no strong reason,... Even(!) if one says, that from a crypto POV, 128 bits would be enough for a 256 bit hash... as long as we aren't forced due to some strong performance reasons... rather waste the extra security margin than dropping it. Cheers, Chris. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
On 10/1/13 at 1:43 PM, mar...@bluegap.ch (Markus Wanner) wrote: Let's compare apples to apples: even if you manage to actually read the instructions, you actually have to do so, have to come up with a throw-away-password, and remember it. For no additional safety compared to one-time tokens. Let Mailman assign you a password. Then you don't have to worry about someone collecting all your mailing list passwords and reverse engineering your password generation algorithm. You'll find out what the password is in a month. Save that email so you can make changes. Get on with life. Lets not increase the level of user work in cases where there isn't, in fact, a security problem. I'm interested in cases where Mailman passwords have been abused. Cheers - Bill --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
Actually, it's only *your* password that's being emailed in the clear. It's punishment for failing to observe the first rule of this list, which is DO NOT TOP POST. Huh? 1. I don't know what top post means, and I see nothing here about it: http://www.metzdowd.com/mailman/listinfo/cryptography 2. The password was sent to me as part of a poorly configured mailing list bot, not any sort of punishment. 3. Even if it was sent to me as punishment, that is retarded. If you don't like the way this list is run, you are welcome to unsubscribe. Yeah, I know. I might do that, as seeing the response to my request has convinced me there's little worth reading here anyway. The person running this list knows his job very well, and I'd suggest you be a bit more respectful of him. What did I say that you feel was disrespectful? That he's failing at his job? That's not disrespectful, that's my opinion based on the fact that he is choosing to mail people their list passwords in the clear. Running a mailing list is not hard work. There are only so many things one can fuck up. This is probably one of the biggest mistakes that can be made in running a mailing list, and on a list that's about software security. It's just ridiculous. A mailing list shouldn't have any passwords to begin with. There is no need for passwords, and it shouldn't be possible for anyone to unsubscribe anyone else. User: Unsubscribe [EMAIL] - Server Server: Are you sure? - [EMAIL] User@[EMAIL]: YES! - Server. No passwords, and no fake unsubscribes. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 1, 2013, at 4:56 PM, John Ioannidis j...@tla.org wrote: On Tue, Oct 1, 2013 at 12:56 PM, Greg g...@kinostudios.com wrote: There is nothing difficult about the right course of action here: Don't send the password. Disable this silly default. The attitude expressed in these replies is a disgrace to the profession of software security, and a disgrace to the list. It doesn't matter whether or not I should be using a unique password. I might not be, and even if I am, a nerd next to me shouldn't be able to change my subscription settings because of the listserv's idiotic setting. It is NOT the user's responsibility to compensate for the incompetence of sys admins or software developers. They are the ones who are failing their jobs. Actually, it's only *your* password that's being emailed in the clear. It's punishment for failing to observe the first rule of this list, which is DO NOT TOP POST. If you don't like the way this list is run, you are welcome to unsubscribe. The password for unsubscribing has been already emailed to you. The person running this list knows his job very well, and I'd suggest you be a bit more respectful of him. /ji signature.asc Description: Message signed with OpenPGP using GPGMail ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Linux /dev/random and /dev/urandom
On 1 October 2013 19:57, Tony Arcieri basc...@gmail.com wrote: On Tue, Oct 1, 2013 at 11:10 AM, Isaac Bickerstaff j...@av8n.com wrote: I'm sure the driver was written by highly proficient cryptographers, and subjected to a meticulous code review. I'll just leave this here: http://eprint.iacr.org/2013/338.pdf Can someone in the crypto-community with the necessary technical knowledge and contacts please review the above paper and then find someone (perhaps the authors?) to provide the necessary patches to the Linux kernel to get this fixed? This seems to be an excellent opportunity to utilise the supposed merits of open source development and review. If enough *justified* noise is made in the Linux dev community I would hope this would rapidly bubble up to become a required security patch for all the major Linux distros. For context here is a recent discussion about entropy generation and a list of Linux developers that might be interested in sponsoring a peer-reviewed Linux kernel patch: Recent discussion on LKML re: [PATCH] /dev/random: Insufficient of entropy on many architectures: https://lkml.org/lkml/2013/9/10/441 Note the concern about efficiency as priority over security. /dev/random is I believe used by OpenSSL - https://factorable.net/ Regards, Gary ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
Here's a crazy idea: instead of using one of these formats, use a human readable format that can be described by a formal grammar which is hopefully regular, context-free, or context-sensitive in a limited manner If only we could channel the late Jon Postel. Didn't you ever notice how almost all the early Arpanet/Internet standards use plain text separated by newlines, simply parsed, with a word at the front of each line that describes what is on the line? Like, for example, the header of this email message. And the SMTP exchange that delivered it to your mailbox. It makes everything so easy to debug...and extend...and understand. And it turns out to often be more compact than binary formats. Much better than binary blobs that not even their mother could love. John ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] AES-256- More NIST-y? paranoia
AES, the latest-and-greatest block cipher, comes in two main forms - AES-128 and AES-256. AES-256 is supposed to have a brute force work factor of 2^256 - but we find that in fact it actually has a very similar work factor to that of AES-128, due to bad subkey scheduling. Thing is, that bad subkey scheduling was introduced by NIST ... after Rijndael, which won the open block cipher competition with what seems to be all-the-way good scheduling, was transformed into AES by NIST. So, why did NIST change the subkey scheduling? I don't know. Inquiring minds ... NIST have previously changed cipher specs under NSA guidance, most famously for DES, with apparently good intentions then - but with NSA and it's two-faced mission, we always have to look at capabilities, not intentions. -- Peter Fairbrother [and why doesn't AES-256 have 256-bit blocks???] ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
Low security environment, minimal ability to inflict damage, clear instructions from the beginning. If the system and processes are not to your liking, that's understandable. Everyone is different. There are other choices. If you'd like to investigate them, determine an appropriate one, and advocate a move to it, that would be welcomed, I presume? The move may not be made, but the effort would be respected. And if you succeed in advocating a move to a new, better system, you would have an impressive new entry on your CV. After all, herding cats is nothing on moving an entire mailing list of geeks and cryptographers to a new system. :) No offense meant, in any way. Please forgive me if offense is given. Joshua Marpet ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why is emailing me my password?
Actually, it's only *your* password that's being emailed in the clear. It's punishment for failing to observe the first rule of this list, which is DO NOT TOP POST. Actually, my previous reply to this comment of yours did not adequately point out the magnitude of its idiocy. The reason I posted to the list in the first place was because the password was sent to me in the clear. This thread has been my sole contribution to the list so far. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 1, 2013, at 6:03 PM, Greg g...@kinostudios.com wrote: Actually, it's only *your* password that's being emailed in the clear. It's punishment for failing to observe the first rule of this list, which is DO NOT TOP POST. Huh? 1. I don't know what top post means, and I see nothing here about it: http://www.metzdowd.com/mailman/listinfo/cryptography 2. The password was sent to me as part of a poorly configured mailing list bot, not any sort of punishment. 3. Even if it was sent to me as punishment, that is retarded. If you don't like the way this list is run, you are welcome to unsubscribe. Yeah, I know. I might do that, as seeing the response to my request has convinced me there's little worth reading here anyway. The person running this list knows his job very well, and I'd suggest you be a bit more respectful of him. What did I say that you feel was disrespectful? That he's failing at his job? That's not disrespectful, that's my opinion based on the fact that he is choosing to mail people their list passwords in the clear. Running a mailing list is not hard work. There are only so many things one can fuck up. This is probably one of the biggest mistakes that can be made in running a mailing list, and on a list that's about software security. It's just ridiculous. A mailing list shouldn't have any passwords to begin with. There is no need for passwords, and it shouldn't be possible for anyone to unsubscribe anyone else. User: Unsubscribe [EMAIL] - Server Server: Are you sure? - [EMAIL] User@[EMAIL]: YES! - Server. No passwords, and no fake unsubscribes. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Oct 1, 2013, at 4:56 PM, John Ioannidis j...@tla.org wrote: On Tue, Oct 1, 2013 at 12:56 PM, Greg g...@kinostudios.com wrote: There is nothing difficult about the right course of action here: Don't send the password. Disable this silly default. The attitude expressed in these replies is a disgrace to the profession of software security, and a disgrace to the list. It doesn't matter whether or not I should be using a unique password. I might not be, and even if I am, a nerd next to me shouldn't be able to change my subscription settings because of the listserv's idiotic setting. It is NOT the user's responsibility to compensate for the incompetence of sys admins or software developers. They are the ones who are failing their jobs. Actually, it's only *your* password that's being emailed in the clear. It's punishment for failing to observe the first rule of this list, which is DO NOT TOP POST. If you don't like the way this list is run, you are welcome to unsubscribe. The password for unsubscribing has been already emailed to you. The person running this list knows his job very well, and I'd suggest you be a bit more respectful of him. /ji signature.asc Description: Message signed with OpenPGP using GPGMail ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] encoding formats should not be committee'ized
On 2013-10-02 05:18, Jerry Leichter wrote: To be blunt, you have no idea what you're talking about. I worked at Google until a short time ago; Ben Laurie still does. Both of us have written, submitted, and reviewed substantial amounts of code in the Google code base. Do you really want to continue to argue with us about what the Google Style Guide is actually understood within Google? The google style guide, among other things, prohibits multiple direct inheritance and operator overloading, except where stl makes you do operator overloading. Thus it certainly prohibits too-clever code. The only debatable question is whether protobufs, and much of the rest of the old codebase, is too-clever code - and it certainly a lot more clever than operator overloading. Such prohibitions also would prohibit the standard template library, except that that is also grandfathered in, and prohibits atl and wtl. The style guide is designed for an average and typical programmer who is not as smart as the early google programmers. If you prohibit anything like wtl, you prohibit the best. Prohibiting programmers from using multiple inheritance is like the BBC prohibiting the world literally instead of mandating that it be used correctly. It implies that the BBC does not trust its speakers to understand the correct use of literally, and google does not trust its programmers to understand the correct use of multiple direct inheritance. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. This is an inherent problem, not with ASN.1, but with any data representation that can represent arbitrary data. The decoder should only be able to decode the data structure it expects, that its caller knows how to interpret, and intends to interpret. Anything else should fail immediately. Thus our decoder should have been compiled from, a data description, rather than being a general purpose decoder. Thus sender and receiver should have to agree on the data structure for any communication to take place, which almost automatically gives us a highly compressed format. Conversely, any highly compressed format will tend to require and assume a known data structure. The problem is that we do not want, and should not have, the capacity to send a program an arbitrary data structure, for no one can write a program that can respond appropriately to an arbitrary data structure. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] TLS2
On 2013-10-01 14:36, Bill Stewart wrote: It's the data representations that map them into binary strings that are a wretched hive of scum and villainy, particularly because you can't depend on a bit string being able to map back into any well-defined ASN.1 object or even any limited size of ASN.1 object that won't smash your stack or heap. The industry's been bitten before by a widely available open source library that turned out to be vulnerable to maliciously crafted binary strings that could be passed around as SNMP traps or other ASN.1-using messages. Similarly, PGP's most serious security bugs were related to variable-length binary representations that were trying to steal bits to maximize data compression at the risk of ambiguity. Scrounging a few bits here and there just isn't worth it. BER and DER can express an arbitrary data structure - and thus can crash the program receiving the data, probably causing it to execute transmitted data as code. The same, however, is true of every overly general line format. Incoming data should be parsed as the expected and bounded size data structure, thus we need something that can generate parsing code from a description of the data at compile time. We need compile time descriptions of the data, not run time descriptions, because the program that uses the incoming data will unavoidably rely on compile time description of the data. PER, however cannot receive unexpected data structures. Thus all data should be transmitted as PER, or by a format with the properties of PER. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
