AlyssaRowan

With TLS, it's not safe not to! Let me explain:

Diffie-Hellman requires the group order to have at least one large prime factor: if it has only small prime factors, Silver–Pohlig–Hellman could recover keys, and that'll make you a sad panda. The easiest way to ensure this is to select a Sophie Germain prime q with 2q+1 also being prime (a "safe prime"), of about the right size. Any base g can then be used - almost always 2 - which then generates a subgroup of large prime order q, problem solved.

The problem is that testing for safe primality is way too slow (as you may have noticed while running openssl dhparam!) for TLS clients to test DHE parameters presented to them. So… they don't. The risk is (I'm not totally clear if the Finished master-secret might prevent this, but there certainly isn't as much transcript hashing as I'd like!) an attacker could perhaps trick TLS parties into accepting bad parameters: too small; small factors; hell, maybe even composite.

The solution is currently in draft, and is to have carefully-selected, standard Diffie-Hellman parameters that are known safe primes, starting from 2048-bit and going up (don't use <2048-bit, just… don't - please don't use 1024-bit!), using essentially the same negotiation as that used with the supported-curves extension. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-f... It's the same approach used by many other protocols, including SSH and IKE.

I gather TLS 1.3 will remove the ability for server-defined Diffie-Hellman parameters completely for this reason.

However, ECDHE is strongly technically superior to DHE: ECDHE using secp256r1 is at around ≈128-bit workfactor, equivalent to broadly ≈3072-bit DHE, but is much faster and smaller and doesn't have these problems (it can have different problems, but not these problems!).

And coming up soon (via the CFRG sausage-machine) hopefully TLS will soon have djb's Curve25519 (the curve, and the key agreement function now known as X25519), which is roughly the same ≈128-bit strength but really fast - and much simpler to safely implement, even in constant-time. You probably want to use that or ECDHE, not DHE, which is a little hairier than it sounds. Indeed, quite a few people are using it already (notably OpenSSH).

Agreed there: if Signal won't do SMS, they shouldn't be catching SMS intents, or they might get invoked when, for example, there's no data. (Of course, there's scope for disagreement here. SMS and particularly MMS are horrible, but sometimes horrible is all you've got.)

I don't know - anyone got time to review the source? - but if they're only doing SMS, they might not need it; after all, SMS is already 'push', and it was only needed for push notifications for the data channel.

The underlying reasons are actually pretty sensible.

Signal (as it will be) can't deliver encryption via SMS on iOS due to platform restrictions. Neither can tablets or computers normally send SMS messages. (To say nothing of metadata risks, although TextSecure cannot address that without a decoupling layer, like Tor, and in any case low-latency low-bandwidth mixnet messaging is very hard versus nation-state adversaries with traffic correlation abilities.)

It's also clear that voice and video can't be delivered well or at all by SMS/MMS, and that MMS in particular is a huge pain in the arse.

However, users who have limited/no data plans are up in arms. Whole bunch of 1-star reviews. Clearly quite a few vocal users (not necessarily users in regions you might expect) liked this feature, used it, seemingly needed it. I know that sometimes when travelling even I'm out of data service, but within SMS service.

So it may be that a fork does make semantic sense here. Signal will eventually deliver cross-platform best-in-class secure messaging, group messaging, voice/video/etc - features which cannot be delivered by SMS - and SMSSecure could deliver encrypted SMS messages for users on the Android platform (only).

No, I find that pretty damn hard to believe. Especially considering where it's coming from.

You don't accidentally do anything with an unconstrained CA key chained from the public root: that is a serious piece of data that can MITM anyone worldwide so at the very least should be under lock and key at all times! [It definitely shouldn't be plugged into any network: it should be locked in a Faraday-caged safe, on a dedicated hardware device, ideally under armed guard. You sign your operational CAs with that.]

CNNIC fundamentally broke their CPS: it has no intermediate programme, yet it intentionally misissued (at least!) one CA anyway. That is easily enough to get them pulled from everywhere, in line with current practice.

It's a pretty good demonstration of why we need something like CT, and (IMO) a public list of all intermediaries ever issued from any active CA.

Although in those, they targeted using pretty close selectors and the payload was browser exploits with a very advanced dropper from what is essentially a big, supported modern malware construction kit. GCHQ used the same technique, but leveraged it to do a very different - and actually far more intrusive and destructive - thing.

This, by contrast, is a widely-targeted, fairly dumb DoS payload - but of course, not every DDoS has to be smart! Scale does all the work, and dropping malware, albeit relatively benign malware, en masse like this yields a lot of scale. This is particularly bad when there are potentially more personnel adapting it to evade defenses than there are personnel trying to defend against it: bravo to the GitHub security team!

And of course, by the time we got to the Pentium Pro - and more or less everything ever since - we ended up with a hybrid pipelined superscalar design which takes advantage of the legacy of support (and, compared to VLIW, tight instruction coding), but as part of the decode pipeline, translates that to RISC µops inside with microcode.

