bascule
Joined 17 years ago
Karma
4,104
Submissions
649
Member since
Mar 12
Recent submissions
Comment · 6 years ago
Comment · 6 years ago
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
Comment · 6 years ago
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...
Comment · 7 years ago
`for` used in a bound (in conjunction with a lifetime) is the syntax for Higher-Rank Trait Bounds (HRTB):
Comment · 7 years ago
Call me crazy but I think CRDTs are interesting enough to deserve a repost
Comment · 7 years ago
Someone else already did. You can find it here: https://news.ycombinator.com/newest
Comment · 7 years ago
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...
Comment · 7 years ago
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...
Comment · 7 years ago
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)
Comment · 7 years ago
Might want to check the names on this IETF draft... https://tools.ietf.org/id/draft-ietf-mls-protocol-02.html
Comment · 7 years ago
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:
Miscreant is built on top of these, and presents an AEAD interface, which could eventually be upstreamed into RustCrypto so Miscreant just implements it.
Comment · 7 years ago
I think what you're after is:
https://docs.rs/miscreant/0.4.2/miscreant/aead/trait.Aead.ht...
These take a byte slice, and return an (allocated) byte vector.
The APIs you're talking about are special in-place ones for Miscreant's #![no_std] support, i.e. for embedded use or other usages which want to avoid heap allocations.
It's nice to support both of these usage patterns, because the allocating version has nicer ergonomics, but not everyone in the world has a heap.
Comment · 8 years ago
One possible solution: get Bluetooth headphones instead, such as the equivalent Bluetooth Audio-Technica headphones to what's pictured in the post, the ATH-DSR9BT:
https://www.audio-technica.com/cms/headphones/6117c014c965cd...
"The ATH-DSR9BT over-ear wireless headphones employ Audio-Technica’s new Pure Digital Drive system, which allows the headphones to operate without a sound-degrading D/A converter that conventional wireless headphones rely upon. Instead, the ATH-DSR9BT utilizes Trigence Semiconductor’s Dnote chipset to receive the digital audio signal from a Bluetooth wireless transmission, process and transfer it to the driver where the digital pulses of the chipset move the voice coil and diaphragm forward and backward to create the sound waves heard by the listener."
Comment · 8 years ago
> you need a remedy for the inherent insecurity of credit cards
Fraud and theft are fairly general problems. I would direct your attention to /r/sorryforyourloss
> In other words, are merchants eating all the costs of fraudulent credit card transactions?
If the goods cannot be recovered, then yes, the merchant eats the costs.
> I guess either way the cost really gets passed on to us consumers in the end.
Someone will always be left holding the short end of the stick when fraud occurs. The alternative to shifting the liability to the merchant is the consumer being directly accountable (rather than vicariously as you're suggesting).
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.