4,104 karma · joined March 12, 2009
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.
This is especially problematic in the case of PII like email address/phone number
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...
https://blog.quarkslab.com/security-audit-of-dalek-libraries...
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)
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.
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.
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."
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 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:
Frankie Knuckles - Your Love, Jesse Saunders - On and On, Mr. Fingers - Can You Feel It, Marshal Jefferson - Move Your Body (The House Music Anthem)
- 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.
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.
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...
That said, regarding JSON and the inclusion of self-describing encoding information for e.g. Base64, I created a microformat for that:
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.
For federated use cases, they are less popular, likely due to the added complexity being a blocker for adoption.
If your OS X daily driver setup is truly stable, can you share all of the details? What OS X version? Yubikey model? GPG version? OpenSSH version?
I know at least a dozen people who have shared my experience so if there is a magic path to stabilizing it, I'm all ears.