The Transmeta Crusoe was a particularly notable (if not particularly successful) case in point, which brought that layer a little more visibility than most, although in all honestly, was probably mostly well-known for having been Linus Torvalds' employer.

There never was a particularly bright line between RISC and CISC, and it's only gotten blurrier with the decades as the two paradigms stole good ideas from each other.

That's not to say there isn't the occasional throwback, sometimes for a good reason. I've got an adorable little slug of a 'transparent' microprocessor on my desk which I hope sees the light of day sometime (when it actually works, because I've bricked it - first time designer == way too many errata! :P) because it's got some fun ideas for trust, like the host being able to directly read (and verify) all the software it's running.

A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how.

I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.

The actual detail/technology, more or less. There's nothing China did this last couple of weeks that the Five Eyes' QUANTUM setups aren't already tooled to do: QUANTUMINSERT can be used to inject the JavaScript, just change the selectors and the payload. Indeed, I believe this capability has already been privately trialled by GCHQ. (QUANTUMSLAMMER, was it?)

It is not advanced technology: TCP just has no protection here. Anyone capable of in-path packet surveillance and in-/by-path packet injection on a significant link can pull off this exact same attack. You could co-opt a router to do it: GCHQ have.

We're going to need pervasive (authenticated) encryption to defeat it.

No, you don't need a HTTP request to upgrade: it's done as part of the TLS negotiation with ALPN. No extra round trips, and TLS 1.3 will probably go even faster.

If you're not using TLS, despite things like the China QUANTUM attack on Baidu against Github, I don't know what to say to you, except most browsers already chose to refuse to speak HTTP/2 over cleartext, because using cleartext in 2015 is a bad idea in almost any scenario.

It does not. Duplicity can use it, however, which does client-side encryption for you, as mentioned above.

Well, duplicity can usually use it. You may have connection problems, because hubic.com is TLS version-intolerant; it'll only use TLSv1.0 (and does NOT negotiate with TLSv1.1/TLSv1.2) with AES-256, AES-128 or 3DES, with RSA and no forward secrecy.

Not what I wanted to see.

That's odd, they substituted the (Double) Gloucester and Cheshire cheeses - are they not possible to obtain in the US?

Looks like a tasty recipe. We might try that (although a member of the Household is lactose-intolerant, so I'd better get the lactase capsules ready if we do).

I've always added eggs. Also a bit of Worcester sauce, which is worth trying almost anywhere you get cheese or need a savoury flavour (providing no-one's vegetarian/etc).

Make that cheesecake and I'm in.

No-one who runs a server which only accepts RC4 (!!) with no forward security, and SHA1 signatures, in 2015, should be giving security advice.

My daily driver browser has RC4 entirely disabled. This is one of the more amusing won't-connect sites I've found.

I feel like I want to test what happens if you put values like "", false, " ", 0, an empty array, etc etc etc in front of ??.

Because, you know, this is PHP.

