Talk:Elliptic-curve cryptography

message: Interesting research and summary of security for different ECC: https://safecurves.cr.yp.to/  — Preceding unsigned comment added by 153.46.253.213 (talk) 14:18, 4 August 2023 (UTC)
thread_title: Security analysis of ECC

message: From an earlier revision of the article:
For comparison, in 2001 some experts are suggesting these sizes for various public key systems for a security level appropriate to major business transactions that require secrecy:
RSA (based on difficulty of factorisation) 1024 bits.
DSA (based on difficulty of discrete log for integers modulo a prime) 1024 bits.
ECC (based on difficulty of discrete log for discrete ECC system) 200 bits.''
I have removed this until it can be backed up firmly by a cite - instead, I have added external links to research papers in this field. -- The Anome
I refer you to What Wikipedia is not, item 9, and
Most common Wikipedia faux pas "Deleting useful content". You have deleted some useful inline information and replaced it with external links. Bad idea. If you actually know anything about this subject and don't like my numbers, then change them, they are fairly fuzzy and there is no recognized reliable method for generating them. But don't delete them. You didn't even give a reason for deleting them. It is NOT necessary to give a cite for every single factlet on the whole of Wikipedia, and lack of a cite is NOT a good reason to delete content. I'll be back in a few days to revert the edit and maybe add some more discussion. -- Geronimo Jones
See www.nist.gov/encryption for a list of recommended elliptic curves.  ANSI X9 requires a minimum of 80 bits of *symmetric key equivalent* security.  THis means use of SHA-1 with 160 bit output, use of RSA/DSA with 1024 bit keys and use of ECC with 160 bit keys.  Don Johnson
The references of 256 bit ECC keys providing 128-bit security need citation.
Bdamm (talk) 17:23, 13 August 2018 (UTC)
thread_title: Cite required

message: I'm sure as ECC becomes more common, lay-people will be looking for information about it. A lot of these people (like me) are rather put off by seeing mathematical functions in the introductory section. Could someone write a lay description of ECC that doesn't use mathematical symbols?
:I tried to do this. --agr 12:10, 16 April 2006 (UTC)
replies: text: A completely non-mathematical description of ECC is no more than that of PK crypto, so I doubt that it is actually possible to have it. GBL 16:48, 20 April 2006 (UTC)

text: I agree with the original poster - there needs to be an intermediate paragraph describing what's happening in simplified, analogous text before it launches into all the TeX stuff. 82.43.137.103 00:08, 18 February 2007 (UTC)

text: I agree, this is endemic on wikipedia maths articles. 93.97.48.217 (talk) 11:50, 1 August 2010 (UTC)
thread_title:  Non-mathematical description needed 

message: Hello. In the introduction, the article states that elliptic curves used in cryptography are defined over prime or binary fields. However, mainly due to pairing-based cryptography, there has been interest in elliptic curves over ternary fields as well. augustojd 14:25, 2 April 2006 (UTC)
thread_title:  Elliptic curves over ternary fields 

message: Removed from todo:
:Please add a graph such as [a picture of EC over real numbers]
If a picture does not communicate any information there is no reason to include it (there is already such a picture in EC—there is no need to copy it to ECC). 
BTW, this talk page needs major clean up GBL 08:29, 18 April 2006 (UTC)
replies: text: I don't think we need the mathematic intro, either. A reader can read the EC article if they need it. — Matt Crypto 08:45, 18 April 2006 (UTC)
replies: text: There isn't much overlap between the math inro here and the EC article. ECC is a very specialized application of EC. Thanks for the cleanup here, btw. --agr 09:18, 18 April 2006 (UTC)
replies: text:  IMO Mathematical introduction is needed since it is about EC over finite fields and it is not described elsewhere, OTOH Introduction is about PK crypto and general EC and thus can be safely removed here and merged into PK and EC. GBL 16:48, 20 April 2006 (UTC)

