On 13/10/2014 16:45 pm, coderman wrote: > On 10/13/14, ianG <i...@iang.org> wrote: >> ... >> your welcome ;-) > > a considered and insightful response to my saber rattling diatribe. > > i owe you a beer, sir!
I'm honoured! >> Ah well, there is another rule we should always bring remember: >> >> Do not use known-crap crypto. >> >> Dual_EC_DRBG is an example of a crap RNG. For which we have data going >> back to 2006 showing it is a bad design. > > let's try another example: Intel RDRAND or RDSEED. depend on it as > the sole source of entropy? According to what I consider good secure practices [0] relying on one (platform) source for random numbers is probably best unless you really truly have a good reason not to. We have no data that suggests the design is bad. Actually all the data suggests the design is good! What we have is an unfortunate learning exercise in being too good: whitening in hardware also hides backdoors. Is that good enough a reason? Not my call, at the moment. But when data turns up, such as the attacks on Dual_EC_DRGB, we'll have something to chew on. > in theory, the only attacks that would allow to manipulate the output > are outside scope. (e.g. the data shows them as nation state level > hypothetical) > > is "depending on a single entropy source" the "known-crap" part? I say no. > or is > it the un-verifiable output of this specific source that is > "known-crap"? Ah, yes, this is a question. I'd say it isn't "known-crap" again because there is substantial pressure on the platform provider to not ever get caught providing known-crap. Which makes it a very high value target ;) so there are limits to assumptions here. One wonders if they will fix that in future releases... > (or am i overreaching, and you advocate direct and sole use of RDRAND > everywhere? :) :) em, close, I advocate direct and sole use of your platform's RNG. Rule #1: http://iang.org/ssl/hard_truths_hard_random_numbers.html 1. Use what your platform provides. Random numbers are hard, which is the first thing you have to remember, and always come back to. Random numbers are so hard, that you have to care a lot before you get involved. A hell of a lot. Which leads us to the following rules of thumb for RNG production. a. Use what your platform provides. b. Unless you really really care a lot, in which case, you have to write your own RNG. c. There isn't a lot of middle ground. d. So much so that for almost all purposes, and almost all users, Rule #1 is this: Use what your platform provides. E.g., for *nix, use urandom [Ptacek]. e. When deciding to breach Rule #1, you need a compelling argument that your RNG delivers better results than the platform's [Gutmann1]. Without that compelling argument, your results are likely to be more random than the platform's system in every sense except the quality of the numbers. >> Others in this category include: RC4, DES, MD5, various wifi junk >> protocols, etc. > > if RC4 is known-crap, then how is a downgrade to known-crap not a problem? It is. For my money, a downgrade is always known-crap. A downgrade to known-crap is beyond embarrassing, it's humiliating. It is a mark of architectural failure, it means that you knew there was known-crap yet you did nothing. Oh, and today's news. SSL should have been deprecated ages ago. Why wasn't it? Just embarrassing; those who wax ladonical about the need to support 350 algorithm suites and versions back to the beginning of time have no, zip, nada thought let alone solution on deprecation. >>> Q: 'Should I switch away from 1024 bit strength RSA keys?' >> >> I agree with that, and I'm on record for it in the print media. I am >> not part of the NIST lemmings craze. >> >> So, assuming you think I'm crazy, let's postulate that the NSA has a box >> that can crunch a 1024 key in a day. What's the risk? >> ... >> WYTM? The world that is concerned about the NSA is terrified of open >> surveillance. RSA1024 kills open surveillance dead. > > consider a service provider that i use, like Google, with a > hypothetical 1024 bit RSA key to secure TLS. they don't use forward > secrecy, so recovery of their private key can recover content. If google were to ask me 'Is 1024 bit broken' I would say no. 'Should I switch away from 1024 bit strength RSA keys?' then sure, do that, in time, but don't be overly panicked about it. (This is a trick question of course, you've shifted the goalposts. So I shifted the strike... google is reputed to have security people and never ever asks anyone else what to do. On the other hand, your average online bank is something that practices 'best practices' and needs to be told what to do.) > what is the risk that a Google-like provider key could be attacked? i > have no idea. but certainly more than my risk as a single individual. Indeed. In fact, we know they were already attacked, and breached. If they'd asked me on that one I'd have said, yeah, probably best to have 1024 bit RSA rather than nothing ;) > regarding open surveillance, this is a potential mechanism for it > despite the appearance of privacy. > > at what point does an insufficient key length become "known-crap" vs. > needless lemming craziness? This is a very good question but I believe the wrong one. The problem isn't the keylength, it is the lack of upgradeability in modern systems. As we saw today, SSL 3.0 is now this month's pariah. Yet SSL 3.0 was late 1990s, there are now kids in the industry who weren't born when SSL 3.0 was designed. So, why is it still there? If we had an answer to that, we'd have the answer to the "known-crap" keylength problem as well. Focus on the real problem: how do we upgrade *everything* to something written in the last 7 years? > said another way, "the data" is only useful if you or those you trust > is not an outlier. Yes, I'd agree. Data is useful in absence of some other evidence, but we agree it is statistical and only an approximation that suits the mainstream. If you're an outlier, you've got outlying problems. But if you're an outlier, your problems should not be a burden on others. This is why NIST is wrong to force everyone to upgrade to 2048, and it is unbalanced to mix general advice with what google do. > in addition, "the data" is only retrospective; by > definition class breaks and novel attacks are not worth considering > until they become known and used. Yup, this is a cost, some have to take it for the team; balanced against the fact that a priori FUD is also difficult to analyse and incurs costs without benefit. So, for example, Heartbleed. Everyone upgraded, $500m ka-ching, thank you very much. (OK, I have my doubts about that number too, but it's a number.) Now, we have very little evidence of any breaches using Heartbleed. What is it, one? CRA? And that one was caught. There was another recently? Hypothetically what would have happened if everyone waited a month and saved say half the cost by doing it leisurely? $250m saved! Would losses -- theft -- have risen from $0 known to ... $1m ? We're still in profit by $249m. Let's wait another month? Could we wait a year? > does the difficulty in migrating > away from a new-known-crap mistake factor into how you draw the line? Very much so. Known-crap is however a warning that we should migrate. As and when permitted. Maybe this month, maybe this year. *But we should definitely upgrade.* What happens with NIST is that they set a very aggressive timetable that forced lots of rework on CAs. Now, granted those CAs are lazy bastards who don't deserve the oxygen, but why can't they upgrade in due course? Why did they get forced to upgrade RSA1024 when it's never shown a problem, yet nobody did anything about MD5 until it was cracked? Answer: everyone was asleep at the wheel. NIST received some secret push from NSA, then panicked. Now everyone's caffeineted and drugged to the eyeballs at the wheel. One blink and everyone's in a pile up. Remember that CA that was crunched with MD5? RabbitSSL or something, well, they were only a month away from hopping onto a new root. They had a plan. Just got caught, on-the-hop, almost. >> Actually, I thought there was data on this which shows that auto-update >> keeps devices more secure, suffer less problems. I think Microsoft have >> published on this, anyone care to comment? > > microsoft updates are not the standard upon which to measure all > application updates. the vast majority don't check certificates or > secure digests at all, hence the hundreds of vectors in evilgrade that > provide a seamless path from MitM at coffee shop to administrator on > your laptop. I *wish* there was data on that claim!! > is the "not using crypto" or "not using crypto right" parts the > "known-crap" piece of this equation? Yeah. This is way more known-crap than say 1024bit RSA. > is the MitM or DNS poison dependency "low risk" enough per the data > that the "known crap" of the update itself no longer matters? I believe so. One day that might change. But for now... download stuff off the net using HTTP, it just works. Probably because of the element of surprise, the difficulty of interception for ordinary attackers, and the fact that the stuff we download is probably 1000 times more dangerous than any MITM or similar. > thank you taking the time to address these points in depth so that i > can better understand your reasoning. > > this is an interesting discussion because i arrived at the opposite > conclusion: given the reasonableness of long keys and secure designs, > and in view of ever improving attacks, the best course of action is to > solve _once_ for the hardest threat model, so that you don't rely on > past indicators to predict future security and all lesser threat > models can benefit from the protection provided. I agree. If that is the topic, let's solve it once. If you're interested in other ruminations, try this one [1]. But for legacy stuff not necessarily so. > i dream of a future where the sudden development of very many qubit > computers does not cause a panic to replace key infrastructure or > generate new keys. Ahhh... that is tough one. > where the protocols have only one mode, and it is > secure. That I agree with. > where applications don't need to be updated frequently for > security reasons. where entire classes of vulnerabilities don't exist. That I wish I agreed with. It just doesn't seem to be the case. Look at SSL -- widely believed to be strong in the 1990s, is now the embarrassment of the 2010s. We know so much more as time goes on. (Note the contradiction...) > in short, i dream of a future where the cooperative solution to the > most demanding threat models is pervasive, to the benefit of all > lesser models, now and into the future. > > > best regards, > > > P.S. part of the context for this bias is my perspective as developer > of fully decentralized systems. any peer in such a system is > potentially the highest profile target; the threat model for any peer > the most demanding threat model any one peer may operate under. the > usual "client vs. server", or "casual vs. professional" distinctions > in threat models no longer apply... Right. And, the upgrade now model also disappears because you can't change the network rules without breaking the consensus model. Oops. So, in such a domain, what matters? To take our favourite whipping horse Bitcoin, it has a great solution for double spending, a dynamic membership signature over the block, but its approach at an institutional level to platform security can only be deemed a sick joke. So, should we work on building bigger and better blockchains? (I would like to, as I personally find the PoW solution abominable except in winter.) Or, should we work on platform security first and try and keep more of the coins in the pockets of more of the people? The neat CS answers-on-paper don't necessarily survive when the people get involved... iang [0] http://iang.org/ssl/hard_truths_hard_random_numbers.html [1] http://iang.org/papers/pareto-secure.html _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
