AlyssaRowan

Simplifying the protocol, making it easier to analyse (and prove) and especially removing legacy things we know are troublesome is the main goal of the draft TLS 1.3: now already live and rolled out across CloudFlare and Chrome, and which removes such things as renegotiation, all non-AEAD ciphersuites, MD5, SHA-1, static RSA, and many of the other classic TLS bugbears which keep bearing interesting vulnerabilities.

Which isn't to say the optional (but usefully fast) 0-RTT mode might not introduce a few more, for those lackadaisical devs who inevitably ignore all dire warnings and abuse it for non-idempotent requests like POSTs (or GETs that do something - bad idea!).

But even if it's not how I would have designed it afresh (the Noise Protocol Framework from Trevor Perrin is how I would have designed a new connection protocol now) it's still a big improvement over previous TLS/SSL iterations and a drastic enough change it probably deserves to be called TLS 2.0.

I wouldn't say it's out of context, I was clearly stating my worries when this CA was discussed here a couple of years ago.

I think something should be done, but it's not my call of course. Given we do have Let's Encrypt now, I wouldn't feel in the least bit sad in revoking the WoSign certs. Anyone affected can, and should, change.

It's disappointing to see my concerns back then were well-placed, and there are clear indications StartCom's and WoSign's backends are connected together somehow?! I don't know what's going on there exactly, and someone should definitely find out.

Yes, that is what I was referring to. Of course it doesn't prove anything either way. It's simply one data-point surrounding the app, and its relevance is not clear (after all, I don't know who uploaded the screenshot, although those accounts do look like "test" accounts a dev might use?).

I think I might take a closer look: if Matt Green found this app entertainingly bad, even though I'd never heard of it before today, that makes me a little curious.

I'll probably announce if there are any clear signs, but Matt seemed to have not found any, and that wouldn't surprise me: attribution is rarely easy and caution always needs to be borne in mind as to accuracy - especially when it comes to trying to tell apart intentional awfulness (happily, rare - but not completely unheard of) from genuine amateur hour (sadly, all-too-common).

As a clever attacker who wanted a backdoored app could well just deliberately outsource it to someone cluelessly inept, for that authentic (and, incidentally, ultra-cheap) feel, there's an element of Poe's law at hand: how do you ultimately know?

I haven't looked at the APK metadata, but I certainly wouldn't dismiss that out of hand - the author is apparently from the US, but has a Türkçe keyboard on display in a demo screenshot?

Imagine a voice call, using a variable-bitrate codec, broken into small packets (not necessarily over the internet), of interest to a passive eavesdropper who cannot decrypt the content, but can observe metadata: the timing of packets and their sizes.

Feed that information into a prebuilt phoneme-in-context model trained on that codec and language, and said eavesdropper could probably reconstruct a pretty good estimated transcript - different phonemes compress differently.

There is no reason this would not work in bulk: I am under the impression GCHQ have done a fair amount of research in this area, for example.

Absolutely. What troubles me - partly why I nearly always stay the hell out of discussions like this, the other part being that it seems to induce sealiony arguments I don't care much for - is that an underlying attitude, though well-meaning, often seems to come from a reaction to the field being male-dominated: "women can (program|science|engineer|etc) too".

I don't feel that the unspoken "too" part is all that helpful. Of course human beings can do things. This isn't some kind of secret "boys' club" invasion.

For me, curiosity was the key. I saw my elder brother and dad doing stuff, and I wanted to join in and learn. No-one ever told me I couldn't: or if they did I was too hungry for knowledge, and too headstrong and precocious to listen - I can't honestly say a lot's changed about me! <g> If there's a solution to whatever problem we may have, maybe it's just that, and it's not just for girls, it's universal.

I rarely gave a moment's thought to my peers' gender because I was thinking about the important part, what I was actually doing: and for the most part, save for a couple of sexist teachers (who were - an even bigger crime - totally useless at the subject they were trying to teach) nor did they.

Quite! Some like big endian, because tradition ('network byte order'); little endian, because simplicity (current CPUs); mostly it's actually just classic bikeshedding¹.

Since X25519 and Ed25519 had already been deployed by a fair few people, all of whom used little-endian, recommending the opposite without a compelling reason would have been a bit too silly. (Upstream working groups are encouraged to consider the field elements as opaque octet strings, to try to avoid arguing the exact same point again.)

[1] http://bikeshed.com/

Indeed. One might be biased, given one was quite... um... vocal in the whole process! I personally feel Curve25519 and Ed448-Goldilocks were very thoroughly discussed, absolutely fine, and they are the final CFRG recommendations. I am quite certain of that, and I do believe we have proved that just about as well as anyone possibly can.

(I'd like to thank everyone who suffered through the whole thing. I am just a participant there, I do not speak for anyone at all except myself, and hold no special anything.)

Both of the CFRG curves are rigid 'safe' curves, with (unlike the NIST curves) solid criteria given for each and every aspect of their definition, all of which were argued in the open, and fully-reproducible parameter generation algorithms are included in RFC7748 - https://datatracker.ietf.org/doc/rfc7748/

CFRG made the decision to select rigid 'safe' curves pretty early on, so that everyone could see exact reasons why we picked what we did at every stage, in the open, and that therefore absolutely no shenanigans were afoot. Specifically, we ended up picking one curve over a near-Mersenne prime (2^255-19), and one curve over a trinomial golden-ratio Solinas prime (2^448-2^224-1) - because they're about the right sizes, and rigidly-structured in a way that makes them almost uniquely fast in software. (We voted on specific sizes, and had supporting reasons even for that.) Both curves are also very handily - thanks djb & Mike Hamburg! - both already present in the existing literature, and indeed quite a few examples of X25519 (DH) and Ed25519 (sig) deployment in particular already exist.

During the middle of the process, some people (some of whom were hardware developers involved in the selection of the "Brainpool" curves, a similar set of random prime field curves) showed up pushing for a new set of curves with random, unstructured prime fields.

CFRG didn't go that way, and we discussed that decision and the reasons why thoroughly. Mostly because the performance of curves over randomly-structured primes absolutely sucks in software (I'm paraphrasing here, but we are talking an order of magnitude difference, at least), but also because given we were even arguing about endianness for God's sake, we'd probably never have been able to agree on a sound, unbiased-in-the-face-of-future-scrutiny method for selecting random parameters in an unbiased way, let alone one that we were positive we could convince sceptical third parties about. It would appear this curve comes from the hardware developers who really wanted new random curves in any case, and have tried to do just that anyway. Good luck to them there.

The only possible advantage really with a random prime field is if some big problem exists with using elliptic curves over prime fields with a sparse bit pattern that doesn't also apply to random prime fields. We argued about that for a while (you may be detecting a pattern here...!), and the conclusion was that we simply don't know of any good underlying reason that would happen that wouldn't also pose a huge threat to random prime fields, or elliptic curve-based cryptography in general (e.g. big practical quantum computers - in which case, arguing about which elliptic curve to use would be pointless and maybe we just ought to burn our worldly possessions and go live in caves. I'm paraphrasing a bit here! <g>).