text: Sorry, I don't agree. Even if a purely non-technical intro is not feasible, a less technical intro that summarizes the subject is totally appropriate and badly needed in this case.--agr 12:26, 21 April 2006 (UTC)
thread_title: Pictures and intros

message: The link for factoring in "recent advances in factoring" points to the general factorization article; wouldn't the Integer factorization article be more appropriate in this case? lordspaz 16:21, 10 August 2006 (UTC)
thread_title:  Factoring link 

message: Just to note...
> (Another factor is that ElGamal scheme is vulnerable to chosen-ciphertext attacks.)
That's certainly not a real factor as e.g. plain RSA is vulnerable to chosen-ciphertext attacks as well. That's what the padding schemes are for (PCKS, OAEP, SAEP...).
> ...cryptography based on integer factorization (e.g., RSA) and finite-field cryptography (e.g., DSA).
Well, both RSA and standard DSA are based on finite-field cryptography.
83.64.176.129 11:13, 27 August 2006 (UTC)
thread_title:  Cryptographic schemes 

message: The introductory states that "... a user picks two large random primes as his private key, and publishes their product as his public key. The difficulty of factoring ensures that no one else can derive the private key (i.e., the two prime factors) from the public one within a reasonable amount of time." This is wrong. Consider the article RSA; in short, RSA generates two primes, p and q, but these are not the private key. The user then creates two exponents d and e, such that de = k(p-1)(q-1) for some k. (There are other restrictions on e, and I'm unsure if the two are really interchangeable.) Unless certain shortcuts are taken, both p and q are deleted at the end of the key generation process (though n = pq is retained).
In any case, this is a rather crucial distinction: in the system described in the article currently, the public key doesn't contain any information that the holder of the private key (assuming they somehow don't have the public key) doesn't already have, and so it doesn't make sense that it could be used to encrypt data that only they could decrypt.
I've rewritten it, but I'm not very happy with my layman's explanations of things. Future editors, please reference the actual operation of RSA before writing about it; there are a lot of misconceptions about cryptography out there. grendel|khan 21:09, 27 February 2008 (UTC)
replies: text: Yeah, I see how it looks like I'm talking about p and q rather than d and e (the user does create two primes, but they use those to create two different primes which are actually used in the keys--I don't stress that there are two sets of primes). Is it particularly vital to make this distinction? I'm not sure it adds anything to a layman's overview. grendel|khan 21:30, 28 February 2008 (UTC)
replies: text: Well, neither d nor e need to be prime (although in practice e is often a fixed, but not a random prime), so by saying one prime is included in the public key and the other in the private key is strongly suggestive that p is made public, especially to those already familiar with RSA, as typically, the first thing one learns about RSA about is the secret primes p and q, whose product is difficult to factor.  Maybe the article's reference to RSA should be simplified, just to say that is another public key cryptography scheme, which requires integer factorization to be hard, letting RSA explain the details.  —Preceding unsigned comment added by DRLB (talk • contribs) 22:47, 28 February 2008 (UTC)

