kpdemetriou

Unlike Dual_EC_DRBG, Bitcoin doesn't use suspicious unexplained constants - all major constants have clear justifications as far as I'm aware.

Cord is a deterministic serialization format built in Rust, designed for security-sensitive applications where consistent and unambiguous binary representations are essential.

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.

I'm not sure what you mean - Minibone's entire purpose is to allow you to not trust the server with users' plaintext data.

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.

I'm curious, how do you imagine using it in Python?

Think of it this way: if your database gets breached, your app won't leak user data if your users aren't all targeted by active attackers. It's not a substitute for transport security.

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.

One of the authors here. Streaming is actually in the works.

It's much more bare-bones. Minibone exposes a more approachable and misuse-resistant higher-level API including support for things like opportunistic key rotations and groundwork for forward evolution!

Re: BLAKE2, I'm not sure it's fair to say that BLAKE2 is more widely used overall. But I do agree BLAKE2 is a bit of an outlier in terms of adoption. I think part of the reason is that SHA2 remains the go-to option, else I'd expect the ecosystem to consolidate around SHA3.

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.

Implemented correctly, I agree the difference in security margin may not be too important. Otherwise, Serpent is more resistant to timing attacks. Weaknesses in implementation are as important as weaknesses in design.

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).

Absolutely, but NIST ultimately choose the winners, giving them the option to pick (non-obviously) weak/weaker algorithms. Historically only the winners are adopted. Look at the AES competition - how often do you see Serpent being mentioned, despite it having a larger security margin than Rijndael by most accounts?