HN user
to obscure cash flows, something which is specifically illegal.
It's only illegal under 18 U.S. Code § 1956 to conduct transactions to obscure the source of "the proceeds of some form of unlawful activity." There's no law against obscuring the sources of cash flows in general. And on an otherwise completely public blockchain, there was a major use case for obfuscating flows for the sake of user privacy.
The phrase 'according to the treasury' and Ctrl-V are doing a lot of work there. The government says a lot of things. The other day the Secretary of State claimed Tornado Cash was a DPRK sponsored hacking group before deleting the tweet. Not everyone in authority has a real great understanding of the technology involved.
https://web.archive.org/web/20220808155413/https://twitter.c...
We are talking about an entity that according to the treasury has laundered more than 7 Billion USD, assisted criminals and neglected complying to...(AML/CFT) obligations willingly and repeatedly.
The Tornado Cash mixer contracts have been immutable since May 2020. It's a dumb piece of software that can't be modified or upgraded. Its authors have no control over who uses it on the blockchain.
https://tornado-cash.medium.com/tornado-cash-is-finally-trus...
It's kind of a strange accusation to say that someone has 'willingly and repeatedly' neglected to comply with legal obligations by failing to do something that's technically impossible to accomplish. All the GitHub users did was write code, and simply writing code, while not executing it to do something illegal, seems like it would be pretty well protected by the First Amendment, since code is speech. Turning people's lives to shit over what a software tool they invented gets used for later, after it's completely out of their hands, is pretty wild.
You copied and pasted Brian E. Nelson's complaint:
Secretary of the Treasury for Terrorism and Financial Intelligence Brian E. Nelson. “Despite public assurances otherwise, Tornado Cash has repeatedly failed to impose effective controls designed to stop it from laundering funds for malicious cyber actors on a regular basis and without basic measures to address its risks.
But what Nelson fails to mention is that a) everyone involved has failed to impose 'effective' controls because it's physically impossible for anyone to, and b) basic measures to block sanctioned entities were actually implemented by the operators of the Tornado Cash website (which just got added to the SDN list anyway). So the complaint is that the control measure in place isn't an 'effective' control measure against entities that don't use the website.
https://www.coindesk.com/tech/2022/04/15/tornado-cash-adds-c...
And not that the exact number matters, but the Treasury is alleging an obviously maximally exaggerated amount of money laundering. $7 billion is the total value of deposits into Tornado Cash over all time. For that to be $7 billion laundered, 100% of all deposits, ever, put into the mixer would have to have come from illegal sources, which is obviously false. Depositing legally earned money into a privacy smart contract isn't money laundering. A sizeable portion of deposits are illicit, but far from a majority.
Since becoming active in August 2019, Tornado Cash has received over $7.6 billion worth of Ethereum, a sizable portion of which have come from illicit or high-risk sources.
https://blog.chainalysis.com/reports/tornado-cash-ofac-desig...
Let's Encrypt is the lone, singular CA that actually already had a defense against this attack.
In multiple vantage point verification, a CA performs domain control validation from many vantage points spread throughout the Internet instead of a single vantage point that can easily be affected by a BGP attack. As we measured in our 2021 USENIX Security paper, this is effective because many BGP attacks are localized to only a part of the Internet, so it becomes significantly less likely that an adversary will hijack all of a CAs diverse vantage points (compared to traditional domain control validation). We have worked with Let’s Encrypt, the world’s largest web PKI CA, to fully deploy multiple vantage point validation, and every certificate they sign is validated using this technology (over a billion since the deployment in Feb 2020). Cloudflare also has developed a deployment as well, which is available for other interested CAs.
But multiple vantage point validation at just a single CA is still not enough. The Internet is only as strong as its weakest link. Currently, Let’s Encrypt is the only certificate authority using multiple vantage point validation and an adversary can, for many domains, pick which CA to use in an attack. To prevent this, we advocate for universal adoption through the CA/Browser Forum (the governing body for CAs).
That defense alone is still not perfect ("some BGP attacks can still fool all of a CA’s vantage points"), but that's the state of the art.
but see for a less hysterical writeup)
See where? Did you miss including another link here?
It's true, as worded, it doesn't make any sense.
What would make sense is that in August 2017, Rohrabacher wanted to strike a deal for actual, solid evidence that would debunk the idea that the Russian government hacked the DNC (and with it, the idea that Trump worked with Russia), rather than just take Assange's word on who the source was and wasn't. Since his goal is to save Trump's reputation, Assange's word isn't enough.
https://losangeles.cbslocal.com/video/3731570-rohrabacher-ma...
Of course Trump likely wasn't aware that Rohrabacher was trying to make this kind of deal at the time. Rohrabacher only spoke to Chief of Staff John F. Kelly, who could have easily mentally filed their phone conversation directly in the trash, because the Trump administration was already busy secretly drafting up charges against Julian Assange at the time.
https://www.cnn.com/2017/04/20/politics/julian-assange-wikil...
Maybe, but this doesn't appear to be an actual example of brazen Trump corruption. The journalist's summary of the lawyer's summary of the ex-congressman's statement appears to be inaccurate to the point of being fake news.
https://www.rohrabacher.com/news/my-meeting-with-julian-assa...
At no time did I talk to President Trump about Julian Assange. Likewise, I was not directed by Trump or anyone else connected with him to meet with Julian Assange. I was on my own fact finding mission at personal expense to find out information I thought was important to our country. I was shocked to find out that no other member of Congress had taken the time in their official or unofficial capacity to interview Julian Assange. At no time did I offer Julian Assange anything from the President because I had not spoken with the President about this issue at all.
It's true, the Mueller report is light on actual evidence and in places rather heavy on hedging language.
But it seems not an unreasonable guess in this case that there was possible use of "WikiLeaks's private communication system" based on a Twitter DM that was quoted in the Mueller report:
On September 15, 2016, @dcleaks wrote to @WikiLeaks, “hi there! I'm from DC Leaks. How could we discuss some submission-related issues? Am trying to reach out to you via your secured chat but getting no response. I’ve got something that might interest you. You won't be disappointed, I promise.”
The evidence is so comprehensive, and yet we can't see it.
Pages 36 to 51 of volume one of the Mueller report concern the hacking and dissemination of DNC emails. It has many detailed claims and conclusions, but what's notably missing:
The actual evidence on which Mueller bases his conclusion that both DCLeaks and Guccifer 2.0 are cutouts for the GRU. He doesn't even indirectly allude to specific evidence, let alone include it in the report. It just isn't there.
Funny thing: on page 46 it cites a 9/15/16 Twitter DM, @guccifer_2 to @dcleaks. If they're both false identities for the GRU, it seems odd for Russian state coworkers to be communicating with each other over cleartext DMs on Twitter, an American company. (Unless that's just to deviously throw us off their trail.)
Yeah, Comey did say in 2017 that they could only get CrowdStrike to hand over their analysis, and never got direct access to the machines.
https://www.washingtonpost.com/news/post-politics/wp/2017/03...
But I can't find anything about physical destruction, CrowdStrike claims to only have ever had images of the systems.
https://www.crowdstrike.com/blog/bears-midst-intrusion-democ...
In 2018, the DNC said “The FBI was given images of servers, forensic copies, as well as a host of other forensic information we collected from our systems.”
https://www.thedailybeast.com/trumps-missing-dnc-server-is-n...
Of all the things that aren't evidence, an indictment is possibly among the most not-evidence things.
A judge famously said you could indict a ham sandwich. In practice, grand juries say whatever a prosecutor wants them to say.
And as Russian nationals, it's also unlikely they'll ever have to actually stand trial, which is when evidence would be required to enter the public record to convict them.
The Ars article is at least very transparent about its conclusions and what evidence they're based on.
https://arstechnica.com/information-technology/2016/06/gucci...
"We still don't know who he is or whether he works for the Russian government, but one thing is for sure: Guccifer 2.0—the nom de guerre of the person claiming he hacked the Democratic National Committee and published hundreds of pages that appeared to prove it—left behind fingerprints implicating a Russian-speaking person with a nostalgia for the country's lost Soviet era."
a witness statement by former U.S. Republican congressman Dana Rohrabacher who had visited Assange in 2017, saying that he had been sent by the president to offer a pardon.
The pardon would come on the condition that Assange complied with the U.S. by saying that the Russians were not involved in the email leak which hurt Hillary Clinton’s presidential campaign in 2016, Rohrabacher’s statement said.
Rohrabacher's witness statement says that he made this offer on Trump's behalf with a condition attached. Rohrabacher's own statement in August 2017 says that Assange met that condition in that same 3 hour meeting:
https://web.archive.org/web/20170817205448/https://rohrabach...
Assange, said Rohrabacher, “emphatically stated that the Russians were not involved in the hacking or disclosure of those emails.” Rohrabacher, who chairs the House Foreign Affairs Subcommittee on Europe, Eurasia, and Emerging Threats, is the only U.S. congressman to have visited the controversial figure.
The conversation ranged over many topics, said Rohrabacher, including the status of Wikileaks, which Assange maintains is vital to keeping Americans informed on matters hidden by their traditional media. The congressman plans to divulge more of what he found directly to President Trump.
Rohrabacher visited Assange in August 2017, when this offer supposedly took place. [1]
Assange wasn't placed in solitary confinement, a form of torture, until 2019, after he was arrested by UK authorities.
Of course in 2017, he was being arbitrarily detained, [2] which while not torture, was a violation of his human rights, and had been ongoing since the Obama administration with no end in sight.
[1] https://web.archive.org/web/20170817205448/https://rohrabach...
[2] https://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?N...
Right, there's a good security reason they have the registration step. Though I don't think what you described is quite how it works. The FIDO and CTAP protocols don't let the Relying Party provide any entropy to the authenticator. The only input is the domain name(+ user handle in CTAP). Authenticator has to create the key with its own entropy. It doesn't need the server's entropy to have multiple keys per domain name.
(In Yubikeys' case, E is actually a Yubikey-generated random nonce that's used to generate the private key by HMAC-ing it with S and the domain name, not an encrypted private key, but that's all opaque implementation details. E can be anything as long as it reconstructs the key.)
I mean, you can.
But the heavily flawed PKI is rapidly improving from the dumpster fire it has been. The glaring 'blindly trust every CA to never go rogue' problem is on the edge of being solved, with browsers beginning to require CAs to submit all new certificates to Certificate Transparency logs in order to be accepted. Attackers would have to either compromise multiple targets in detectable ways, or publicly disclose their forged certificate to the world before they can use it, at least once the older certificates from the dark ages of 2017 have all expired in a few years.
It doesn't say that IANA defined it to not have HTTPS anywhere at all.
using IP's to try to figure out what site is what doesn't work.
Every mainstream browser sends the server's domain name in plaintext at the start of the TLS connection,[0] so (short of domain-fronting, which browsers don't do) it's generally not a mystery what site clients are talking to, even if they used DNS-over-TLS. ISPs still have that metadata.
TLS session resumption could theoretically be used for tracking users, but why would Google benefit from doing that when it already uses HTTP cookies? The actual benefit is one fewer round trip, making the web, and all of their sites, faster to load.
It's far more plausible that they're pushing to secure the web with HTTPS and Certificate Transparency because an insecure web ecosystem is just plain bad for business, and makes us all more insecure. It doesn't require spite or a zero-sum game of tearing down the competition to explain pushing HTTPS and Certificate Transparency, which lack real nefarious downsides for users.
? https://www.example.com/ It's had HTTPS since at least 2014. [0]
All 3 of the concerns GP listed are completely agnostic to the topic of the web page or the behavior of its audience. It's not your fellow webpage visitors or community that are most likely to be in a position in the network to be doing MITM attacks.
Serious question, is it your contention that no lawyer has ever lost a case defending an innocent person, in the entire history of the bar association, because that's just impossible?
Cuz the vast majority of these were not plea bargains: https://en.wikipedia.org/wiki/List_of_wrongful_convictions_i...
Critics of the criminal justice system have been railing against the utterly lopsided plea bargaining system, among many other CJ issues that all serve to prop up the others. Some cursory googling turns up:
https://www.jstor.org/stable/796954
https://reason.com/archives/2011/07/05/the-devils-bargain
https://www.nytimes.com/2011/09/26/us/tough-sentences-help-p...
https://www.nytimes.com/2012/03/11/opinion/sunday/go-to-tria...
https://www.nybooks.com/articles/2014/11/20/why-innocent-peo...
https://www.themarshallproject.org/2014/12/26/plea-bargainin...
https://www.wsj.com/articles/the-injustice-of-the-plea-barga...
https://www.theatlantic.com/magazine/archive/2017/09/innocen...
https://www.injusticewatch.org/interactives/2018/plea-bargai...
People's inability to afford bail isn't an argument for plea bargains, that's an argument for letting people go on their own recognizance and abolishing cash bail, instead of keeping half a million unconvicted people in American jails.
Objecting to one criminal justice reform because it might exacerbate how the criminal justice system is also completely unfair in another, equally terrible way isn't very convincing, when you could actually be advocating to eliminate both problems.
And hey, no more innocent people railroaded into guilty pleas like they are under the current system. https://www.nybooks.com/articles/2014/11/20/why-innocent-peo...
Relevant chart? https://en.wikipedia.org/wiki/Nolan_Chart
Alternatively, https://xkcd.com/868/
I'd have to see this scattered polling, but this really seems like a claim somewhere between "Catholics who say they don't believe in transubstantiation," and "self-identified Scots not from Scotland," considering.
There doesn't technically have to be a way to register new sites. There is, but theoretically there never actually had to be, given keys are generated deterministically on-demand, using the website's domain name effectively as a salt. There's no system with a list of websites.
The signed challenge-response you give to the phishing site cannot be forwarded to the real site and accepted, because you used the domain name as part of your response, and as part of key generation, so it doesn't match. That's all that meant. 'Credentials' included the use of a public/private key, not just the typed password.
Given the justification for plea deals is the crowded dockets, alternatively, you could talk to your representatives to reform the laws so fewer acts are crimes that get people arrested in the first place.
Also alternatively, instead of using life-ruining threats to 'incentivize' defendants, the only actors in the system being strong-armed here, into 'reasonable' capitulations to do whatever the prosecutor wants, you incentivize prosecutors to better behavior by abolishing plea deals so they have to focus finite resources on prosecuting only the most important cases against the most dangerous individuals, and not to add as many people as possible to the USA's disproportionately massive prison population. [0]
Also also alternatively, instead of fretting about a zero-sum game where defendants suffer from 'delayed justice' due to other defendants enjoying their right to a day in court, you could try to eliminate cash bail and let people back into the community until they've actually been convicted of a crime, so they don't have to await their trial from a jail cell. [1]
And being stubborn, illogical, mistrusting, or giving an abstract concept the metaphorical middle finger is one of the weakest possible reasons to punish someone with excessive jail time that you actually know they don't deserve, in an unaccountably secretive, opaque legal game of chicken where you're trying to make the defendant blink first.
[0] https://www.prisonpolicy.org/reports/pie2018.html
[1] https://reason.com/blog/2018/01/25/government-is-gutting-the...
Nothing mandates it. In fact, it's specifically discouraged in the WebAuthn spec:
Authenticators may implement a global signature counter, i.e., on a per-authenticator basis, but this is less privacy-friendly for users.
Since you can have multiple keys on the same site, you could go one better, and have a per-key offset. When the key is rederived from the one-time nonce sent from the server, you'd also derive a 16-bit number to add to the 32-bit global counter. But even that wouldn't actually be enough to make correlating them impossible.
A large but finite set of independent global counters is a great idea, though. 256 32-bit integers is just 1 KiB of storage.
It's not that kind of nonce. It's not even called that formally, it's called the 'signature counter.' It's just a part of the plaintext signed with the keypair. There is zero risk of what you're talking about.
And how is it complicated to store a single integer per account and perform a comparison if `counter <= previousValue` at each authentication to see if it's not monotonically increasing? They already store that user's public key and key handle, they can store another 4 bytes.
In fact, the WebAuthn spec makes verifying this behavior mandatory. [0]
What contradiction? It just plain isn't part of the threat model. Was that not clear?
Although, actually reading the spec, it can actually double as a bit of extra authenticator of the website. Any site has to first request registration (client uploads a new, unique, opaque key handle/'credential id' to the server, along with its matching public key) before it can request authentication (server provides credential id and challenge, client signs challenge).
A credential ID is a unique nonce from the device's global counter, signed by a MAC. The real site will already have a registered credential ID, which the device will take, verify it, and use the nonce to HMAC the private key back into existence.
A phishing site you've never visited before will have no credential ID. Any fake ones it tries to generate will be rejected since the MAC would be invalid. One from the real website won't be accepted either, because the MAC incorporates the website's domain, too. They'd have to get user consent to create a new key pair entirely, which a user could notice is completely different from what's normally requested at login. Then they'd have to consent again to actually authenticate.
https://developers.yubico.com/U2F/Protocol_details/Key_gener...
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...
In the more expensive devices, are the arbitrary new private keys imported from the computer it's plugged into? If the new keys are generated on the hardware you don't trust, it'd still be the same problem, since the private keys could be generated deterministically from a known seed and a counter.
You can at least verify when a cheaply-designed device has changed its secret key, because the public key it offers for github.com is different from before, but yeah, that 'new' secret key could still just be derived from a manufacturer-known seed/secret serial number, too, same as the first one was, but with an incremented counter.