text: To keep it simple the private is (p,q) and the public N=p*q.  e and d can be introduced in the RSA article along with the RSA problem. Brusegadi (talk) 05:07, 28 February 2008 (UTC)
replies: text: That's still not really accurate. The public key can't just include n; it also has to include e. The essential nature of RSA is that key operations are symmetric: what can be done with one key can only be undone with the other, and vice versa. The system as described is very much a one-way scheme, where the public key can be derived solely from the private key, but not vice versa, which is not how RSA works. The rewritten explanation describes it properly, as does somehow shoehorning in a mention of e in the original description. We shouldn't sacrifice accuracy while we're trying to make the explanation simpler. grendel|khan 21:30, 28 February 2008 (UTC)
replies: text: While it's true that to use a public key, one has to also know the value of e, it is often not specified explicitly, rather all users of a given encryption product typically agree on a default value for e. For example, PGP uses 17 by default and will try other popular values. So e is a technicality that does not have to be discussed here. It has no confidentiality implications in usual practice. All the public key confidentiality is in n.  --agr (talk) 22:54, 28 February 2008 (UTC)
replies: text: I agree.  The most important technical aspect might be   gcd(e,(p - 1)(q - 1))=1 , and the fact that if you choose e such that d is smaller than N^(1/4) then RSA becomes vulnerable (D. Boneh and G. Durfee. Cryptanalysis of RSA with private key d less than N^(.292) . IEEE Trans. Inform. Theory, 46(4):1339-1349, 2000. ) according to my textbook is good further reading...  In summary, I see what grendel says, but I am not sure if adding the bit about e would make things too complicated.  Is there a third opinion thats somewhere in between proposals?    Brusegadi (talk) 03:02, 29 February 2008 (UTC)
replies: text: Right, but that level of detail isn't needed in this article. --agr (talk) 04:19, 29 February 2008 (UTC)
replies: text:  Agreed. The article is about elliptic curve cryptography in general and not just one specific cryptosystem. Hence the introduction should compare the mathematical problems that are the basis of different classes of cryptosystems, i.e. integer factorisation vs. discrete logarithms over GF(p) vs. discrete logarithms over elliptic curves. Details about RSA do not belong here, simply because there are many other cryptosystmes that are also based on integer factorisation. 85.2.102.219 (talk) 06:35, 29 February 2008 (UTC)
replies: text: Yet, we still should be careful about equating solving RSA to integer factorization...  It is not proven that the only way to crack RSA is by factorization...  Am I being too picky?  Brusegadi (talk) 06:44, 29 February 2008 (UTC)
replies: text: If you find such a mistake, fix it. Right now the article only claims that finding the private key is as difficult as factoring, which is correct. Still there is much room to improve the introduction. E.g., right now the introduction appears to claim that DSA is based on factorisation. 85.2.99.242 (talk) 19:12, 1 March 2008 (UTC)
replies: text: Brusegadi's point is that in fact  we don't know if  finding the private key is as difficult as factoring. That is the RSA problem. I tried to clarify the article on this point, without getting too far off topic.--agr (talk) 02:21, 2 March 2008 (UTC)
replies: text: That is wrong. Rivest, Shamir and Adleman already showed in their original RSA paper that N can be factored in propabilistic polynimial time given N,e and d. But it is still unknown whether there exists another method for decrypting RSA that does not require the private key. 85.2.53.248 (talk) 07:58, 2 March 2008 (UTC)
replies: text: Yeah, the RSA problem is to decipher without the private key, with e, N and Cipher text.  We know we can do it if we factor, the question is, can we do it without factoring?  Thus, factoring is not equivalent to solving RSA although the first implies the second... (I am pretty sure of this, I was once penalized for saying they were equivalent...)  Brusegadi (talk) 08:24, 2 March 2008 (UTC)
replies: text: Sorry, you're right, I missed that distinction, but I think the current article text still covers this point.--agr (talk) 12:41, 2 March 2008 (UTC)
thread_title:  The section referencing RSA is wrong. 

message: This article is written almost entirely from the mathematical POV. There are other important POVs which should be reflected here. 
For example, what guides a design choice to incorporate ECC vs. alternatives? How does ECC compare to alternatives such as RSA? e.g. the key length is shorter, computational complexity on each side of an exchange, etc.  —Preceding unsigned comment added by 192.118.32.80 (talk) 08:46, 13 December 2009 (UTC)
thread_title:  Design choices and ECC 

message: The link hxxp://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml in reference 3 is broken. –84.157.71.42 (talk)  —Preceding undated comment added 19:32, 17 June 2010 (UTC)
thread_title:  Broken link in reference 

message: The article currently states that "For cryptographic application the order of G [...] must be prime."  This agrees with SP800-56A, but the only references I have seen that justify a restriction on the order only say that it should be large and divisible by a large prime.  (E.g., Algebraic aspects of cryptography, Neal Koblitz.)  Does anyone know of a reason why the order would have to be prime? Doctorhook (talk) 20:24, 22 December 2010 (UTC)
replies: text: You're right, it does not have to be prime. If it is not prime, then some complexity would be added to some protocols. For example, someone might choose a public key that has order 2, and that is useless. So it is customary to choose the generator to have prime order. Roger (talk) 22:48, 22 December 2010 (UTC)
thread_title:  Generator 

