Unlike Dual_EC_DRBG, Bitcoin doesn't use suspicious unexplained constants - all major constants have clear justifications as far as I'm aware.
154 karma · joined June 25, 2018
Many serialization formats allow multiple binary representations of the same data (e.g., dictionaries with different key orders, or different integer encodings). This non-determinism creates problems when combining serialization with cryptographic operations like signing and hashing. Cord guarantees that every unique semantic representation has exactly one unique binary representation.
This deterministic approach is crucial for cryptographic use cases. When data needs to be signed or hashed, any variation in serialization — even between semantically equivalent representations — can produce different cryptographic results. This undermines the reliability of verification processes and introduces additional considerations during system design at best, or security vulnerabilities at worst.
Without deterministic serialization, systems face a burdensome choice: either store both the original serialized bytes alongside the deserialized data structures (doubling storage requirements and creating synchronization challenges), or risk the inability to verify previously signed data. This challenge becomes particularly acute in distributed systems where multiple parties need to independently verify signatures without access to the original serialized form.
Canonicalization solves this problem by ensuring that all participants, regardless of their implementation details, produce identical byte representations for identical data. This property allows cryptographic operations to be reliably repeatable across different implementations and environments.
The ability to have a single, deterministic binary representation for each unique data structure eliminates an entire class of potential inconsistencies and security issues. It means that verifiers can independently reconstruct the exact byte sequence that was signed, without needing to preserve the original serialization alongside the semantic content.
Cord's approach creates a foundation where cryptographic operations and data serialization work together seamlessly, rather than requiring complex workarounds to reconcile their different requirements.
Naturally, you DO need to run Minibone in an environment that's not compromised, but even if you're concerned about TLS (and there can be valid reasons to be concerned depending on your threat model), web apps can and do run in places other than the browser - that can guarantee the integrity of the bundle.
In any case, for most use cases, database compromise is much more likely than active attacks from APTs that can break TLS.
If active attackers are an important part of your threat model, you do want to assure the integrity of the payload - and you can ship Minibone in things like Tauri (or Electron) apps, like we do at Backbone.
Minibone is an initial attempt to address this challenge in the single-user setting (that allows a concise and easily auditable implementation).
This is all part of our broader work that you can read about here: https://backbone.dev/company
The multi-user scenario is significantly harder to get right without running into nasty vulnerabilities. We plan to write more about how we built it and what to look out for.
Re: Serpent, there are many things to unpack here but, in summary, you don't know a priori how large of a security margin you need (given the primary function of a cipher, you want to pick the conservative option), efficiency concerns become much less relevant with hardware-accelerated implementations and years of Moore's law performance uplifts, low-power devices can take advantage of much lighter algorithms than Rijndael OR Serpent, ease of implementation does not equal ease of correct/secure implementation vis-a-vis side channel attacks, and certainly if Serpent was chosen you wouldn't see Rijndael talked about much.
Regardless, the comparison wasn't intended to argue for a meaningful difference in security margin, but to show that that the winner of the competition, well, wins (in adoption).
In this particular case it's worth noting that neither BSI (Germany) nor NLNCSA (The Netherlands) recommend Kyber.
Unfortunately, alternative algorithms are more difficult to work with due to their large key sizes among other factors, but it's a price worth paying. At Backbone we've opted not to go down the easy route.
Another concerning realization is how sparingly encryption is used in (many) modern password managers. Sure, it makes search easier but it also leaks secrets stored in metadata fields without any disclosure to the user. And this is in the single-user setting! There are vastly more security considerations as soon as a common "workspace" is involved.
- You're also trusting a large population of Certificate Authorities (CAs), subject to the post-compromise implications of Certificate Transparency. Only one needs to be compromised.
- An app "update" occurs on every page load, giving attackers flexibility and more frequent opportunity to intercept app payloads - perhaps as users cross into networks the attackers control.
- There are currently no sufficient mechanisms to validate the integrity of web app packages end-to-end. Not even under a trust-on-first-use (TOFU) model.
These are all practical constraints we're grappling with while working on Backbone[1], and why deploying native apps is a top priority for us. Nevertheless, we need to reach users where they are, and that means we can't completely deprecate our web app.
> Zero knowledge cloud
> Data in our cloud is end to end encrypted so your credentials are never exposed to anyone but you.
1. You might want to avoid calling this zero-knowledge. While your docs suggest some use of E2EE, there seems to be a significant amount of metadata that remains both unencrypted and unauthenticated.
2. Having read your white paper, it appears your E2EE setup is vulnerable to various forms of forgery. In a simple case, an attacker that has compromised your infrastructure can easily substitute the credentials of arbitrary users in a way that is NOT tamper-evident.
3. There seems to be no post-compromise security. If your user private key is compromised (e.g. extracted from the extension's local storage), there seems to be no way to reset it.
4. The recovery flow is questionable. Do you really want to store critical cryptographic material in plaintext and in a third-party cloud?
When rolling out E2EE from scratch, it's very easy to give rise to issues like #2. At Backbone[1], we've created a framework for building end-to-end encrypted applications with building blocks designed to preserve confidentiality, integrity and nonrepudiatiability under a strict threat model.
Feel free to reach out, we're happy to share how we solved issues like the above.
Lazare very helpfully detailed the internals of the two available formats but I'll summarize them here and I'm happy to answer any questions:
Format A (fuuid) consists of a 4-byte second timestamp concatenated with a 12-byte random tag.
Format B (fuuid_ns) consists of an 8-byte nanosecond timestamp concatenated with an 8-byte random tag.
As far as collision resistance is concerned, here's a list of probabilities at various production rates for Format A. Collisions for Format B are only relevant when the production rate begins to approach 10^9 IDs per second (assuming IDs are produced uniformly in time).
- 2^-90.51 at 10 IDs/second
- 2^-83.73 at 100 IDs/second
- 2^-77.07 at 1,000 IDs/second
- 2^-70.42 at 10,000 IDs/second
- 2^-63.78 at 100,000 IDs/second
- 2^-57.14 at 1,000,000 IDs/second
Hope this helps!