The only thing that popped up was that if one has old crypto hardware that one is trying to reheat and present as new crypto hardware with go-faster stripes, and one is trying to get better performance from it by abusing its pre-existing RSA multiplier to do your ECC maths as well (like, for example, a certain hardware developer, ahem, might do), the side-channel blinding technique there would not work properly, because it's only designed to work with unstructured prime fields as you usually see in RSA, rather than a field with lots of concurrent 0s or 1s in there. So, um, friendly reminder, as I said at the time: if you have an RSA multiplier, please don't abuse it to implement your elliptic curves. (Note: this would also present an issue if you did it with the NIST curves, which are also so structured.)

All the software out there that I've seen that implements Curve25519 appears to be at least timing side-channel resistant (this also being a goal, and why we went with Montgomery/Edwards forms specifically to simplify this, because short Weierstrass form is a bloody nightmare by comparison).

If you are tasked with designing new crypto hardware today, I do feel you'd be better placed doing what a friend of mine suggested: instead of bolting new bits on decades-old designs like most people seem to, actually go and design new open hardware (RISC-V?) and try to restore some verifiability in that. Put all the crypto in open-source, verifiable software which the user loads and verifies (a friend's prototype design just uploads the whole executable EEPROM to the host for comparison with a known-good image whenever you connect it, and zeroises the data EEPROM in hardware whenever the executable EEPROM is written by the host) - and then ship the hardware absolutely blank. Then you hopefully have one less problem, as you don't really have dedicated crypto hardware as much as a solid general-purpose microcontroller with side-channel protection. (I wonder what impact that might have on export controls, if any?) In any case, you probably also have enough problems to worry about in your supply chain already without risking becoming the next Gemalto... or, God forbid should things not go well, Apple. Just a thought there. I know several people are working on open hardware now; I've heard of a couple of dedicated hardware implementations of 25519 floating around, too.