message: The first of the external links () shows a page with no substantial or interactive content to me? Gryllida 03:07, 21 November 2011 (UTC)
thread_title:  External link one 

message: In reference to quantum computing attacks the article reads "Elliptic curve cryptography is vulnerable to a modified Shor's algorithm for solving the discrete logarithm problem on elliptic curves" with two citations (). Looking through both of these citations, they both work over fields of prime order, with the latter paper explicitly stating that they did not consider fields of prime power order. If  ECC over fields of prime power order is truly vulnerable to QC attacks, I think there should be a citation that references this. GromXXVII (talk) 22:20, 25 June 2012 (UTC)
replies: text: Good catch! I updated the reference. If you need more information or have any other ideas, please share. Skippydo (talk) 01:58, 26 June 2012 (UTC)
replies: text: I found a copy of the first 1997 Eicher reference if it is still of use: (cite tag: ).  I (probably is) be outdated though, though it might be useful for background info (?). Jimw338 (talk) 04:18, 12 September 2016 (UTC)
thread_title:  Quantum Computing Attack Citations 

message: I don't have the technical competence to write a section about this, but I think it is important to point out that there is serious speculation that the NSA inserted a backdoor into the NIST Special Publication 800-90 Dual_EC_DRBG elliptic curve pseudo random generator. If I understand the concern, it is basically that some defined constants in the standard are related to a second, unknown set of numbers, but whoever originally generated those constants does know those numbers. Cryptographic experts say that whoever knows those numbers can gain encryption keys given only 32 bytes of cyphertext.
The technical discussion of the issue is found in these sources:
http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115
http://eprint.iacr.org/2007/048.pdf
http://rump2007.cr.yp.to/15-shumow.pdf
And some analysis of the possibility that these concerns are founded, based on leaks from Edward Snowden, is found here:
http://arstechnica.com/security/2013/09/the-nsas-work-to-make-crypto-worse-and-better/  — Preceding unsigned comment added by 24.126.40.36 (talk) 17:29, 6 September 2013 (UTC)
replies: text: Wrong place here. Go to the Dual_EC_DRBG article. Besides this is about a specific random number generator. It's about a possible weakness on the practicality of the technique based on geometrical identity of elliptic curves, I think. Something like finding a twin to get the answer. Mightyname (talk) 20:39, 6 September 2013 (UTC)
replies: text: I think it might be appropriate to mention it in the section about NIST-recommended elliptic curves.  I think there are good sources in the Slashdot summary: http://it.slashdot.org/firehose.pl?op=view&type=story&sid=13/09/11/1224252  Yakatz (talk) 15:35, 11 September 2013 (UTC)
replies: text: considering the gravity of the scandal, there should obviously be a paragraph dedicated to it here. Details can still go to Dual_EC_DRBG, but the topic needs to be given WP:SS treatment on this page, because this page is the first people will come to when they read about the "NSA ECC backdoor". --dab (𒁳) 10:10, 21 September 2013 (UTC)
replies: text: I think this is quite out of topic and should be removed. Even though there are links between random number generation and cryptography, Dual_EC_DBRG is a random number generator, based on elliptic curves (the mathematical objects). This article should be about the cryptographic primitives. #!/bin/DokReggar -talk 12:46, 3 January 2014 (UTC)

