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?
Thanks, that's basically what I was looking for. I have apps that are bottlenecked by blake2, so finding a faster cryptographic hash function would be pretty interesting to me.
If BLAKE2 (I assume you're using blake2b) is your bottleneck, perhaps you should consider the blake2bp (four way parallelism) or the blake2sp (eight way parallelism) variants. If even those are too slow for you (lots of continuous data and you have multiple cores available), then you might be able to try using tree hashing on top of one of the mentioned BLAKE2 variants.
I'm curious though, what are you working on that saturates ~1 GiB/s/core?
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.
> dd if=install.iso of=/dev/sda - right over the top of the partition table and everything.
I do the same thing. Then reboot and use fdisk to delete the main partition and recreate it again, except this time using all the available space of install drive. Then resize2fs to expand the filesystem.
How does something like the Arch Linux installer handle being "overwritten" as it installs? Or do you skip the first ~700mb of the drive when installing?
Interesting approach, skipping the space. But I think it would be simpler to just start with whatever's configured on the install disc. It's a pretty normal archlinux install, just need to change the passwords.
There's no need for an ISO image. Just prepare the system on either bare metal or a virtual machine, then tar the entire disk to a file, transfer and feed that file to dd instead. Of course, make sure you use the same (or smaller, but you'll have to claim unused space later) disk size, and be careful when choosing partition table type and aligning partitions.
> 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.
Don't forget Gentoo! That's precisely how they installed it.
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.
> Strong, deniable, end-to-end encryption should be mandatory.
Strong end-to-end encryption with perfect forward secrecy should be mandatory. Deniable authentication (https://en.wikipedia.org/wiki/Deniable_authentication), however, seems like a potentially interesting option but not one that the protocol should mandate. Sometimes you do want authentication that remains valid after the conversation ends, so you can subsequently authenticate the messages in it.
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).
With no knowledge of how signal's servers actually implement this, I would like to ask you... how long should the central server hold on to the (encrypted) message that Alice sends to Bob if Bob never becomes available again?
I haven't thought about what's reasonable (an hour? a week?) but it still shouldn't be dropped but bounced back to the sender with an undelivered message. At last that's how email solved it some thirty years ago.
(But perhaps a new protocol could take the opportunity to improve things further and offer on-line delivery status notifications throughout the process.)
No matter what, messages should never be silently dropped.
Doesn't look like you even need to install WSL.