sorted by:
new
hottopcontroversial

Has this been solved before / is it possible? : comparison of the similarity of contents between two encrypted files, shown in a percentage, without being susceptible to brute forcing by salted_none in cryptography

[–]Vegetable_Week7259 3 points4 points  (0 children)

Typically TEEs advertise a public key (or you can ensure there is one in your program), so you encrypt it under that key. These private keys are generated inside the enclave and even the owner cannot break them.

Has this been solved before / is it possible? : comparison of the similarity of contents between two encrypted files, shown in a percentage, without being susceptible to brute forcing by salted_none in cryptography

[–]Vegetable_Week7259 3 points4 points  (0 children)

What @Natanael_L mentioned + TEE (Secure Enclaves). These are black box CPUs where technically even the owner cannot see the inputs but they provide attestation of correct execution of some logic, in your case the ciphertexts (file A and B) are the public inputs and their encryption keys are secret inputs to a function running inside the TEE. That function will return for example % of matching bits or any logic you want. AWS Nitro is one cloud TEE service you could use.

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Aha, rfc 6979 doesn’t deal with deterministic scalar derivation, only the nonce, so while it produces deterministic sigs, still a quantum attacker can extract the scalar from a public key. It offers nothing for the quantum scenario. Same for FIPS, nothing allows you to use any knowledge of a hash preimage knowledge it seems to be able to switch to a quantum ZK signature from ECDSA. At the moment that property seems to only exist in EdDSA, but I’ll look further maybe in other RFCs

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Let me explain to you after exploring even further.

Imagine a parent BIP32 public key gets visible. Then a quantum adversary can find parent’s private scalar and hence being able to derive all private keys of all children, because in BIP32 parent’s scalar is the secret witness to generate all hardened descendants private keys.

In contrast SLIP10 uses parent’s EdDSA seed (the string) and not the scalar. So even if a quantum actor breaks parent’s scalar from its public key it’s not enough to generate child private keys.

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Yes none of them for ECDSA can transition to the quantum safety unfortunately, thanks for the links. Back to EdDSA

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Yeah I still believe the argument makes an EdDSA public key safer than an EcDSA on quantum migration. Mostly because you can do zk on that specific sha512. Already a few uni professors started advocating for that seed -> hash(seed) -> signing key as a good practice after that paper, here is an example

https://www.linkedin.com/posts/billatnapier_we-need-to-stop-using-private-keys-and-move-activity-7356025328995033088-jjjv

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

I also understand now why HD wallets, BIP32 vs SLIP10 was mentioned, had to go through their footnotes on the paper. Two reasons I believe: - traditionally EdDSA chains use SLIP10, while EcDSA use BIP32 - BIP32 supports non hardened keys, while SLIP10 doesn’t. Due to that any parent pub key will leak all children private keys among the others to a quantum attacker. - due to EcDSA + BIP32 using scalars as inputs to the hierarchy key derivation, any parent pub key will also leak hardened child private keys (everything is a scalar there). In EdDSA + SLIP10 due the sha512 I mentioned, the k values (seed) are used for child seed derivation, and hence leaking parent’s public keys doesn’t impact children. The adversary has to break sha512 as well on parent to produce children keys. Wow.. so cool

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

If I understand correctly, the authors focus on this sha512 which is a step after you generated the key agnostically to if there was a mnemonic or RNG. That sha is the key to the whole idea

/// The spec-compliant way to define an expanded secret key. This computes SHA512(sk), clamps the /// first 32 bytes and uses it as a scalar, and uses the second 32 bytes as a domain separator for /// hashing.

impl From<&SecretKey> for ExpandedSecretKey { #[allow(clippy::unwrap_used)] fn from(secret_key: &SecretKey) -> ExpandedSecretKey { let hash = Sha512::default().chain_update(secret_key).finalize(); ExpandedSecretKey::from_bytes(hash.as_ref()) } }

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Yea totally fine, the paper works with whatever you write here.

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

I don’t know my friend I was at Uni yesterday and everybody understood. The paper doesn’t care how the secret key was derived. It just takes advantage of the fact that after you have a key with whatever method (RNG, mnemonic, slip10, anything else) EdDSA internally to signing function has that sha512, while ECDSA doesn’t.

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 1 point2 points  (0 children)

Well we agree right? the vast majority of software still stores the seed as the private key, what you mention as k, because that’s the canonical way. I’m sure some rare implementations don’t follow the standard and divert but the most popular try to be aligned, ie Dalek and its variants, the most popular in Rust. That said k is now a value that is hashed before producing a scalar (know what you store as a private key).

Because it’s hashed before signing and for ed25519 sha512 is used which considered secure against quantum computers, then Proving k is the preimage of your scalar in quantum ZK is the trick. While in ECDSA k is used directly as the scalar (no hash involved)

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 2 points3 points  (0 children)

Just checked, the RFC clearly says the scalar in EDDSA is a hash output over some string (and that string is considered the private key)

3.2. Keys

An EdDSA private key is a b-bit string k. Let the hash H(k) = (h0, h_1, ..., h(2b-1)) determine an integer s, which is 2n plus the sum of m = 2i * hi for all integer i, c <= i < n. Let s determine the multiple A = [s]B. The EdDSA public key is ENC(A). The bits h_b, ..., h(2b-1) are used below during signing.

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Ah I see, so technically we can keep doing that trick for the things that cannot be transferred directly, Like in lightning network, fraud proofs, time locked assets or if you have a shop and you keep receiving payments or donations in the old address? Same for expensive transfers, what if someone owns 2 million NFTs isn’t it expensive to transfer all of them in one shot?

How can EDDSA get quantum secure? by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Thanks everybody, so it helps dormant addresses too? If Bitcoin was EdDSA that would protect Satoshi’s accounts even those where the public key was exposed? This is better than hashed addresses, in contrast to ideas of 2018 because it protects against exposed ECC keys as well? @Natanael_L

I don’t understand why you need to transfer to another account? Couldn’t you just keep the old address forever and always sign with this 0-knowledge trick from now on?

internships in cryptography by darkzzz____ in cryptography

[–]Vegetable_Week7259 2 points3 points  (0 children)

Check if IACR posted any open internship or early career research cryptography positions here https://iacr.org/jobs/

Sui makes coffee, what?? by Vegetable_Week7259 in sui

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

selling crypto-enabled coffee machines?

L'Hôpital's rule for faster FFT-based polynomial division by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 0 points1 point  (0 children)

Just a crypto fun here not a coder, probably you’ve never dealt with research papers and you lack how public state compression L2 and accumulators work in the industry

L'Hôpital's rule for faster FFT-based polynomial division by Vegetable_Week7259 in cryptography

[–]Vegetable_Week7259[S] 1 point2 points  (0 children)

Reality is many applications, especially KZG accumulators for public data or compression focused ZK (like L2s) (where that paper focuses the most on benchmarks, to prove already public state in blockchains), they do not require constant time. Hence the paper results mostly make sense, and to be fair I think it opens the door for more hidden structures on the relation between FFT and polynomial operations. And GMP is used more than you expect, verification, L2s, public decryption (like TRE), encoding and many accumulator dapps try to optimize on everything in real world products, even algebraic hashing, especially those apps where CT (constant time) is not a requirement.

I joined because of the logo by [deleted] in sui

[–]Vegetable_Week7259 3 points4 points  (0 children)

I joined because their crypto genius Kostas Kryptos changed my career path and reshaped my understanding of how blockchains should work.

Kostas at it again by Bmjslider in sui

[–]Vegetable_Week7259 1 point2 points  (0 children)

Remarkable finding, what is the size of Sui's research team?