text: I strongly disagree. There is no such thing as an NSA ECC backdoor (that we know of), there is an NSA Dual_EC_DBRG backdoor. Furthermore, the fact that elliptic curves were used as the construct for this RNG is a mere detail; the NSA could have just as easily based this upon modular exponentiation in integer fields. Elliptic curves just happen to be used by this backdoored construct, but this coincidence is only of interest in other articles. It is irrelevant here, especially when positioned actual implementation issues specific to elliptic curve cryptography. Please remove it here.  — Preceding unsigned comment added by 130.89.106.70 (talk • contribs) 15:22, 17 March 2014 (UTC)
replies: text: You should clearly read the text a little more closely. The fact that quotable sources are making comments about the possible untrustworthiness of the NSA-recommended elliptic curves, and hence on their use in ECC, is relevant in the section.  —Quondum 18:09, 17 March 2014 (UTC)
thread_title:  Possible NSA backdoor 

message: The article states, under the heading "Domain Parameters," that
:  For cryptographic application the order of G, that is the smallest positive number n such that n G = \infty, is normally prime.
The order of an element G in an additive group is the smallest positive integer n such that nG = 0, not ∞ (Gallian, Contemporary Abstract Algebra, ch. 4). This needs to be fixed.
John (talk) 15:37, 3 November 2014 (UTC)
replies: text:  I believe either is accurate -- it's equal to the identity element of the group (denoted 0 (zero), O (uppercase o), or e), which is a point at infinity, specifically [0:1:0]. I suspect this is what the original author was trying to convey.... gurnec (talk) 21:33, 15 January 2015 (UTC)
thread_title:  Group Order 

message: Hello fellow Wikipedians,
I have just modified  on Elliptic curve cryptography. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20110719233751/https://www.certicom.com/index.php/2004-press-releases/36-2004-press-releases/300-solution-required-team-of-mathematicians-2600-computers-and-17-months- to http://www.certicom.com/index.php/2004-press-releases/36-2004-press-releases/300-solution-required-team-of-mathematicians-2600-computers-and-17-months-
*Added archive https://web.archive.org/web/20060327202009/https://anziamj.austms.org.au:80/V44/CTAC2001/Hitc/Hitc.pdf to http://anziamj.austms.org.au/V44/CTAC2001/Hitc/Hitc.pdf
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Archive link for anziamj.austms.org.au fails with 504 Gateway Timeout
Cheers.—InternetArchiveBot (Report bug) 20:15, 11 September 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified  on Elliptic curve cryptography. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20090117023500/http://www.nsa.gov/business/programs/elliptic_curve.shtml to http://www.nsa.gov/business/programs/elliptic_curve.shtml
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 02:32, 23 December 2016 (UTC)
thread_title:  External links modified 

message: Hello fellow Wikipedians,
I have just modified 2 external links on Elliptic-curve cryptography. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20140503190338/http://eprint.iacr.org/2011/506 to https://eprint.iacr.org/2011/506
*Added archive https://archive.is/20121208212741/http://wiki.crypto.rub.de/Buch/movies.php to http://wiki.crypto.rub.de/Buch/movies.php
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:14, 19 September 2017 (UTC)
thread_title:  External links modified 

message: This article doesn't contain the algorithm for ECC like the RSA article does.  — Preceding unsigned comment added by 198.52.160.180 (talk) 20:30, 6 December 2019 (UTC)
thread_title: Algorithm needed

message: The first paragraph states that ECC is based on finite fields, as opposed to non-EC cryptography, which is based on plain Galois fields. However, the referenced article on finite fields explains that finite fields and Galois fields are one and the same. I suspect the intended meaning is that non-EC crypto is based structures over finite fields which are not elliptic curves. If so, this is not clear from the text. I won't change the formulation myself, since I'm not an expert in the field.  — Preceding unsigned comment added by VecLuci (talk • contribs) 04:13, 10 October 2018 (UTC)
thread_title:  The first paragraph seems self-contradictory 

message: "Five prime fields \mathbb{F}_p for certain primes p of sizes 192, 224, 256, 384, and  bits. For each of the prime fields, one elliptic curve is recommended."
Should there be a footnote about that 521 not being a typo? It really is 521 (see  among many, many sources) but it really looks like someone mis-typed "512". 76.216.220.191 (talk) 04:00, 28 December 2021 (UTC)
thread_title:  Not a typo. 521, not 512.