Hacker News new | past | comments | ask | show | jobs | submit | bascule's comments login

It's almost quaint how this December 2019 article talks about "the concern surrounding the creation of large swaths of Tether in 2017", when about $2.5 billion of Tether was issued.

In the time since it was published, when Tether had issued about $4.5 billion total, there have been over $14 billion additional Tether, a 4X expansion of the total supply, or 7.5X what was described as "large swaths of Tether" in this article.


IMO if a few billion is cause for an CFTC investigation then $20B merits an emergency injunction.


Couldn’t agree more.


If you use an unkeyed hash (as opposed to a PRF) on low-entropy inputs, they can be preimaged by an attacker.

This is especially problematic in the case of PII like email address/phone number


Author here.

You're right (if you add a constant-time check upon decryption that the bits are zero).

I suggested as much here yesterday, and may revise the scheme to do so:

https://www.reddit.com/r/crypto/comments/fyn8cs/aesbased_syn...


Does the check even need to be constant time?

The usual use case for a constant time comparison is to avoid allowing an attacker to guess a value one byte at a time. For example, a 16 byte MAC value on a packet could be brute forced byte-by-byte if the system reveals to the attacker which byte the MAC check failed on.

But in the zero padded AES case, the check is being done after an AES decryption operation, so the attacker can't attempt to generate each zero value a byte at a time. After 256 guesses, an attacker able to see timing information could figure out when their 128 bit input guess generated a decrypted value with a valid zero in the first padding byte. But that does them no good trying to generate a zero in the next padding byte because any change they make to their input guess changes all the decrypted output bytes, including that first zero. Each successive zero byte means they have to start over, so generating 8 zero bytes requires 2^64 guesses as far as I can tell.


yer. attacker can't generate longer collisions from shorter collisions so constant time comparison is not necessary. assuming AES in ECB mode and you are not doing something weird like using an IV mode where attacker can tweak the IV to generate different plaintext.


`for` used in a bound (in conjunction with a lifetime) is the syntax for Higher-Rank Trait Bounds (HRTB):

https://doc.rust-lang.org/beta/nomicon/hrtb.html


Yes, but it's not used that way in this snippet...


Call me crazy but I think CRDTs are interesting enough to deserve a repost


I dunno, I heard and read so many times about CRDT that I wouldn't say it's nerdy interesting to just posting wikipedia page here.

Something more, some failure stories like [1] would be interesting.

[1] https://news.ycombinator.com/item?id=19886883


This post is filled with a large number of factual inaccuracies, so numerous I wrote a blog post in response: https://tonyarcieri.com/factual-inaccuracies-of-facebook-lib...


You should submit that


Someone else already did. You can find it here: https://news.ycombinator.com/newest


Direct link to the submission: https://news.ycombinator.com/item?id=21455739


The article also incorrectly claims that curve25519-dalek has never had security audits. It's had at least two by reputable cryptography auditing firms (Quarkslab and NCC), the former of which is public (the NCC audit was done at the request of my former employer and is private, but like the Quarkslab audit only found minor issues):

https://blog.quarkslab.com/security-audit-of-dalek-libraries...


Here's a real world application of Karatsuba: carryless multiplication of finite field elements for cryptography (universal hashing):

https://github.com/RustCrypto/universal-hashes/blob/master/p...

(note: that function is a bit more than Karatsuba, it also has a modular reduction at the end. I should probably refactor it to make that more clear)


Might want to check the names on this IETF draft... https://tools.ietf.org/id/draft-ietf-mls-protocol-02.html


One Facebook author and like apple iMessages which used xmpp they lock the anchor certificate to a walled garden.

They're writing standards and deploying closed ecologies.


I'm not getting the sense from you that you're especially familiar with how this particular IETF effort came together.


True. Since i'm familiar with Richard Barnes I'll ask him in Prague.

Your comments in https://news.ycombinator.com/item?id=16325803 seem relevant.


I'm not optimistic about MLS, the standard. I also don't think it's a secret plot against open protocols.


I don't think I am a secret plot believer. I just observe apple and others deploy group communication software and person to person as walled gardens even when they use xmpp and like protocols.


There's an entire section in my 2019 blog post about this:

https://tonyarcieri.com/rust-in-2019-security-maturity-stabi...

rust-crypto has the most upstream dependencies, but is an unmaintained, abandoned project.

There are a number of other awesome cryptography projects in Rust (in fact some of the most advanced cryptography in the world is being developed in Rust), but they suffer from an awareness problem.

The Go standard library's cryptography, while full-featured and very mature, does suffer from a particular problem: it's a mixture of high-level and low-level APIs all within a single namespace / module. This makes it difficult to compare to Rust projects, because it's an enormous omnibus library, whereas in Rust there is no equivalent to that because the projects are more compartmentalized, and in my opinion that arrangement is preferable to what the Go standard library is doing. See also:

https://cryptocoding.net/index.php/Coding_rules#Avoid_mixing...

The closest thing to an all-in-one crypto library is ring. There's a notable difference between ring and the Go standard library though: ring presents a very high-level, hard-to-misuse API. This makes ring unsuitable for usages where you want "shoot yourself in the foot" cryptographic primitives which are difficult to use correctly and fail catastrophically unless used as such.

For the Rust equivalent of these "shoot yourself in the foot" cryptographic interfaces like Go "crypto/cipher" types such as Block, BlockMode, and Stream, take a look at the Rust Cryptography project:

https://github.com/RustCrypto

Miscreant is built on top of these, and presents an AEAD interface, which could eventually be upstreamed into RustCrypto so Miscreant just implements it.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: