bascule

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.

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

`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

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

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

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

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

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.

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.

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

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

The TB-03 provides a fairly faithful and accurate reproduction of the TB-303's sound.

The TT-303, on the other hand, despite being "circuit identical", can sound downright weird at times (as can Roland's other "analog modeling" 303 reproduction, the TB-3)

Here is a 4 way comparison of the 4 synths I just mentioned complete with waveform visualizations:

https://www.youtube.com/watch?v=r8CAEUU_ics

Hardfloor are masters of the 303. In addition to Acperience, check out their semi-recent track the Art of Acid: https://www.youtube.com/watch?v=5OvWMAzhdOQ

Most early house songs were ~120BPM. This includes:

Frankie Knuckles - Your Love, Jesse Saunders - On and On, Mr. Fingers - Can You Feel It, Marshal Jefferson - Move Your Body (The House Music Anthem)

That's more or less how it was used in one of the first popular tracks to use the 303, Orange Juice - Rip it Up: https://www.youtube.com/watch?v=ESy-Z8vqMrE

If you've ever had your credit card number stolen and used by a criminal for fraudulent purchases which you later disputed, you've used chargebacks.

If that was your point, perhaps you should've mentioned it. That would've made your post informative, rather than merely nitpicking.

> Fisher says, if the phosphorus atoms are incorporated into larger objects called "Posner molecules". These are clusters of six phosphate ions, combined with nine calcium ions.

This article covered more than I was expecting, but still manages to squeeze a small amount of substance into a relatively large article. Here's a tl;dr:

- Penrose and Hameroff postulate microtubules might have quantum mechanical behavior in their Orch-OR hypothesis. This hypothesis was refuted by Max Tegmark in the 90s. Penrose doesn't care and keeps preaching his hypothesis, and has not put forth any new scientifically compelling arguments in the past 2 decades.

- Photosynthesis is shown to be quantum mechanical. I'm not sure quantum mechanical behavior in plants is the best argument that quantum mechanics are responsible for consciousness.

- Fischer hypothesizes that phosphate ions in biological cells might exhibit distinctly quantum mechanical behavior, but is wary about any link to "quantum consciousness".

This is pretty much all of the substance of the article.

Even if there were a conclusively demonstrated link between quantum mechanical behavior in human cells (there isn't), using that to argue that our brains are quantum computers and that consciousness is a fundamentally quantum phenomenon would be a huge non sequitur.

From my benchmarks (oh hi I'm the author of a multi-provider elliptic curve digital signature library for Rust), ed25519-dalek (with curve25519-dalek's AVX2 backend) seems to be winning:

https://twitter.com/bascule/status/1024313525554925568

...for both signing and verification, beating out the fiat-crypto P-256 implementation (in ring, a Rust cryptography library that wraps BoringCrypto).

libsecp256k1 seems slightly slower than fiat-crypto's P-256, even with the endomorphism optimization enabled. The Rust crate presently provide knobs for either of these things, hence the low Signatory benchmarks.

These curves predate Broker-Stevanhagen, however all of the implementations I'm comparing are production(-ish) quality.

There have been some poorly received hypotheses to this effect, most notably Roger Penrose's Orch-OR: https://en.wikipedia.org/wiki/Orchestrated_objective_reducti...

That said, most attempts at quantifying whether or not distinctly quantum mechanical processes in the brain related to things like microtubules and NMDA receptors are significant to cognition (i.e. is the brain a quantum computer?) have generally concluded the answer is no:

See:

https://arxiv.org/abs/quant-ph/9907009

https://onlinelibrary.wiley.com/doi/pdf/10.1207/s15516709cog...

I want to be a fan of csexps. I'm a big fan of SPKI/SDSI conceptually. Unfortunately I lack your enthusiasm for trying to evangelize them, and think JSON is probably here to stay.

That said, regarding JSON and the inclusion of self-describing encoding information for e.g. Base64, I created a microformat for that:

https://www.tjson.org/

Spoilers: it was (at least in regard to software development)

At least post-1975 software development had the Mythical Man-Month to reflect on.

Furthermore, advances in memory safe languages and type safe languages can both be considered good things. Unfortunately, Go is "almost there but not quite" in these two departments.

Client certificates, a.k.a. mutual TLS or "MTLS" authentication, are widely used within infrastructural deployments of TLS, where there are automated mechanisms to provision and rotate certificates.

For federated use cases, they are less popular, likely due to the added complexity being a blocker for adoption.

Same question to you which I asked in the comment linked below... if your OS X setup is truly, actually stable for a daily driver and not just something you use here and there, can you share details?

https://news.ycombinator.com/edit?id=16146856