Yes, as long as you have a sound random source (whitened via a good CSPRNG, if you're not using real dice), and a correct unbiased bijective mapping to the wordlist (not just a biased modulo), then it is secure.

A friend of mine already wrote a generator for his own use along the Diceware lines, which probably I don't think he'd mind me linking, although it's a work-in-progress: https://qrmn.uk/dwr/ - you can feed it a custom wordlist, too, by just feeding it a textfile and it'll digest it.

(It's fairly easy to read, uses getRandomValues, a simple CSPRNG of my design based on djb's ChaCha20, and seems to do the selection correctly, I think: the trials and tribulations of JavaScript crypto, potential TLS MiTMs, the attack surface of the browser, etc are of course well known.)

The trick to memorable passphrases seems to be getting a really good wordlist. The standard ones of 7776 words fit well with 5d6, but don't cut it well for heading to the 100-bit range, and some of the words are strange. A 19973-word list would allow for 7 words to be 100 bits. To get that to 6 words, we'd need 104032 words in the list, which is unlikely to be a memorable English corpus. If we're willing to have 100 bits = 8 words, 5793 words are sufficient.

If anyone knows of any particularly nice English corpora that are free for use and would work well for this, I'd appreciate a tip.

A pox on those with "you-must-have-a-capital/symbol/dingbat" (it doesn't help!) or short maximum password lengths (I'm looking squarely at you, Microsoft Passport/Windows Live).

Well, Zendo is not open source, and it uses "one time pads" - classic signs of snake-oil cryptography (Vernam ciphers are information-theoretic secure if done properly - but impractical for almost every use case, because they really just amount to secret-splitting - and the most fragile crypto primitive, because if you do even one thing slightly wrong, they're awful). It also doesn't look to be forward-secure, unless I'm misunderstanding something from 2 minutes of research. And it needs manual setup.

So very poorly, I'm thinking.

TextSecure/Signal can present/scan a QR code in-person to do a public key fingerprint verification that way.

I'm sticking with TextSecure/Signal, thanks.

The optical method is also quite smart, if you happen to, say, have an activity LED wired to a bus without much of a filter in between. LEDs switch faster than you might have thought¹.

This kind of thing is intelligence-agency home turf; they have decades of experience, not necessarily relating to computers.

[1] Joe Loughry and David A. Umphress [2002] "Information Leakage from Optical Emanations." ACM Trans. Info. Sys. Security, Vol. 5, No. 3, pp. 262-289 <http://www.foo.be/docs-free/tempest/optical_tempest.pdf>

I wouldn't say that's true, but I am unable to comment further.

Longer than a year. RLD released a proper after 424 days.

Inquisitive minds wanting more information should be directed to StarForce.RE.Tools.ReadNFO-RELOADED - http://www.glop.org/files/rld-sfrt.rar (sorry for the hotlink!) - for a detailed technical analysis published concerning the StarForce 3 protection. A fine piece of work, if I may say, though I shall not identify the authors.

StarForce 3 was really quite intrusive, including secretly-installed ring0-access device-drivers. Flaky and damaging to the security of your system and very widely complained about.

I would not say such a monstrosity is an achievement UbiSoft should be proud of: indeed, they actually apologised, although I would not say they were genuinely sorry in any sense.

I would like to thank the developers working on the actual game, of course. I feel sorry for them that the publisher had such strong opinions about that.

Check the bottom of the screen (you may have to look carefully). You're looking for something like Sign in without a Microsoft account (not recommended) -> Local account - there's a similar flow when creating a new user.

It is there, but it's (obviously deliberately) hidden behind one hell of a UX antipattern. I guess they want people to use Microsoft accounts more than they want people to be able to use Windows.

And Microsoft accounts are still stuck using only 16-character passwords (!), and I'm not completely clear on what does and does not get 'synced' - if it's my %AppData%, I don't trust SkyDrive, so that's definitely out.

Hmm. Could be the mailbox communication for VPU<->CPU communication timing out? BCM should be able to repro and fix that. They could also be able to make enabling HYP mode less of a hack.

As for the lack of an accessible GIC, the VPU runs ThreadX, which has a software timer infrastructure: no reason I can see they couldn't expose those if they wanted.

I'm not sure what he's alluding to. It may be that they've done simple loudness normalisation instead of one of the more preferable, advanced techniques, like ReplayGain 1.0, R128, or BS.1770 (/ReplayGain 2.0)?

It's kind of confusing. BULLRUN/EDGEHILL projects are umbrella cover terms: Secure Communities of Interest regarding general access to NSA/GCHQ (respectively) efforts to defeat network communication technologies such as TLS and IPsec, not particular individual cryptanalytic attacks, vulnerabilities, backdoors or techniques.

I think you want the PICARESQUE ECI compartment, specifically (TS//SI-PIQ). NSA are said to have had a "cryptanalytic breakthrough" which "surprised" GCHQ some years ago. Specific operational details are currently undisclosed, but there have been references to PIQ (PICARESQUE) blades at locations of some TEMPORA full-take feeds processing the (72-hour) network intercept ring buffers in nearline and providing passive decrypts on-site to the backend via crypt attacks. They have only one-way access, and aren't active/QUANTUM (MoTS/MiTM) attacks, or PAWLEYS (key-stealing) attacks. The prevalence of RC4 within TLS (and other protocols) at the time, that it apparently directly provides plaintext decrypts, and RC4's relative weakness, suggest it as the most likely candidate for attack.

So, no, don't use RC4! …not that I've had the opportunity to reverse any of these blades recently, you understand…

So's NULL, but that doesn't mean you should use it.

No! I know I mentioned this just yesterday - in the thread in https://news.ycombinator.com/item?id=9207824 - but this is yet another new attack. And they're going to keep coming, and there are passive attacks…

Like I said yesterday, if you're using RC4, stop now, and go back and consider what may have been compromised by attackers recording ciphertexts and cracking them when it became practical.

Really: no. There is nothing "very sudden" about RC4 exhibiting biases indicating it is weaker than it should be: ask any cryptographer. The break that's about to be disclosed in March is simply a new practical twist on a weakness published more than 10 years ago!

A lot of sites got bad advice. (One might wonder about whether all that advice was truly given in good faith. Maybe.) The real fix for BEAST and Lucky13 is, and always was, to use TLSv1.2 with AEADs like AES_GCM, or CHACHA20_POLY1305. So do that.

On the world wide web, jumping to Hulu, an explicitly US-only site that blocks all of the rest of the world, is a bad decision overall.

I guess everyone else will be pirating that new series if they want to watch it. He's made that choice. Sorry, FreddieW, whoever you are, on one level I kind of hope it doesn't work out for you: balkanisation of the world wide web is not really something I want to encourage and thrive.

…how about a new twist on an old partial plaintext recovery attack that can actually steal passwords in the wild, given a cute name and a logo, being demonstrated in 11 days at Black Hat Asia 2015? I think that might help speed things along a bit.

https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-a...

If you're managing a system, do what the RFC said: turn off RC4 on all the servers and clients. You were warned!

Or at least, on other peoples' subdomains.

Misconfiguration. All RC4 ciphersuites are explicitly forbidden by RFC, and considered a severe vuln by CVE. https://tools.ietf.org/html/rfc7465