I don't know of anyone who actually wants to use this so-called "million dollar curve". CFRG aren't recommending it. I'm certainly not. Not because it's bad. Just because - sorry, but as I said at the time - it's kind of... pointless? If you're using the Brainpool curves already, there's not really any reason you couldn't use this... but unless: a) you believe the Brainpool curves are deeply flawed somehow, enough to avoid, but these somehow aren't; and, b) you believe there's a huge breakthrough in number theory that affects structured primes but not unstructured primes or elliptic curves in general; and also, c) you believe nobody's going to show up with a quantum computer in the time period you're worried about... I just don't - personally! - see why you would bother switching. Clearly these people do. I suppose we simply disagree there, which wouldn't be the first time.

NSA themselves have used Dual_EC_DRBG (which can be distinguished from a PRF even if you don't have the 'backdoor key': it's not just backdoored and slow, it's bad - and they know that). GCHQ behaves even worse and is at this point almost entirely out of control.

In either case, I feel information assurance and signals intelligence arms really should never have been the same agency: they are roles entirely at odds with each other and do not seem to even have their own governments' equities properly balanced, nor their recommendations always having been given in good faith. So be cautious drawing any conclusions from their advice.

Unfortunately, that is not the sort of 'reform' that either government is interested in, particularly my own. It's quite depressing, really.

Emotionally, it feels to me a little like that one time a stalker bought me flowers and had them delivered to my (then-) home. I mean, yes, in general flowers are nice, but: fuck off! You can't buy my memories: a token of your affection won't make me forget what you did to me.

On reflection, the analogy bites a little closer than I might like to admit. They are stalkers, to each and every one of us. What they do is literally an attack on the entire internet (- IAB).

Please bear in mind that GCHQ are actually worse than the NSA in every way. They have essentially no "equities issue" to speak of; they operate both internationally and domestically; they have repeatedly ignored the law with essentially zero oversight, consequences or meaningful reproach; they have spied, and continue to spy, even on UK Government departments and MPs; and they are very probably about to get official powers to do mass hacking, which in typical form, they've already been doing for years anyway.

Bear in mind also that this is software that they use for analysis of data collected by spying on all of us; graph analysis software that is literally being used right now to select who to murder.

Forgive me if, therefore, I might hesitate to run any of the code of an organisation with a long history of deploying malware against innocent people.

Perhaps it's just me, but I find the - repeated - attempted unmasking of a cypherpunk nym adopted with good cause and reason for the creation of a very disruptive technology terribly disrespectful, although perhaps inevitable.

"Who is but the form following the function of what, and what I am is a man in a mask." (Well I can see that.) "Of course you can. I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is." [-V, 2005]

I actually ran a chan: so I think I kind of understand, a little bit. The one I ran is small, chilled-out, and pretty social (well, for a chan). Those two particular storms didn't really wash upon our shores much. There were however still disagreements about moderation policies (we were far from perfect, but we tried to strike a balance between freedom of speech and not being a platform for arseholes). There was someone who had their own opinions about how the site should be run, up to and including trying (albeit failing) to dox me (!); the odd DDoS attack; and, spammers trying to advertise some really horrible stuff (which I expeditiously deleted and passed onto law enforcement - anti-spam on a chan which has a very low barrier to casual entry is quite a technical challenge).

I eventually decided I simply didn't have the time to continue running it myself; the legal risk is also highly significant (I'm in the UK…), and I'm quite happy that part is no longer my problem, and it all seems to have landed on its feet. I still post there sometimes.

