qrmn

I think it might have rolled out already. Turn on Developer Mode in Windows 10 Anniversary Edition, and ssh to port 22 with a valid l/p?

Doesn't look like you even need to install WSL.

More permanent than a van. (Not that unusual for an embassy to be spied on!)

It might have something to do with the IMSI catcher installed more or less across the road; hard to hide those, they broadcast, and that one is not particularly trying to be stealthy.

Respectably, no tool - be it I2P's garlic routing, Tor's onion routing or anything else - could ever provide "complete untraceable anonymity"; that is a huge (and potentially very harmful) misunderstanding of what these techniques can do, I strongly encourage you to learn more about them to correct that misconception.

Both projects have designs which have inspired each other and have relative advantages and disadvantages. Technically, I like I2P, but I accept I may be somewhat biased there. Practically speaking, Tor has a much larger anonymity set because it is far more widely used and receives more support, with very well-established volunteer outproxies. I would never criticise anyone for contributing to either: Tor in particular has the widest practical impact of any tool in this space.

This distributed random idea is a very impressive achievement; I'm glad to see it work in the wild! Congratulations.

I'm not sure what you mean about "stigma". Any reasonably effective solution in such a politically-charged space as the anonymity and privacy of human communication is likely to become controversial to some degree.

Absolutely. I built a concept that essentially did that.

Separated program and data memory with only one executable. USB host would get (in hardware) an outright memory dump of the program memory on connection, so it could hash it/compare it to known-good firmware. If you flashed the firmware the data memory should get wiped, and if you flashed it with anything the driver didn't know as a good build, unless you manually whitelisted it, you'd be warned.

That seems like a better approach to me. (It turns out I really suck at designing hardware, let alone secure hardware.)

Doing the same kind of general thing with, say, a RISC-V microcontroller and trying to secure the RAM seems like a generally fruitful possible course of action? Let's see how Lowrisc turns out.

This is a hash function (as used in hash tables/Bloom filters and so forth), but it is not a cryptographic hash function. It is designed to be very fast for things like table lookups, but it is not designed to be strongly resistant to preimages, second-preimages, or collisions. Don't use it for security-relevant purposes.

I think BLAKE2 is probably the fastest and best cryptographic hash function you're likely to see for the foreseeable future?

I've experimented with doing this kind of thing myself, especially with servers where I don't have ready access to the console and where the provider doesn't offer custom ISO support and I wanted a clean (and/or customised) install, perhaps of something not yet supported.

