Quote from: 247poker on November 27, 2014, 08:52:24 PM

Now to you is he a genius or should he be mocked on this forum like you are doing. Face it, if you mock Dr. Adoni and his brilliant 30Mod Prime Algorithm the NSA is paying you to mock him.

Not sure if troll, or really that stupid. I'm going with the latter. Adoni and his crackpottery have plenty of company, all of it cooky. You either are him, or have fallen for his nonsense because you have little to no mathematical background.

Quote from: Vessko on November 26, 2014, 09:31:34 AM

This is conspiracy theory bullshit written by somebody with no clue in mathematics, number theory, primality testing, cryptography and so on.

Yes, the prime numbers distribution is not random and Ulam spirals are real but they are nothing more than a curious pattern with no practical applications. There is no magic formula that will yield simultaneously a) only primes, b) all primes and c) different primes every time without some kind of brute force testing.

...

Finally, someone else in this thread with some decent knowledge of modern mathematical algorithms and any mathematical background. Hear, hear!

Quote from: Vessko on November 26, 2014, 09:31:34 AM

That said, how exactly the NIST elliptic curves are picked is a concern and I personally don't trust Elliptic Curve Encryption - but that's only because I don't have a sufficiently good understanding of it (while I do understand and prefer RSA encryption). But nobody forces you to use the NIST curves. You can easily pick different ones and still use EC-based cryptography.

(quick intro: Bitcoin uses the secp256k1 curve. The only remotely suspicious things here are the generator base point G, and the choice of P as nextprime(2^256-2^32-2^10).) For you and anyone else interested in ECC and whether the base point G in secp256k1 could be a problem, read the post at https://bitcointalk.org/index.php?topic=289795.msg3183975#msg3183975 (also see https://bitcointalk.org/index.php?topic=289795.msg3206788#msg3206788 for a nothing-up-my-sleeve derivation of the rest of the parameters in secp256k1). Specifically:

Quote

3. The base point G is something I cannot explain, but the general understanding, at the time and still now, is that the base point G cannot contain a backdoor in the main problem underlying ECC, namely ECDLP and ECDHP. Indeed, random self-reducibility applies to prove that the choice of G is irrelevant for most versions of these problems. Some cryptographic schemes, including ECDSA, seem to depend mildly on some other problems, in which the choice of G may be more relevant. In particular, the ECDSA verification of a signature (r,s) includes a check that r is not zero. If this check is dropped, then there is a possibility that party who chose G can have chosen G in such that to make some signature (0,s) valid for a particular message m. (For details and examples, see my chapter in Advances in Cryptology II, or my paper Generic Groups, Collisiion Resistance, and ECDSA, or my IACR eprint The One-Up Problem for ECDSA.) I strongly doubt that G is malicious, because these properties were not widely known at the time, and the adversary seems to have little to gain, the verifier has to be faulty.

Also:

Quote from: gmaxwell on July 24, 2014, 01:58:24 AM

Quote from: hashman on July 24, 2014, 01:10:06 AM

When you say G is provably irrelevant, I can only assume (and I'd rather not hence this reply) that you mean a choice of G cannot effect the ability of an attacker to brute force a private key. While there are convincing arguments of that in this thread, I wouldn't call any of them a proof.

You can transform any pubkey on any G to a pubkey on another generator by means of addition. In particular, if there is some bad generator O where you can compute the log of Ox for arbitrary x easily, one can use find the discrete log of Gx as log_O(Gx)/log_O(G) mod order. One doesn't need to prove anything about the hardness of the discrete log to just show the arithmetic relation that if on a curve discrete log is insecure with respect to one generator then discrete log is insecure with respect to all generators of that group.

A better example that I could have given is how the byte order is chosen (big endian or little endian). You surely can't create an implementation without knowing how to deseralize the bytes, but byte order isn't relevant to security.

So if one G is broken, then they all are. It doesn't matter whether G is nothing-up-my-sleeve or specially chosen one way or another: either the NSA has an algorithm to break Bitcoin with any G, or they don't.