It's very different culturally-speaking to other mediums, but there's considerable variation between different chans, and between different boards on a chan (especially with a huge one like 4chan). It's fascinating how much the medium shapes the culture of a discussion environment. 4chan's perception of anonymity is often relevant to the discourse, in that the removal of persistent identity is thought to remove ego (and karma-whoring) from the equation. I don't think the disinhibition of anonymity/psuedonymity is necessarily a negative thing overall; and yes, lots of other, more mainstream sites, even those with "real name" policies, have unwittingly been platforms for just as bad, and worse.

Managing a site with the size, activity, and sheer wildness of 4chan must have been quite a ride. I can't imagine the full scale, but I think I get part of the general picture, and I just don't know how moot handled it. I don't think even moot knows how he handled it! That part I get. One person can only do so much, and I appreciate his efforts.

Yes, exactly. In that case, perhaps using the algorithm described in the same place as one may find the reverser's credo: "what one man can invent, another can discover"? (As can women and others, of course! I've always assumed the "man" a forgivable historical artifact there, given the now 110-year gap.)

One might tolerate an occasional hint, but please, please, please do not spoil the crackmes and such things. They are for the practice and instruction of those who seek knowledge, not those who want to merely find it. The act of seeking trains the mind in the inference of their creators' intentions and thoughts: a skill that needs to be learned, and I do not think can simply be taught.

I am, of course, biased. There is a remnant of elitism, I will admit. Before we had the web, such things used to be swapped via post, and obscure BBSes. It's quite emotional, even, to be reminded some of the old forgotten places still exist. It has been many years. Even... a certain shrine's still running, somehow. Old crackers never die: they just nop! +akr

You'll note they don't actually specify any asymmetric quantum-resistant algorithms. I'd guess if they did, NTRU or a derivative would be one they'd consider first: Security Innovation were trying to sell them that at about the same time Certicom were pushing elliptic curves. (I'm not as convinced about ideal lattices, but that's an artifact of my not being as familiar with the field.)

Pre-shared keys, as they suggest there, have no forward secrecy - which makes them great for those who really like stealing, say, IPsec keys… like the NSA. It may work with the kind of old military key infrastructure they and GCHQ have, that regularly distributes random keys from centralised, organisationally-trusted sources on specialised hardware; it is a terrible recommendation for civilians.

Interesting that they're still married to P-384 (probably the most annoying curve to implement correctly). Properly-implemented Ed448-Goldilocks is safer, and that's what CFRG are going with for the "paranoid" level.

Firstly, so - the writer is geek_slop? - let me get this straight about you?:

· You adopted a girl at some point.

· You are not law enforcement, and are not authorised by them in any way.

· You disclose, here in this webpage, that you ran a hidden service site, via Tor, explicitly for paedophiles.

· You have admitted the above, to the FBI.

· You haven't considered what child protective services' post-adoptive services might think of your doing this?

Um, I am a trifle concerned that you may have let your emotional investment get in the way of good research, or good sense, thinking this vigilantism through to its logical conclusion.

Secondly, I think I'm enough of an expert on the topic of malware to say that the software, designed to cause a privacy breach upon whomever runs it and to disguise that purpose so that they may be tricked into running it voluntarily, is definitely malware: what is technically known as a "Trojan Horse", essentially doing the same job as the FBI's "CIPAV", but worse.

Thirdly, I've spoken with law enforcement on this topic before, in the context of discussing anonymous networks like Tor. They are frequently displeased about vigilantes ruining their operations by doing shit like this - it makes the paedophiles more paranoid and careful, actively disrupting ongoing law enforcement investigations.

