zmanian

This attack started with a well known pattern where protocols where you can freely mutate cyphertext in transit usually end of building a decryption oracle into them that an attacker can exploit.

Then they found a novel oracle in the image decryption system.

Then big change at Apple lately is that on top of having world class cypto and security people they are publishing a lot more of their design work for peer review. This will lead to much more secure systems when they replace the iMessage crypto.

You'll get an exit with DDOS attack against it. Not an exit controlled by the attacker. The attacker will see the same fraction of Tor traffic with or without the attack. The Tor user base will notice a massively degraded experience.

You can't affect the proportion of Tor traffic that flows through a given exit with a DDOS attack.

This attack is a general amplifier on denial of service attacks on Linux server.

If this attack was deployed against Tor, this would appear as a general DDOS attack against Tor and degrade most users experience.

It would not help an attacker direct circuits towards a malicious exit as described in the paper.

I meant the former...

I think you are right. The same techniques could be applied in ethereum to reward ddos attackers.

It's beautiful and terrible at the same time. <3

We may have found a deeper horror than assignation markets.

TouchId coming to the MacbookPro will bring the secure element from the Iphone with it.

I'm hoping they also use the secure element to implement SecureBoot of only signed software. Ideally this could be disabled like in a Chromebook

I've been wanting something like this to sandbox build systems like npm, cargo etc so you can be sure your dependency resolution can't exfiltrate your keys.

I don't see anything in their site about end to encryption?

IBM is pushing hyperledger / blockchain on Power8 pretty hard.

Given how much memory bandwidth is a bottleneck on updating the internal Merkle trees, Power8 might be good for tx throughput

I can see this being immensely beneficial to environments that rely heavily of calling out openssl for TLS like node and python.

Rust is not a good language for low level crypto implementation because it offers no facilities for side channel resistant algorithims. Ring uses the extensively reviewed implementation from BoringSSL and considerable expertise from the author. Ring has a goal of moving as much code that does not need side channel resistant to Rust.

By moving the protocol logic to Rust, the amount of code that needs to be reviewed for memory safety in a TLS library is drastically reduced.

We do not currently have good options for small Post Quantum signatures.

Hash Based signatures in a web of trust would result in enormous amounts of signature data for each public key.

A stateful hash based signing protocol like XMSS might be more suitable.

Hopefully a Post Quantum small signature alternative appears.

I'm really impressed by how easy it is to get NISTP256 key from the enclave. I think Intel got a lot of things right and then completely failed on the signing and attestation process. Hopefully we can see a future iteration of SGX that builds on this early promise.

Bitcoin script provides a no elegant way to invalidate old states. There are various solutions to this in lightning network tx but they end up requiring actively watching the network in case an old state is broadcast. If you have a better mechanism for invalidate the previous state, the whole system can be massively simplified.

You see a common pattern in crypto projects. The core of the project is passionate autodidacts and the experts are in periphery.

Tor and Ethereum have ample access to experts via academic research, security auditors and academic consultants.

Tor worked hard to build up this pattern by encouraging a robust outsider community to form around Tor. Ethereum has done the same from the get go.

I'm entirely convinced that Intel would undermine the entire trusted computer over some relatively hairbrained ideas about new revenue sources.

Intel needs to give us an alternative.

We need operating system vendors to give us a mechanism for easily creating and managed sandboxed dev environments.

Ones dev environment should be a place where remote code execution is a high probablity and we need better tools to partition that from high value data.

Basically the jurisdiction is limited to equipment used by the county sheriff. To cover the police departments within the county, we need to pass a similar ordinance in each city. We are working on it

ACLU press release https://www.aclunc.org/news/santa-clara-county-passes-ground...

This doesn't directly impact a huge population. But because of the relentless support of Supervisor Simitian, it was a good test case.

It will be much easier to move forward in larger cities now.

Is there any document or talk that really explains how all the crypto pieces fit together?

Ethereum is an cryptocurrency retailer and exchange platform. Coinbase should support cryptocurrencies where there is customer demand and backed by credible technical teams. Bitcoin and Ethereum both meet that criteria.

I wish Coinbase had a stronger set of technical advisors. Fred and Brian seem to rarely meet with the engineering and research community. Charlie Lee is pretty strongly on crytocurrency technology but just one person.

At least on Debian based systems, running Tor as a daemon is trvial.

There is even apt tor to fetch updates over Tor.

There hidden service config is pretty simple as well.

We should write more functionality for servers that let them setup hidden services via tor

Tor is a solution for both anonynmity & privacy and censorship evasion. I2P is oriented primarily towards anonymity and privacy.

I2P has an attractive anonymous service design and can run applications like Bittorrent over it. But it also developed basically by 3 people in New Zealand.

Tor has more funding b/c of censorship evasion features being attractive to funders. Successes in the anonynmity feature set like SecureDrop. A vibrant academic community with conferences etc. Lots and lots of review from the external crypto and security community. A deep well of technical talent.

The combination of watering hole attacks and internet scale packet timing collection is pretty big problem for the security of Tor users.

Fortunately Internet wide timing attacks are mostly a Five Eyes and domestic Chinese capability. Chaff, padding etc can help here.

Compromising the servers of target services and using that a platform to distribute anonymity stripping malware is also a problem. The Firefox codebase that TBB is based isn't awesome from a security point of view. Hopefully the Firefox code base can catch up from a security perspective and give them something better to work with.

I'm very excited about a number of innovations being deployed in next gen onion servers.

The distributed random number generator is very cool.

The blinded ed25519 public keys for the rendezvous servers are also super awesome.

Funding tor not only protects people from surveillance but advances computer science.

The Signal protocol is for all intents asymptote the state of the art in the design of a secure messaging protocol. There doesn't seem to be any meaningful improvements to the design without changing the requirements.

New requirements might be

- Post Quantum forward secrecy

- Groups messaging with transcript verification

- Security weakness in x25519 or AES-CBC-HMAC or SHA256 primitives.

If you don't have any new requirements, crypto protocol developer time is a scarce resource. Why reinvent the state of the art?

I'm really happy using Crouton on a Pixel 2 as my main dev machine.

I think it is possible to create a movement against Feinstein. But it would be most powerful to turn the party against her.

I don't think she would hold her position if other Democrats came to her and said she was hurting fundraising.

Lavabit wasn't end to end encrypted. DarkMail will be.(Assuming it ever materializes)