Schnorr Claims to Have Destroyed the RSA Cryptosystem

Seriously - https://eprint.iacr.org/2021/232.pdf

The final sentence in the Abstract is, "This destroys the RSA cryptosystem"

This is profound if true. I'm obviously not qualified to audit Schnorr's work, but we can rest assured that peers in cryptography academia are pouring over this paper as we speak.

The paper is a legitimate eprint and various professionals have contacted Schnorr to confirm that he indeed is the true publisher of the paper (and that this isn't a hoax / someone looking to rile up bullshit).

'

Initial Reception From Various Individuals

Truthfully, the reception has been extremely skeptical with most requesting Schnorr to provide concrete proofs showing RSA being broken in practice.

This feels reasonable.

We'll have to see how this one evolves over the next day or so.

To claim that he has broken RSA is profound, if true. This is an obviously well-known cryptographer that has earned respect for his contributions in the field of cryptography.

So one would assume that he values his credibility and name as much as you would expect from someone of his stature. To make the claim that the "RSA cryptosystem is destroyed" is a ludicrous statement to make if he truly has no proofs.

I'm going to optimistically assume that Schnorr has additional information / proofs / breakdowns to rebut.

If not, then I'm sure there will be a response paper published in a few days, at most. This is extremely interesting as a spectator to be honest

Picnic Signature Specification (optimized) = https://github.com/IAIK/Picnic

bcrypto library = https://github.com/bcoin-org/bcrypto

Using PGP Encryption With NodeJS = https://www.loginradius.com/blog/async/using-pgp-encryption-with-nodejs/

Aggregatable Distributed Key Generation

Not sure how much novelty there is in the construction of this protocol, but there was a preprint shared today, posted at this URL =

A less 'academic' write-up of the scheme was published on one of the team member's blogs here = https://www.benthamsgaze.org/2021/03/24/aggregatable-distributed-key-generation/

General Thoughts

The use here is obvious, but I'm still not sure if it has been all the way justified that this scheme's construction is uniquely different than what already exists currenlty.

Example From Ethereum: https://github.com/herumi/bls

There are other examples if you look deep enough on the internet (with better explanations on how they're supposed to work within the context of something that many would consider to be valuable at this point in time [i.e., blockchain])

Publisher of That Reddit Post

Hmm, we start to get interesting results when we track down certain individuals, don't we?

url = https://www.reddit.com/user/sjmurdoch/

Pseudo-Useful Contributions to the Blockchain Space

Specifically this can be seen here in this whitepaper by Alin Tomescu: https://people.csail.mit.edu/alinush/papers/catena-sp2017.pdf

What the Paper is About

(you won't believe this idea here)

The paper goes into somewhat of a droning shpill at its outset about 'equivocation' on the blockchain (think the term that they're looking for here would be better encapsulated within the idea of 'finality').

They make the correct deduction that if one were to anchor an identity / concept to an underlying blockchain (i.e., 'Bitcoin'), then one would be forced to download the entire chain (in order to retain the property of trustlessness conferred by Bitcoin)

So (rather than fixing Bitcoin - because nobody ever wants to fucking do that), this individuals proposed to create "logs" that abstract from the Bitcoin network by building another layer over top of it in some sort of capcity.

No Trustless Consensus - No Benefit

The benefit of blockchain = trustless consensus.

Do anything that mitigates, reduces, hampers, etc., that process should be considered something that's not wholly blockchain.

Scrape: Scalable Randomness Attested by Public Entities

Interesting, published by IOHK (under Cardano if you're familiar with crypto projects).

URL = https://cryptorating.eu/whitepapers/Cardano/216.pdf

GnuPG v2.3.0 Beta Testing

You can check out the actual release for GnuPG 2.3.0 (beta) here = https://github.com/gpg/gnupg/releases/tag/Beta-2.3.0-beta1655

There are a ton of modifications that have been made to how this tool performs PGP encryption, in general.

Was able to build the project w relative ease.

Definitely very cool to use ; much needed update over what we were used to w prior GPG versions.

Ed448 Comes to PGP

This is a welcome addition to PGP (as this provides the strength of 10k+ length RSA keys).

Some notable additions:

1. 'Experimental database' daemon

2. tpmd2d (new daemon to physically bind keys to the local machine)

3. ed25519 made the default algorithm

4. Supports AEAD encryption mode using OCB or EAX

5. Supprots creation of EdDSA certs as well

6. Enhanced ssh-agent support

7. Telesec Signature Card v2.0 support

8. PIV card support

9. Smartcard support

10. LDAP authentication support (this is unique)

11. "gpg-card" as a tool to interface w other smart cards of all types

Among some other additions (see those here = https://github.com/gpg/gnupg/blob/master/NEWS)

I've already taken the liberty of installing all of the necessary components on my computer first from their repo (very easy to do, will probably roll this in a Docker fiole in the near future and release that to everyone in this channel so that you can have that too).

Needed to tweak a couple of things to get ed448 signatures going (had a previous version of gpgconf + gpg-agent already pre-installed, so had to ensure that the correct modules were being referenced). Overall though - smooth experience.

This is beta, so please keep that in mind (they'll remind you of that frequently though.

Back to Cryptography

1. https://github.com/claucece/useful-crypto-resources

2. https://github.com/Deadlyelder/Tools-for-Cryptanalysis

3. https://github.com/hellman/cryptools

PQSignatures = http://www.pqsignatures.org

https://cr.yp.to/crypto.html (Daniel J. Bernstein; the man, the myth, the legend)

1. ssb-box-stream: https://crates.io/crates/ssb-box-stream

2. captain-lib: https://crates.io/crates/capitan-lib

3. snocat: https://crates.io/crates/snocat

4. xoodyak: https://crates.io/crates/xoodyak

5. xsalsa20poly1305: https://crates.io/crates/xsalsa20poly1305

"NOBUS" ('nobody but us')

This concept refers to a specific exploit / vulnerability that has been brought to the attention of the NSA that it decides to leave unpatched (or instructs the relevant vendor [i.e., Microsoft or Intel, for example, to leave unpatched]) in cases where the agency believes that they are the only ones with the knowledge, sophistication and resource to actually leverage a compromising attack against the software that utilizes the specific vulnerability / exploit that has been brought to their attention.

According to a statement from NSA Director Michael Hayden:

"You look at a vulnerability through a different lens if even with the vulnerability it requires substantial computational power or substantial other attributes and you have to make the judgment who else can do this? If there's a vulnerability here that weakens encryption but you still need four acres of Cray computers in the basement in order to work it you kind of think "NOBUS" and that's a vulnerability we are not ethically or legally compelled to try to patch – it's one that ethically and legally we could try to exploit in order to keep Americans safe from others."

The obvious stupidity in this policy is:

1. The idea that the NSA possesses such an inherent (and permanent) advantage vs. all others on planet earth that there could exist vulnerabilities / exploits that only it could exploit (and nobody else; American hubris at its finest possibly)

2. The idea that there are no 'double agents', 'spies' (etc.) that are embedded within the relevant intelligence agencies dealing with these secrets.

3. The failure to put a 'cap' or timestamped limit for when the vulnerability will be patched. For example, perhaps they find a vulnerability that they consider to be NOBUS in 2011, and decide to leave that exploit unpatched - when does it become patched? Surely, the NSA cannot have believed that they stumbled across exploits that nobody would ever be able to exploit at any point in time - either then or in the future, right?

4. The NSA has frequently made purchases of certain exploits on the 'grey market' from various vendors. To leave those exploits unpatched exhibits stupidity in its rawest form because, by virtue of the fact that there exists a 3rd-party vendor with the ability to find certain zero-day vulnerabilities in software (among other things), means that the assumption should be that there exists 3rd-parties (in general), with the capability to find the same bugs / exploits and leverage them by passing that information on to their respective intelligence unit(s).

This policy of 'NOBUS' has resulted in tens of millions of Americans becoming the victim of various data breaches, hacks, ransomware etc.

State Cannot Be Trusted With Decryption Powers

These powers continue to be abused at a level that breaches criminality.

Therefore, strong encryption is recommended at any and all costs.

The argument against child abuse is a valid one, even if used disingenuously by various agencies seeking to deprive citizens of their right to privacy. However, the gov't needs to find other ways to stop & prevent human trafficking and other sex crimes.

If they're decrypting communications after-the-fact, then they're already too late.

The goal should not be just to apprehend criminals, but rather find ways to prevent the crime itself from happening. Even if only pedophiles had their data accessed via an encryption backdoor (solely) and the gov't / law enforcement used that information to arrest said pedophile, the child whom the pedophile has harmed is still harmed.

The goal must be to prevent that child from being harmed in the first place. Settling for apprehending the offenders after-the-fact is a half-assed consolation prize that betrays the fact that the gov't (or whatever law enforcement making such arguments) may not really give a fuck about this issue.

Libsodium Documentation (great) = https://libsodium.gitbook.io/doc/memory_management

^^^ Memory management. Making sure that your keys / secrets aren't exfiltrated - this is important.

FSCrypt (should be putting this in the @librecryptography channel as well)

Think that this is a great file-level encryption tool for those that are looking for one (hell of a lot better than encryptFS where the author of that tool didn't want to get off of their ass to ensure that it was equipped with the latest & greatest as it pertains to standardized cryptographic algorithms - specifically KDFs [dumbass insisted on leaving Scrypt - which is vulnerable to side channel / timing attacks] - https://opensourcelibs.com/lib/fscrypt

FSCrypt uses Argon2i for its KDF (believe that it also leverages XChaCha20-Poly1305 for encryption as well (could be wrong on that - but check the encryption to see if this is something that I'm wrong about)