While I did have some success with in-place install shenanigans, I eventually settled on creating a customised install ISO for the distribution I wanted (with a script to have it automatically listening for remote shell connections, and so on), using isohybrid on the ISO (which makes the ISO's first sector also a bootable MBR), and then simply dd if=install.iso of=/dev/sda - right over the top of the partition table and everything.

It's inelegant, to say the very least, but it works just fine! I'm pretty sure I saw that technique used a few times during Twitch Installs Arch Linux, during the more exotic segments when some joker hijacked the effort temporarily by installing Windows 95, and TempleOS, and so on.

XML was probably a mistake. Strong, deniable, end-to-end encryption should be mandatory. The Axolotl ratchet is the current state-of-the-art: maybe it does asymmetric things we don't need, or maybe that's helpful.

Looking forward: metadata protection. This is a much more difficult-to-solve problem, but existing tools such as Tor are partially successful.

As far as I'm aware, Yubikey 4 and Yubikey Nano 4 can do 4096; the older ones like the NEO can only do 2048.

Not that 2048 is flawed as such: it's still north of 100 bits workfactor at the moment, as far as I gather. 3072 would be equivalent to about 128 (similar to the EC algorithms secp256r1 or Curve25519), and 4096 is some extra insurance on top. (As a benchmark: Snowden used 4096-bit RSA keys for GnuPG.) Anything bigger than that could introduce OpenPGP compatibility troubles.

All of these are secure when correctly implemented. (Yubikey use NXP chips. I don't have much to say beyond that, I haven't audited them.) All of them will fall to Shor's algorithm on a quantum computer of sufficient size, but we're not likely to have one of those for a good few years, if they're possible.

Sybil is a real pain, and HashCash (via I2P, which had it as an anti-DoS option) was the first obvious attempt at a solution that worked. It would be better done with Argon2 now, but it still burns coal and is a bet that evil nodes don't have more power than all the good nodes put together - it seems we aren't always going to win that bet.

Will proof-of-stake would be any better? It doesn't feel as suited to things other than currency to me, because: what value does the deposit have? We'll see how it turns out when deployed, it's hard to predict how people will react.

There's a surprising amount of heat in the field now. Lots of activity, like this interesting work, some very strong opinions. Please don't eat me! I'm quite happy to leave it be and move onto other things.

I do have an "invite" prompt on my SMS contacts that don't yet have Signal: "Invite to Signal: Take your conversation with %s to the next level.". Perhaps it's a function in the beta version that isn't in the live version yet?

I haven't seen a message with a double-tick that's been dropped yet, at least not on a recent version. It can sometimes behave poorly with Android battery-saving mode - however, so does plain SMS. Turning off sync is part of the actual point of battery-saving, but conversely, I never want to not get messages. That's arguably Android's problem, not Signal's. Still, it uses GCM, so at least there's hope for the deep sleep (which I haven't tried yet).

Automatic contact discovery is tricky, but the beginnings of one potential solution is I think explored in agl's Pond, using pairings on BN curves?: https://pond.imperialviolet.org/

To a point, so is offline messaging. Distributed datastores in general do that kind of thing - there are old implementations over Freenet in particular, and GNUnet as well and other things I think. The robust part is harder: if the client is offline, where's the disk space coming from? Volunteers' (nodes') cache? That needs to be opaque, and so do lookups. What's to stop spammers flooding the network? (Spam, and denial-of-service in general, is a Hard problem to deal with in general even in distributed systems.)

They're not among the hardest problems. Pseudonymity is a huge challenge as the latency gets lower against traffic correlation attacks, and a secure messenger is most definitely up against the kind of threat model that can and will try to pull those off in the wild. Perhaps mixing high and low-latency traffic may help, although it's going to need to be very carefully analysed how much (I believe I2P's design can do that, although I'm not sure if jrand0m ever implemented it in the router).

Impossible is a strong word - one prefers to reserve that for provably doomed problems like DRM - but several common, simple paradigms do present an unexpected technical challenge, or even an open research problem, or need to be expressed slightly differently to be practical, in a distributed, privacy-preserving, untrusted-server kind of model.

For example, paraphrasing quite a lot - uniqueness of names requires ordering; ordering probably requires consensus; consensus has a Sybil problem for which some kind of countermeasure is needed. So a namespacing problem that seems simple, and is simple in a centralised/trusted context, may only be practical to solve with a blockchain-like structure with a computationally-heavy proof-of-work in a distributed trust architecture. Even that may still be vulnerable to attacks from someone who can outcompute the rest of the network: and a Nation State Adversary (as a friend snarkily puts it) may actually have enough budget to try that. There may be another way, but maybe not another way that satisfies all the security requirements or that would survive an attack. And there are still other niches you need to worry about, like homoglyph attacks.

That's a long way to go just to make sure that there aren't two ~bobs! So you end up thinking, maybe it's better to find another way that ~alice knows she's talking to the right ~bob? Then you have rephrased your security problem as more of a UX problem: how do I try to avoid impersonation? - which is perhaps more practical to solve another way. [Edit: Also, now your users won't have to fight over who gets to take ~bob first. This may or may not be an advantage, depending on how you feel about username exclusivity.]

It's going to require a lot of hard work to solve this type of problem comprehensively; in the meantime, Signal does more or less the best we can do practically right now, and there's a lot of value in a practical solution that's best-in-class, works and millions of people can just pick up and use now.

I wish that were true, but honestly, plaintext isn't fine for anything at all in 2015, whether authenticated, important, public or otherwise, whether the network is the internet or a LAN.

HTTP sites have had attack scripts injected into them by nation-states, used to DDoS others on a massive scale - and that capability, and the desire to use it, is unfortunately proliferating rapidly.

Unless you want to be part of that problem, you're going to have to go HTTPS on everything - cat videos included - no matter how important or unimportant you think it is. I really wouldn't be surprised if tcp/80 goes the way of tcp/23.

On a brighter note - the speed difference is negligible with modern cryptography, and as others have mentioned, TLS 1.3 is developing handshakes with less TCP round trips. It's possible that a future protocol (taking into account what's been learned by Google's QUIC experiment) may deliver faster handshakes over UDP if possible to avoid the TCP handshake overhead - there's energetic research in that area at the moment.

I just use Diceware: https://qrmn.uk/dwr/

(With thanks to Alyssa Rowan for the CSPRNG design. Public domain - feel free to copy it.)

For really important stuff, actual dice just to make sure.

This is a very solid point. We already had an open cryptographic competition to select a password hashing standard, and we have a winner: Argon2 is being developed as a new standardised password hash (i.e. slow-hash).

If you're going to introduce a new one, it should go through at least the same level of cryptanalytic scrutiny before anyone uses it.

I used it. It's not as fast an approach as it sounds; you want to do hitbox collision first. But if there's a better way to really do pixel-perfect collision, I couldn't figure it out - maybe subdividing hitboxes would have been, but how does that work when the sprites change? I always thought of plain old hitboxes as being unnecessarily cruel - the player can't see them - but if you were on the NES, you probably wouldn't have CPU time for much of anything better.

Fortunately, I was on something less basic. Unfortunately, I was working on a bitplane mode (for my sins); the CPU didn't have a barrel shifter (so, for speed, one needed to store pre-shifted copies of sprites and masks); and, because the assembly instruction of course wants to modify the output, I ended up copying the dest mask and doing the source as self-modifying code with chains of unrolled andi.l #<character mask>,-(a0) / bne.w pairs; if the chain falls through, the player's just scraped by a mob.

This was of course back in the day that one didn't have to worry about pipeline or cache invalidation, because one simply didn't have the luxury of such things. The naïve loop/temp register implementation would be faster now (and, thanks to µcode and register renaming, would be what the CPU really does inside anyway).

Incidentally, you want to really look out for your animation code in games like this, because it impacts directly on game logic. Anything that might reset the animation counters will have side effects. I'm not sure if it was intended that Tiki - despite being a flightless kiwi - from Taito's The NewZealand Story actually can fly with repeated pushes of up mid-jump, for example (although the presence of secret level design elements catering for it suggests it may be, and could actually be a huge easter egg considering it wasn't documented!).

Similarly, Turrican II has a trick involving what happens if you fire and let off a smart bomb (space) at the same time while jumping, and then jump again - and I don't know if that's intended, but there's at least a couple of platforms with some nice goodies I don't think you can get to any other way.

Of course, the Elligator and related mappings allow for (a subset of) valid curve points to be mapped to indistinguishable bit strings, which is very handy in some protocols. A backdoor merchant using Elligator 2, or Elligator Squared, in this particular setup wouldn't be detectable.

I'm going to recommend deadlisting/disassembly instead. Network analysis doesn't give as much context for exactly what is sent, and there seems to be - as far as I can see, yet? - a total lack of hard data and verifiable evidence about what all this "telemetry" actually is, what can be turned off, what can't, and what actually gets sent to whom, when, from what, and why.

The "evidence" I have seen so far that Windows 10 communicates with its maker is, let's be honest, pretty scaremongery and includes things like LLMNR traffic - which is link-local! - and neglects to consider that Windows Update now checks much more frequently (because of the accelerated release cadence of a rolling release) and essentially torrents its updates now, P2P-style.

If there's a real privacy issue - and there may well be, especially on default settings - we need reliable, detailed, hard information to see what binaries send what to where to begin to address it, and to see what can be turned off, what should be, etc. Does anyone know if anyone's begun that analysis yet?

(Of course it really should be Microsoft openly discussing this, but in the absence of that, the mantle inevitably falls to independent researchers.)

That is incorrect. From the EULA [§4(b)], it is clear that upgrades from retail (stand-alone) versions stay retail - and transferable. No exceptions in there about the one-year qualifying period to upgrade your (now-perpetual) Windows licence:

4. Transfer. The provisions of this section do not apply if you acquired the software as a consumer in Germany or in any of the countries listed on this site (aka.ms/transfer), in which case any transfer of the software to a third party, and the right to use it, must comply with applicable law. a. Software preinstalled on device. If you acquired the software preinstalled on a device (and also if you upgraded from software preinstalled on a device), you may transfer the license to use the software directly to another user, only with the licensed device. The transfer must include the software and, if provided with the device, an authentic Windows label including the product key. Before any permitted transfer, the other party must agree that this agreement applies to the transfer and use of the software. b. Stand-alone software. If you acquired the software as stand-alone software (and also if you upgraded from software you acquired as stand-alone software), you may transfer the software to another device that belongs to you. You may also transfer the software to a device owned by someone else if (i) you are the first licensed user of the software and (ii) the new user agrees to the terms of this agreement. You may use the backup copy we allow you to make or the media that the software came on to transfer the software. Every time you transfer the software to a new device, you must remove the software from the prior device. You may not transfer the software to share licenses between devices.

Both Xiph's Daala and Cisco's Thor projects are contributing to the NetVC Working Group at IETF - https://datatracker.ietf.org/wg/netvc/charter/ - to attempt to create a new, competitive, royalty-free video codec - in much the same way as Skype contributed SILK and Xiph contributed CELT to the audio codec WG to create the truly excellent Opus audio codec.

We'll see what comes out of it!

The point I'm making is that people should probably balk at the suggestion that they need 200Mbps/sec of entropy from a mysterious black box on a PCIe card sold to them by an NSA affiliate who want them to put it into their critical servers. No. Just... no. Don't do that.

256 good bits, once, is quite enough, as long as they are good. You might well try to collect more entropy, and your CSPRNG's setup might use a compression function (e.g. a cryptographic hash) to combine them into the seed to try to hedge against failures. That's quite a good idea, as long as the last one you sample is your most trusted (see djb's blog for why). But you don't need megabits of entropy, and you don't need it on an ongoing basis. That task is solved by the PRF.

So what you should perhaps be doing is not using /dev/random at all, but using Linux's default getrandom syscall to get 256 bits to seed your userspace CSPRNG instead. The urandom mode of that will block if it hasn't collected enough entropy, and will never block thereafter, and it also doesn't need a device node handy.

Even attempting to estimate entropy is perilous, so most modern CSPRNGs don't try. (Note, by way of example, the difference between the earlier Yarrow and the later Fortuna.)

Honestly, this sales brochure of a "paper" tastes even worse than the BBC fluff piece. This is below the standard of paper I would have expected Black Hat to accept.

Good CSPRNG design is not a "dark art", and entropy is not "consumed" when a good CSPRNG is used. Any good CSPRNG uses a good PRF - any good block cipher in CTR mode, a hash, or a HMAC, perhaps - to stretch one good, solid, 256-bit entropy seed into as much cryptographically-secure random data as you'll ever need over the lifetime of your cryptosystem, and ratchets forward through the PRF after each call so the state cannot later be reversed (without breaking the PRF, but you're using a good one, so you'll be fine).

You need quality entropy to seed a CSPRNG - not quantity. Yes, it is, as we all know, very important you don't try to use a CSPRNG before its initial seed has collected enough good entropy - which is, yes, a particular problem in embedded systems or headless servers - but after that, the entropy in your CSPRNG seed isn't something that magically disappears, as you'll see from the design of Linux's newest random-number API, getrandom, patterned after the OpenBSD folks' ideas.

Reseeding a CSPRNG's state with more entropy is not a benefit, but in fact a potential risk every time you do it: it can result in entropy injection attacks if an attacker can observe the state, and control some of the entropy. That, in turn, could break your whole cryptosystem, especially if you're using fragile primitives like DSA or ECDSA. One source: http://blog.cr.yp.to/20140205-entropy.html

Detuned ring oscillator TRNGs [p2] can be troublesome to protect from RF side-channel attacks, or even RF injection attacks in pathological cases. Carefully used, they are fine, but best used when combined with shot-noise-based TRNGs. You can find those in surprising places: even the Raspberry Pi's BCM2835/BCM2836 has a perfectly serviceable one, available from /dev/hwrng after bcm2708-rng/bcm2835-rng has been loaded, and which rngd can use with no trouble.

Forgive me if, therefore, I perhaps wouldn't like to buy a "quantum random number generator" from Allied Minds Federal Innovations, Inc, who are behind this "paper", or to replace the OpenSSL RNG with theirs. That all feels far too much like a black box, and Dual_EC_DRBG is still fresh in our memory. I'd rather use the one Alyssa Rowan described to me on a napkin, thanks, or LibreSSL's/OpenBSD's arc4random with ChaCha20, or CTR_DRBG, or HMAC_DRBG.

There are few enough IPv4 addresses that just about any hash forms an injective mapping which can be completely reversed: the best you can do is use something like HMAC and "pepper" it, but that only works if the clients can't verify or generate them.

A policy which unfortunately lumps DoS in with remote code execution as both "high". They're both significant, but one's clearly going to give us all a much worse day than the other, so we're all still left to wonder - how bad is this one?

I think what the grandparents is wondering is if Hacking Team have a 0day in OpenSSL which this will fix, or is the timing coincidental? (I don't know the answer, but if they did, it's probably in that 400GB dump.)

I'm mostly just wondering what they mean by HIGH. Something as bad as code execution or Heartbleed, or "just" something like bad DHE checking?

I do remember disassembling it and looking at it from the other way! (I was curious.) Pre-emptive multi-tasking kernels at that level weren't things you saw frequently on consoles then. Many people just hung things off the vertical blank instead.

You can decode the audio bits - it's just Sony's special version of ADPCM - or use a cartridge (for those PlayStations old enough to have a cartridge port) and read out the SPU memory over X-Link. You didn't even need a debug model to do it (although you did need a handy parallel port and the ability to bit-bang, or run a DOS program).

The CODEC used CD-XA Mode 2 Form 2 (2532-byte sector, with less error-correction layers) ADPCM-compressed streaming audio, 1 of 8 channels, at a relatively low sample rate - which works fine for speech. Lots of PlayStation games used the same basic technique for music and voices (as well as FMVs, although the bulk of that data would have been MDEC-compressed video).

Fascinating insights.

Lots of music on the PSX used a system like that, because that's a very natural fit for the PSX SPU. Tracker "modules" combine the sample data and tabulated sequencing data, but what you found more often on the PSX was separate sample wavetables and sequencing data closer to (i.e. literally converted from, and convertible back to) a MIDI format: it's smaller, timing-based, without all those pesky 00s wasting space. (It sounds better with the PSX reverb unit/buffer on top, of course.) It's actually very similar to what Minoru Akao did for the AKAO sound engine for the PSX Final Fantasy games, for example.

What did you think of the multi-tasking kernel/DMA bit in the "main" binary? (Or did you just remove that?)

By the way, the VR missions mentioned above were released as a separate add-on disc in many regions (rather than the later release Integral which the PC port was). If you do happen to have an original and can't play it on a PS2/PS3 because it doesn't recognise that the 'lid' is open (because it's a tray/slot-loader)... try launching the other executable, it runs fine :)

Indeed, the old FTL game, Dungeon Master (an old RPG, its most direct modern successor-by-inspiration being Legend of Grimrock) put some copy-protection code in one of its sprites, where it hoped you wouldn't notice.

One part of it would repeatedly read one "weak" sector that had been incorrectly encoded on the disk in such a way that it would usually read inconsistently, and would crash the game with an obscure system error if it didn't read differently.

Cute, but kind of a problem when you have a much better quality floppy drive which read the weak sector consistently.

I gather they're not launching with ECDSA certificates (and obviously not with EdDSA or whatever comes out of CFRG, because that's still being discussed by the IETF/IRTF), but they're going to add it later. Any idea when?

What's the hold up; HSMs that'll do secp256r1?

Because of the huge performance improvement ECDSA brings over RSA, I know I'm not going to be deploying Let's Encrypt certs until I can get ECDSA ones (as well as RSA ones, presumably).

(This is not legal advice, just a comment.)

No, the "under penalty of perjury" bit in the DMCA is that they own the copyright in the content they're saying they own. (I believe this is undisputed; they do in fact own the typesetting of their front page.)

Whether the links actually point to copies of the content alleged, or whether the content if republished would be an infringement of copyright in that context, are entirely separate questions (and there are no repercussions for being wrong, even deliberately, which is one of the really bad things about the DMCA, especially in a world where robots auto-file takedowns based on dud search terms).

They do not seem to have misrepresented their clients' interests, although this §512(c) takedown is clearly filed in bad faith: because yes, this kind of meta-reporting, commentary on news stories, is absolutely classic fair use - and there's the story they're reporting on, right there on the right. I believe it would be perfectly legal over here, too - in fact, the BBC actually routinely republish the front pages of every major UK newspaper every day for comment and criticism, both on the TV and on their website - http://www.bbc.co.uk/news/blogs/the_papers - and they neither seek, nor need, permission. This low-res image of the front page represents what the paper was reporting as a snapshot in time as a matter of history. It obviously doesn't replace the paper: it doesn't even contain all of the story in question. It is quite clearly not an actionable infringement of copyright.

One would think that Ms Chisese would have given her client certain advice about the serious potential negative impact of spitefully trying to restrict news reporting via copyright takedowns: aka the "Streisand effect"? You would think they'd know about that. Still, I don't see an "on instructions" in there. Oh well. I'm sure the Intercept will respond as I would expect them to. (Edit: Sure enough - https://twitter.com/ggreenwald/status/610451356122509312 )