daira
daira on Hacker News
> BLAKE3 appears to have 128 bits of security against all attacks.
That's not accurate. The best pseudo-preimage attack on BLAKE2s has complexity 2^{253.8} against 6.75 rounds (section 3.2 of https://eprint.iacr.org/2019/1492.pdf ). The best full-preimage attack on BLAKE2s is against 2.75 rounds. BLAKE3's round function is identical to BLAKE2s (although used in a different mode). Currently there isn't any known classical preimage attack on BLAKE3 better than these ones against reduced BLAKE2s. This should be interpreted with caution since the design has only just been published.
[Disclosure of interest: I know Zooko and work for Electric Coin Company. This is only based on a cursory review of the paper, though; I had not seen it prior to publication.]
-- Daira Hopwood
Disabling SharedArrayBuffer is just stopping the most obvious method of exploitation; it's by no means a fix. Expect a slew of papers over the next few years on other methods of exploitation from JS.
But you don't detect that one case where you are actually compromised. You dismiss it like you do all the false positives. At best, when you get pwned you think back to having dismissed the key change warning and know what happened, but how does that actually help you?
The legacy codebase issue we are lamenting there is just that the code inherited from Bitcoin is in C++. It's of course possible to interface between C++ and Rust, and that's what we're intending to do in future. It would have been risky to try to do that in the code we wrote before launch.
Yes, your portrayal of the performance issues was fine.
As far as I know we've never claimed that the distribution is flat or that the "effective anonymity" is equivalent to a uniform distribution over prior notes (I certainly didn't claim that). One of the advantages of Zcash's approach is that you don't need to know the distribution in order to have a strong privacy claim. As I said, this is because the content of a transaction is not revealed, and so the attacker's advantage is no better than guessing based on their prior knowledge (plus the little information that can be inferred from timestamps and number of JoinSplits in a transaction).
It's the same claim as for semantically secure encryption, for example: no competent cryptographer would claim that encrypting a message implies that the adversary's knowledge of the plaintext distribution is uniform; only that the ciphertext gives the attacker no further information (apart from length, typically) about the distribution.
Note that the number of prior shielded transactions (not the proportion, and not the value) is what is actually relevant to the privacy of new shielded transactions. Roughly speaking, the privacy you get with Zcash is comparable to what you would get with Monero
if you could use
all previous shielded transactions (over 120000 of them, currently) as mixins. That's why the criticisms of Zcash based on the percentage use of shielding (either by transactions or value) are totally missing the point.
-- Daira Hopwood (Zcash developer)
This bug had nothing to do with Zcash. Please correct your comment to say Zcoin, if that's what you meant.
In any case, Zcash is also derived from Bitcoin and builds with `-Werror` (edit: not `-Wall`, but we're working on that). That kind of minimal static analysis is certainly not sufficient to catch the majority of bugs, though.
C++ is not memory safe in any meaningful sense. There have been efforts to define a memory-safe subset, but typical large codebases, including Bitcoin, do not come close to falling within that subset.
Zcash, for example, is built with `-Werror` (edit: not `-Wall`, but we're working on that). So this is absolutely feasible on a Bitcoin-derived codebase.
No, that is not the bug. See Ian Miers' comments.
This isn't a subtle or difficult-to-find case. It's a case of "why the heck would anyone write code like that, in any language, in the first place?" The only language-level abstraction needed to avoid this particular kind of duplicated code, is a loop.
Just to clarify, the code that was duplicated per denomination is not part of libzerocoin itself, it's in main.cpp. I'm not sure who wrote it; it may or may not have been part of the academic prototype Ian refers to. In any case, this amount of duplication (in security-critical code, no less) should never have passed the necessary code review to release a cryptocurrency. Also note that there are still unexplained differences between the copied code branches after the security fix.
(In contrast, Zcash did have duplicated code in the prototype we inherited, but we rewrote that entirely well before the Zcash launch.)
[Edit: I confirmed that the duplicated validation code in main.cpp was not present in libzerocoin. Some of the code in main.cpp including some stale comments, appears to have been pasted from https://github.com/Zerocoin/libzerocoin/blob/master/Tutorial... , but that tutorial code does not have the bug. So it appears that it was introduced by the Moneta/Zcoin developers.]
Disclosure of interest: I am a Zcash developer.
The crypto used in Confidential Transactions, or any implementation of it, does not only rely on ECDLP. There's plenty of scope for potential protocol or implementation errors. (The Zcoin issue, remember, is an implementation error.)
There are ways to significantly reduce the cost of zk proof verification by batching (that are compatible with the existing Zcash protocol without a fork).
Fixed in Zcash 1.0.3. (They were always "working", despite the bugs that were recently fixed. You can see plenty of successful z-address transactions on the blockchain.)
The concern in that last sentence seems misplaced; there is no relation between proportion of monetary base held by an attacker, and proportion of mining power held by an attacker.
Basically yes. Strictly speaking privacy also relies on assumptions about Curve25519 (with a Blake2b-based key derivation function) and ChaCha20, but those are standard and uncontroversial.
It's a bit more complicated than that. The main responsibility for implementing connection layer unlinkability lies with Tor (if you use Zcash over Tor, which we will aim to provide good support for), but how effective that is in resisting deanonymization attacks at that layer depends a great deal on the higher level protocol and its implementation. That's why it's recommended to use TorBrowser to browse the web anonymously; if you were to use a stock browser, then there would be numerous attacks that reduce the size of your anonymity set. We've tried to pay attention to minimizing leakage of information in the Zerocash protocol; you can read the numerous tickets on that here:
https://github.com/zcash/zcash/issues?page=2&q=is%3Aissue+la...Also, note that even against an adversary that can observe all connection metadata, Zcash maintains strong unlinkability of which notes are involved in a private transaction.
Of course they've had to pay. In the case of the investors, they've had to pay cash up-front to fund the development of Zcash. In the case of other shareholders of Zerocoin Electric Coin Company, they've had to pay for, or otherwise legitimately obtained their shareholding -- for example by their labour, in the case of developers who are also shareholders.
"Pump and dump" means fraudulently manipulating the price of a stock by making deliberately misleading or inaccurate statements in order to sell it at a premium. That's illegal under securities law. If you invest in something that then increases in value over a long period because people generally think it is valuable, and at some point you sell it, that is not "pump and dump".
Declaration of interest: I'm a Zcash developer and I hold some shares in Least Authority, which owns part of Zerocoin Electric Coin Company.
I don't actually see any assertions on this thread by natdempk or tptacek claiming that TextSecure is "trustworthy" and/or "solid". Did I miss something?
My own opinion is that both strong cryptographic and security engineering expertise on the part of designers and implementors, and multiple independent published security audits, are necessary to consider an app trustworthy -- but still not sufficient, given the poor state of platform security and the lack of support most current platforms (operating systems, browsers, etc.) give for isolation between apps.
Disclaimer: I worked on the Least Authority audit of Cryptocat, and in general get paid for similar auditing. I'm also designing a programming language (Noether) that is intended to facilitate security reviews.
The scopes had a great deal of overlap; although we (Least Authority) didn't consider the iOS client at all, the rest of iSec's audit has essentially the same scope as ours. The point I was trying to highlight is how easy it is to miss things, and therefore that having independent concurrent audits is actually a really good idea. It would probably be even better if the teams worked mostly independently but were able to exchange draft versions of their reports (before the mitigations necessary for a public release).
Actually I strongly suggest reading these in conjunction with iSec's issues 12 through 16, because each team spotted some details that the other missed.
Findings iSEC-RFACC0114-1 and iSEC-RFACC0114-3. (2 out of the 17 vulnerabilities found by iSec, of varying severity.)
I was one of the auditors for Least Authority. Just wanted to add that this audit was really fun to do! If you have the necessary experience and are part of a good team, security auditing is a fantastic job.
-- Daira Hopwood