(Very) Basic Intro to Elliptic Curve Cryptography
qvault.io
qvault.io
===
If however, you know the number of hops you can use an exponentiation trick to find the ending point quite quickly. For example, and omitting the details of elliptic curve operations: 2P = P dot P and then 4P = 2P dot 2P. This allows you to get up to those crazy high calculations exponentially faster.
===
One big difficulty in ECC vs RSA is how to do the math required for the operations. With RSA choosing the keys is the part where dragons lie and you need to make sure the numbers chosen satisfy various criteria. The algorithms for working with keys in RSA are well defined. The opposite is true for ECC. It is easier to choose numbers but depending on the curve used as well as how it is implemented there can be information leaked about the key in timings and other behavior.
If you want to read more check out the Wikipedia article on the Montgomery Ladder ( https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...) as well as DJB's comparison chart of curves that don't support the Montgomery Lader: https://safecurves.cr.yp.to/ladder.html . The real kicker here is that the NIST P-### curves are what ends up in official US government requirements.. and they are vulnerable to side channel attacks due to their design.
https://en.m.wikipedia.org/wiki/Integrated_Encryption_Scheme
This is intuitively similar to how TLS works, in which asymmetric concepts are used in conjunction with a KDF and hashing algorithm to agree upon a per-session symmetric key.
It's impossible to accidentally encrypt a message with the asymmetric cryptographic primitive in the ECC case, but not in the RSA case. This makes ECC misuse-resistant in a way that RSA isn't.
(Although, strictly speaking, you can "encrypt directly" with elliptic curve schemes if you use ElGamal--which might even be desirable in weird systems. Fortunately, most high-level cryptography libraries that offer ECC don't expose the APIs to facilitate this.)
How TLS 1.3 works.
This way of proceeding was introduced earlier, but wasn't the only option until TLS 1.3, in TLS 1.2 for example, even though chances are any TLS 1.2 sites you run offer a more modern Elliptic curve scheme, it was mandatory to implement TLS_RSA_WITH_AES_128_CBC_SHA.
For TLS_RSA_WITH_AES_128_CBC_SHA (and many other schemes) RSA is being used to transport the session keys chosen by the client (and thus implicitly authenticate the server). This means if an adversary gains possession of the server's RSA private key, even perhaps several years later, that's enough to decrypt the session key and thus decrypt all messages that adversary might have captured before.
Whereas with the schemes using Ephemeral Diffie Hellman (whether conventional or elliptic curve) once those ephemeral values are discarded going forward the only way to decrypt the messages secured by them would be something like Shor's algorithm to break DH, hence the term "Forward Secrecy".
1. Integers modulo a prime form a (cyclic) group
2. Cryptographic algorithms like Diffie–Hellman group exchange don’t really care about the integers modulo a prime and can be translated to other groups
3. The security of these algorithms rely on the discrete logarithm (computing a given g and g^a) being hard. For Diffie–Hellman, it is a related problem of computing g^{ab} given g, g^a, and g^b, which might be easier.
4. For integers modulo a prime discrete log is hard but not that hard. Security is measured in the number of bits of one-time-pad the security is equivalent to. It is generally believed that discrete log is harder in elliptic curves, such that a shorter elliptic curve problem (which also gives faster computation) is the same difficulty (ie security) as a larger mod p problem. This is the promise of elliptic curves.
Note here that factoring in general is not replaced: RSA, for which factoring is the important problem, relies on specific properties of modular arithmetic that aren’t really the case for general groups.
Given integers 1, a, and b, compute ab. This is obviously easy. The problem of translating from an arbitrary cyclic group to addition mod n is the discrete log problem, so perhaps that explains why it is important to cryptography that it be hard for your group.
a^(xyz) = ((a^x)^y)^z
and as long as you know how to square, you can pretty much compute exponentials in log2(exponent) time.
https://media.ccc.de/v/31c3_-_6369_-_en_-_saal_1_-_201412272...
For example with bitcoin
(I'm not trying to be snarky, just sort of expressing the sentiment of throwing up my hands after having a grip on P-256 and Curve25519).
If we're not careful some hodlgang hooligan will have this implemented (badly) in Rust in 30 seconds!
Symmetric algorithms such as AES can have their strength reduced as well, but (I have no sources to cite) I believe this reduces it from 256-bit to 128-bit. At 128 bits of security it is still widely considered safe to use.
When you're measuring "bits of security", you say N=2^k, so a classical computer would take O(2^k) and Grover's would take O(sqrt(2^k)) = O(2^(k/2)), or a reduction from k bits of security from a classical adversary to k/2 bits of security from a quantum adversary.
Hence the wisdom that AES-256 is approximately as secure post-quantum as AES-128 is to classical methods.
But bitcoin is a waste of resources by design. The whole point is to waste resources.
A good analogy is password hashes. If you have a hashed value, it is expensive to find the original input. If you want to check that an input is equal to the hashed value, that is a cheap operation.
> But bitcoin is a waste of resources by design. The whole point is to waste resources.