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.
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.
Doesn't look like you even need to install WSL.