Fourthly, it's not valid research. geek_slop doesn't appear to be familiar with how Tor actually works, in fact, they actually list the wonderful exit nodes they got, apparently unaware that the list of exit nodes is public and by design doesn't tell you anything at all about the visitors to your site. Web crawlers (including "Dark Web" - a wording which is another sign that the author does not have a strong background in anonymous networks - it's correctly "onion site" now, formerly "hidden service") naturally find related sites that link to each other, if you're going by links, which they might have done. If they're neutrally HSdir crawling, most of them are dead (because they're ephemeral services created by a P2P chat app?). We know all that from previous research (Dr Gareth Owen, University of Portsmouth, Tor Hidden Services and Deanonymisation, 31C3 https://www.youtube.com/watch?v=oZdeRmlj8Gw ).

Finally, this crawler might in fact be the exact same "dumb crawler" I previously identified as doing repeated HSdir directory service lookups (instead of caching) while refreshing paedophile sites, causing disproportionate load on the Tor network's HSdir services and strongly skewing Dr Owen's results on this topic (if it's not yours, it's probably IWF's). So, um, thanks for that.

This protocol has no forward security; so, poorly by comparison.

I should perhaps point out that this series is based on somewhat outdated elliptic curve techniques. It's a little easier to explain these operations over, say, Edwards curves, and I believe djb's done a couple of talks at hacker conferences explaining exactly that.

In particular, djb et al has eviscerated the argument that curves generated through seeds (for example via the X9.62 method) are in some way provably safe. Anyone can perform a partial second-preimage attack on even a perfect hash, and if they know an attack that affects one-in-a-million curves, they can easily bake a seed to match it: http://safecurves.cr.yp.to/bada55.html - I suppose this will be covered in the next post?

More interestingly, especially in light of if you know that, the most commonly-used elliptic curve for ECDSA/ECDH right now, secp256r1 (otherwise known as NIST P-256 or prime256v1), claims to be verifiably random but deliberately doesn't say where the seed came from. Public questions about this haven't met with particularly enlightening answers.

What I was able to find out wasn't as enlightening as I hoped: the seed for P-256 was computed by Certicom's engineers, working with the NSA. To what end? I don't know exactly, but I gather the precomputation actually had to do with picking parameters amenable to efficient implementation via (at-the-time) optimal, but Certicom-patented, techniques. The NSA use it (and P-384) themselves extensively and seem to trust it - and they haven't backdoored every crypto scheme they've ever had a hand in (their hash algorithms still seem to be fine) - but of course, there's always going to be that modicum of doubt, and unfortunately, whether it was cooked for anything else is beyond my knowledge.

(That's apparently part of why Satoshi Nakamoto chose secp256k1 for Bitcoin instead.)

This is also part of why CFRG were asked to recommend non-NIST curves, and have been focusing on recommending "rigid" curves, based on parameters which are obvious choices which are justifiable by themselves (and have settled on djb's Curve25519 at a ~256-bit strength and Hamburg's Ed448-Goldilocks at a >384-bit strength). They're simpler and faster to implement, too. The ECDH using Montgomery form is incredibly easy by comparison; and currently we're discussing specifics of the signature scheme, which I hope is probably going to look somewhat like EdDSA if it isn't EdDSA exactly.

And to top it off, what size are his PGP signing keys? http://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html

1024-bit RSA, and 1024-bit DSA.

Please see my comment earlier today about why that's Very Bad™ in the thread on the "Logjam" attack which shows that 1024-bit keys are too small for safe use now: https://news.ycombinator.com/item?id=9577998

Come on, Simon, I know you know better than that. It really is time to upgrade.

I mean use of RSA-1024 or DSA-1024 anywhere, for any purpose, is really too small for safe use now.

By "on your keyrings" I mean that quite a few PGP keys in the wild still use DSA-1024 master signing keys with (often much larger) ElGamal encryption subkeys (as DSA was not specified for a long time with keys beyond 2048-bits).

However, DSA-1024/(ElGamal-anything) is not a safe configuration anymore - an attacker who can do a discrete-log on a highly-valued 1024-bit finite field can recover the signing key, and sign things - including software released under that key, or grant themselves new encryption subkeys of any strength.

It may therefore be a good idea to review your PGP keyrings for any master keys you trust which fit that 1024-bits and below criteria (look for 1024D, or below), as they definitely are overdue an upgrade. You may find that a fruitful search, with a few surprises still. For example, to pick one high-profile signing key that would doubtless have been interesting to Nation-State Adversaries and would have been susceptible to such an attack: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xE3BA7... ˙ ͜ʟ˙

The common safe configuration for modern OpenPGP (and upstream GnuPG's current default, I believe) is to use RSA signing keys and RSA encryption subkeys, each of at least 2048 bits - really I'd recommend 3072 or 4096 bits, as use of PGP is not as performance-sensitive as TLS and there is no forward secrecy, so I wouldn't really recommend going much below a ≈128-bit workfactor (equivalent to ≈3072 bit RSA or ≈256-bit elliptic-curve).

Edward Snowden trusted RSA-4096 signing and encryption keys with his life, and that obviously worked out fine for him at the time.

Seconded. Group 14 (2048-bit, ≈112-bit workfactor) or another safe 2048-bit or greater prime (such as ffdhe2048, or ffdhe3072 @ ≈128-bit workfactor) will do fine for now. You don't need to roll your own safe primes. As per the paper: "When primes are of sufficient strength, there seems to be no disadvantage to reusing them."

The problem with reusing them is of course when they're not strong enough, and so if an adversary can pop one, they can get a lot of traffic - and as I've said for a while and as the paper makes clear, 1024-bit and below are definitely not strong enough. Anything below 2048-bit would be a bit suspect at this point (which is precisely why the TLS Working Group rejected including any primes in the ffdhe draft smaller than that - even though a couple of people were arguing for them!).

If you're still needing to use 1024-bit DH, DSA or RSA for anything at all, and you can't use larger or switch to ECC for any reason, I feel you have a Big Problem looming you need to get to fixing. Custom DH groups will not buy you long enough time to ignore it - get a plan in place to replace it now. We thought 1024-bit was erring on the small side in the 1990s!

I concur that the NSA's attack on VPN looks like an operational finite-field DH break - I didn't realise that two-thirds of IKE out there would still negotiate Oakley 1 (768) and 2 (1024), but I suppose I didn't account for IKE hardware! Ouch!

Their attacks on TLS are, though also passive, architected far more simply and more suggestive of an RC4 break to me as there seems to be no backend HPC needed - ciphertext goes in, plaintext comes out. Both are realistic attacks, I feel, but RC4 would have been far more common in TLS at the time than 1024-bit DHE, and although 1024-bit RSA would be present many likely sites would have been using 2048-bit, so naturally they'd go for the easiest attack available. (That gives us a loose upper bound for how hard it is to break RC4: easier than this!) I also don't think the CRYPTO group at GCHQ would have described this as a "surprising […] cryptologic advance" from NSA, but just an (entirely-predictable) computational advance, and (again) lots of people in practice relying on crypto that really should have been phased out at least a decade ago. So there's probably more to come on that front.

Best current practice: Forget DHE, use ECDHE with secp256r1 instead (≈128-bit workfactor, much faster, no index calculus). You can probably do that today with just about everything (except perhaps Java). It will be faster, and safer. And, we know of nothing wrong with NIST P-256 at this point, despite its murky origins.

Looking forward, Curve25519 (≈128-bit) and Ed448-Goldilocks (≈222-bit) are, of course, even better still as the algorithms are more foolproof and they are "rigid" with no doubts about where they come from (and in Curve25519's case, it's even faster still). CFRG is working on recommending those for TLS and wider standardisation. You can use 25519 in the latest versions of OpenSSH right now, and you should if you can.

It's not particularly surprising to the IETF TLS Working Group either, which is at least partially why https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe... exists.

Minimum 2048 bits, please note. 1024 is not safe - and has not been for quite some time. GCHQ and NSA can definitely eat 1024-bit RSA/DH for breakfast at this point (although it does still take them until lunch).

(Those of you still using DSA-1024 signing keys on your PGP keyrings should reroll RSA/RSA ones. I suggest 3072 bits to match a 128-bit workfactor given what we know, but 4096 bits is more common and harmless. 2048 bits is a bare minimum.)

Smart cards/hardware tokens try to not make themselves easy targets, and many such microcontrollers have attempts (of varying success) to defend against limited degrees of physical access and make attacks evident. But in any case, given sufficient time and resources, the attacker will always win.

Bottom line: It depends largely on who stole it and for how long - however, if someone knew enough to target stealing your hardware token/smart card, you are under targeted attack and your key's probably toast: revoke it.

I would also gently caution that the elliptic curve routines provided by NXP should not be used over special prime fields (elliptic curves that are fast in software, i.e. just about everything except Brainpool) as they abuse the large (RSA) multiplier whose side-channel blinding was not designed for non-random fields. (Unless they've rewritten it since I last saw it?)

As I've said before: look out for side-channels!

The RF/electrical/other emissions from general-purpose CPU cores and their supporting circuitry tend to have major features with good correlations to execution timing and pipeline stalls, which they are not designed to treat as secret.

This is one reason why crypto implementations should be written using techniques that avoid table lookups or branches based on secret data: another is of course that the resulting timing variations may be visible on another core, over a network, etc.

Systems which treat the TSC (etc) as such secret data that they effectively seed a PRNG with it should therefore be treated with a very considerable degree of caution considering just how (literally) squeaky some cores/boards can be about leaking it. Further research is needed.

Regarding your first point, there's some confusion between active exploits (i.e. botnet infections, etc) and passive intercepts. They are indeed cautious about using exploits and botnet platforms (I don't think that makes any of it right).

Absolutely NSA & GCHQ should be able to crack RSA-1024: it is not magical, and it is definitely well within their budget, but it still isn't particularly cheap timewise, so unless something is really super important, it's not going to join the crypt attack queue for supercomputing resources, and they would not be waving it around too widely.

By comparison, we know RC4 is toast. We have a rough sketch of the attack (though please correct me if any of this is wrong): passive; returns plaintext from ciphertext, with either no or a few bytes of known plaintext header at most; runs in software on blades and other places at mass-intercept scale in real-time, so we have an upper bound on its complexity (and it's very low compared to RSA-1024).

We don't know many technical details about the attack yet. RC4 is a peculiar beast, quite unlike semi-modern or modern ciphers like AES or Salsa20/ChaCha20: huge state; crappy diffusion; several known weaknesses, but no public break yet. I can't wait to find out more: this is one of the few areas NSA actually are ahead, as the public sphere definitely know RC4 is too wobbly to use, but still quite some way off decrypts of it. Whatever technique is used may well not be applicable to ciphers of a more modern design (but what about Spritz?).

If you've been using RC4, ever, this should give you pause. Think about what's ever gone out using it. Think about what someone could have recorded - likely did record. Do you need to be changing any passwords?

If you're still using or accepting RC4 anywhere for any reason (ahem, Mozilla, Google, Microsoft?), for heaven's sake, get your arses in gear. You're not beating the attackers, you're now only limiting the damage. Given the RFC and everything, and the internal discussions you've been having, I personally would be loathe to consider any further delay ethical before action. Please do remember Holmes' Law of Reverse-Engineering: what one can invent, another can discover.

Directly related, if you've been keeping up: RC4 is considered weak crypto and, now that CVE-2013-2566 has a base score of 4.3 (i.e. more than 4.0) and RFC 7465 has been published forbidding its use, offering or accepting RC4 should be considered an automatic fail by any PCI compliance scan.

Most of the tiny percentage of sites which only offer RC4 that I've found have been financial. They may not all necessarily fall under PCI themselves, but this is probably about all we can do.

The next round is on the browsers: IE, Chrome and Firefox turning it off completely (it's already only offered on fallbacks for IE, and recent Firefox; Fx nightlies only offered it on a whitelist of sites which still needed it but I don't think that change made it to release because it broke sites, although obviously breaking sites which will only use weak ciphers is unavoidable).

Now this is out of the way, all we really need to do is set a flag day and throw the switch.

If you're still using or offering RC4 for some reason, for heaven's sake stop, because you're going to regret it if you don't. XP has been out of extended extended support for more than a year now, and even unsupported early Android versions have alternatives.

Grandparent: Yes, but they are specialised ones, not general-use ones.

Parent: Impossible? It's far more nuanced than that. Do you think that's real time that's passing?

Redpilling and bluepilling (as it's become known since about 1999, thanks to The Matrix) is an arms race. In a game theoretic sense, bluepilling "wins" when the environment is within the attackers' control, redpilling "wins" when essential parts of the target aren't (e.g. on the internet, only an oracle), but of course back in real life we find ourselves asymptotically approaching that because usually, neither plays perfectly. Bluepilling wants a more seamless virtual environment; redpilling wants to find the seams and chisel away at them.

You could be referring to a number of approaches, but there can be serious complications. Here are the two big factors, especially as the actors get more advanced:

1. False positives. The tweakier you make a anti-debug trap, the more likely it's going to fire on real hardware. There is really nothing you can do about that, especially on the PC where there's such a massive variation of real hardware, each individual piece with its own errata. The question is the impact that has. False positives are often not a really big deal to those hiding advanced malware - they'd often prefer to skip those boxes just in case, no big deal - so they can (and do) use much crazier techniques than say anti-debugger routines in copy protection, where a user will care about a false positive because the stuff they bought won't run - and then they call you to fix it, or when you won't, someone like me to fix it, and then in your nightmares you're up against:

2. Simulators: bluepilling's finishing move. Emulators that work at the gate level, errata and all. Last I heard, one vendor doesn't even do physical draft tapeouts anymore - they've got a supercomputer, and they use it. You can simulate a 6502 in your browser in Javascript - http://www.visual6502.org/JSSim/ - but doing it to a big x86 (even an Atom) takes quite a bit more oomph. Oh, and masks. But it's a viable approach, with a few tricks. Which you might not need, because:

3. These routines look really distinctive in a way you cannot disguise. You expect to see them in advanced malware or copy protection; it's sometimes enough to get a signature all by itself. And of course, they are just code. They can be deadlisted, rewound, replayed, patched, modified, and everything else.

It's just another trap: when the attacker can read your mind, make 1+1 equal 0x90, and time flow backwards, nothing is impossible. Just harder.

It's definitely worth looking into - TextSecure's Axolotl is best-in-class for dealing with text messaging or other scenarios with occasional one-shots.

If you want another, simpler transport that works better for more connected scenarios, like this one, ask trevp who did that: he has a very promising-looking one in the design phase.

If I can give any advice: security doesn't make a good afterthought, especially when encryption was the first word you mentioned. It's a foundational feature; treat it as one. Pick primitives that make the best, most solid foundations you can get, and do your best to make sure you can rely on them. As for the rest, extensibility needs careful thought: it can be easy to extend yourself into vulnerabilities.

Best of luck. You have an interesting project. I might keep an eye on it.

That's the big blocker - but, without wishing to be too mean to NXP (sorry Joppe!), the A700x MX51 microcontroller used in the YubiKey Neo is pretty old. Really, most crypto chips are at their core: they almost always just make them out of old ones with new bits glued on to (reasonably) try to reduce (high) NIST/etc certification costs. (Seriously, it's still carting a hardware DES implementation around.)

I believe it has a 2048-bit multiplier with a particular (patented?) form of blinding to protect against side-channel attacks. That's used for RSA; it can't do 3072/4096 bit RSA keys without tricks as it stands unfortunately.

The existing NXP ECC implementation is also not in JCOP's applets by default, I think? From what I saw, it (ab)uses the RSA multiplier. That can go up to 320 bit curves in theory without running out of scratch space, and is a generic implementation of prime fields over GF(p), so you'd think it'd be able to do some operations on Curve25519 fine in principle.

And it can, but in my testing it did what I thought it'd do, and leaked side-channels when used with the NIST curves and djb's curves, because the blinding on the RSA multiplier was simply not designed to cope with the regular structure of the special prime fields that most elliptic curves use. And the performance of random prime fields (like Brainpool) in software is awful, so no-one else wants to use those.

You've also got the problem that the existing implementation there can only do ECDSA (not the EdDSA used by Ed25519) and doesn't have SHA-512 around, too.

A pure software implementation that avoids using the RSA multiplier would be much safer, and I think in principle would be able to do the other CFRG favourite, Ed448-Goldilocks, as well. That is what some HSM vendors are doing. It'd be a very tight fit on the NXP A700x, however. I'll leave that to NXP, if they want to.

I myself want an open crypto chip, not one that still needs blobs in 2015. And I've seen a few movements in that direction.

Trusted filters (such as ad blockers, parental censorware, network monitoring) must to be inside the trust boundary to be effective. That is the best way to ensure they are not imposed en masse against people's will.

In-path filters outside the trust boundary are, I'm afraid, the very first casualty in our efforts to mitigate the threats of nation state adversaries, as they resemble the attacks used there too much to survive. I, for one, will not mourn them.

>The case of a leaker getting her hands on 2 copies is however highly unlikely.

I'm not so sure about that. Some groups used to have a general practice of always getting at least two distinct copies from a supplier to avoid burning sources. And I doubt they just averaged either, but detected discrepancies and manually eliminated potential areas of interest. A few releases of cracked software were even actually compiled afresh from source, or were object code before a wrapper protection was added. Some suppliers were developers themselves, who weren't always seeing eye-to-eye with their publishers.

Of course, perhaps the 'race' to be first has all but eliminated this from modern practice. I couldn't say.