1486:
usage. Example of actual usage makes a different point, the noteworthiness of the technology, since it is used so often, by so many people. In other words, it is notable not just because it is interesting, it is in some standards, it is in some crypto libraries, it is in various protocols and products, but many devices are actually using it frequently, in the past and still today. In fact your device just used it, to verify the current WP page, to bring home the point, as a small but easily replicable sample. Perhaps, it would be clearer, and stabler to show the WP certificate, instead of a summary report of a single ephemeral TLS session. So, I propose restoring the example usage, although improvements and clarifications would help greatly.
242:
232:
211:
532:
341:
320:
440:
409:
508:
179:
119:
92:
61:
32:
594:
1571:
The
Digital Signature Algorithm (DSA) operates over any cyclic group and is fairly straight forward. EC-DSA is simply the DSA, but over an elliptic curve group -- the algorithm itself is identical with that in mind. This EC-DSA article should have been a subsection in the DSA article, not a separate
1551:
The RSA encryption method, which is also asymmetric, permits a series of simplified explanations, based on the difficulty of calculating two large prime numbers given their product, and explaining how and why modulo operations are used. Why can't this article build up from a similar simple statement
836:
was calculated by applying a symmetric cipher to the HASH value; if the attacker does not know the symmetric key which was used for this, then this should not help the attacker (?), because for a secure symmetric cipher, the output should be unpredictable if you do not know the symmetric key for the
719:
I am new to ECC. It seems to me that the given signature scheme (the one with (mod n)) still is a little bit dangerous: If you sign two different messages (with hashes e_1 and e_2), with the same "random" number k, then an attacker will be able to reconstruct "d_A" (the secret key) without problems:
1485:
The example usage section has been removed, on the the grounds that it is does not show how ECDSA works, and possibly on the grounds that the algorithm could change at any time (and perhaps also on the grounds that alternatives to ECDSA are deemed preferable). Well, that's not the point of example
787:
For RSA you only need to generate a secure key (meaning that the key has to be "real" random). Then for signatures, there is not much more you can do wrong. So I think RSA is the easier to use scheme, in the sense that you do not need an additional cryptographically secure random number generator.
1372:
Currently, the wikipedia web site seems to be using TLS 1.2: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1035_SHA256, 256 bit keys, So, browsers show the lock icon because wikipedia signed something with ECDSA, and browser has verified the signature (and validate the certificate for the ECDSA signing key).
1469:
Using WP (or any other website) as an example doesn't seem like a great idea - it's inherently at the mercy of configuration changes. A better example might be a specific root certificate, or a some more slowly evolving system. For example the UK smart metering infrastructure mandates ECDSA over
795:
certainly is something that must be implemented very carefully in ECDSA. However, RSA has its share of pitfalls too. E.g., the private key might be leaked if a miscalculation occurs during a signature generation. Proper padding must be used, etc. Often standards do help to address potential
1306:
It's just a convention to talk about n-bits of security. From there you can estimate, for example, that 80-bit security is in the "possible to brute force, but at great expense" ballpark. But you're right, there are more informative ways to discuss specific aspects of resistance to attack.
1290:
There may be other problems as well. Finding the private key is the most devastating attack, but far from the only one. For example, if it takes only, say, 2 effort to find a collision, then arguably the system has only 40-bit security no matter how expensive finding the key is.
1286:
would be more useful and does seem possible; that is how the level is defined in other contexts. For example breaking a block cipher with an n-bit key by brute force takes 2 encryptions on average. The minimum is 1 and the maximum 2, but those numbers are not usually mentioned.
893:
The issue is variously addressed in the literature, I don't know how it is in the standard. And correcting it here might require modifications to other pages too. It is a huge task, I don't have time now to even start to list all the pages affected (in the several languages).
692:
then the secret key leaks from the signatures. What you describe is a variant of ECDSA that does indeed not need modular reductions and hencecan be used with elliptic curves with unknown order. This variant has several disadvantages however. E.g., the random number
889:
The elliptic curve coordinates are defined on any finite field, so computing mod n does not make any sense. For example the field might be of characteristic 2. It might seem straightforward for large prime fields, but it is incorrect always unless specified.
1175:
I realize that this is a very dense topic, but this article is barely readable. The jargon should be trimmed down, and perhaps we can add some more encyclopedic content, like present-day usage of ECDSA (technologies like WAP and SSL to name a couple).
885:
For Alice to sign a message {\displaystyle m} , she follows these steps: .... 4. Calculate the curve point {\displaystyle (x_{1},y_{1})=k\times G} . 5. Calculate {\displaystyle r=x_{1}\,{\bmod {\,}}n} . If {\displaystyle r=0} , go back to step 3.
1154:
Feel free to edit the article to clear this up! My suggestion is to not dive too deep into the math in the article, but rather just emphasize the prime-field case and add footnotes where important for the characteristic-2 field case.
780:
I understand. Still: This basically means that you have to be extremely careful with how you generate your "k". If an attacker has only the slightest idea of the value "k", which was chosen for a signature, then you are definitely in
1270:
Current text mentions "a security level of 80 bits (meaning an attacker requires a maximum of about 2 80 {\displaystyle 2^{80}} 2^{80} operations to find the private key)". That seems badly flawed to me. I'd like to be able to say
927:
You are right, this is straightforward for prime fields but it's vague for characteristic-2 fields. The go-to document for ECDSA (in my opinion) is Daniel R. L. Brown's SEC1, which is referenced in the
Further Reading section. In
1521:
the signature size is the same for both DSA and ECDSA: approximately 4 t {\displaystyle 4t} 4t bits, where t {\displaystyle t} t is the security level measured in bits, that is, about 320 bits for a security level of 80 bits.
737:
From this it is easy to calculate kInv. With kInv you get k. With k you get d_A. This basically means you must never sign two different messages with the same random numbers of "k". Correct ? (Of course since "n" should be :
820:. Of kourse this means, that you must keep the symmetric key secret (in the same way you keep your private ECC key secret). Is there an obvious flaw in such a scheme ? To me it seems the most important thing about
1054:
897:
One needs to specify a map from the elliptic curve to the integers, and this might be straightforward in some cases but how to define the map and which properties are needed for security is not clear.
1737:
391:
169:
785:
For the ECC DSA scheme, you basically need a private key, a private random seed file and a real good (cryptographically secure!) random number generator; otherwise the whole scheme is compromised.
1687:
381:
663:
a function to convert a point to an integer (by example returning coordinate x) G generator point a secret key (integer) P pubic key point (P=aG) h hash of message (integer) k random number
1220:
It is a common error to use the complete hash value with modular reduction in signature computation. The standards require instead a truncation (cf. the references given in the article).
625:
1003:
1575:
For a simplified explanation, first look at DSA. Now swap out 'modular exponentiation' with 'scalar multiplication of a point on an elliptic curve' and you are essentially done.
1717:
1682:
1732:
1652:
546:
193:
42:
1139:
1105:
969:
709:
do not leak useful information about the secret key. Hence signing and verifying signatures are less efficient. Moreover, the signatures are longer in this variant.
1657:
1642:
159:
1449:
This may be partly due to the way openssl TLS client negotiates the cryptography. Maybe a more thorough analysis should be done before updating the article.
1692:
302:
1727:
1672:
1336:
292:
1201:
article, for further consistency. For example, the hash function notation (HASH(m) here, H(m) in the other article) and the modulo notation are different.
1702:
1662:
1647:
1151:
and a formal procedure is included as well. You can also see that the conversion of hash bytes to an integer is more precisely defined (it's big-endian).
498:
488:
1712:
1677:
1501:
I agree with the other editor that it was a bad example, for the reasons they gave. I suggested a couple of alternatives; you could use one of those?
522:
357:
1341:
1742:
812:
Just an idea: If I pick a symmetric cipher (twofish,aes) and create a "private" symmetric key for the cipher, would it make sense to generate the
559:
541:
423:
135:
783:
The same is (for example) not true for the RSA based signature scheme. There you do not need a random number, which makes the application easier.
1525:
Huh? Just below it says: "The signature is the **pair** ( r , s ) {\displaystyle (r,s)} (r,s)", i.e., twice the curve order size, not 4 times.
1637:
268:
188:
102:
1667:
816:
out of the HASH value, by applying the symmetric cipher to the HASH value ? This would guarantee, that different HASH values get different
464:
348:
325:
1552:
of how and why elliptic curve encryption works? Or at least refer to such an explanation with a prominent wikilink ("full article at") to
1697:
1183:
844:
1707:
740:
126:
97:
858:
It might indeed work, but wikipedia isn't the right place to discuss new constructions. Some deterministic algorithms for generating
1532:
863:
255:
216:
797:
1747:
1010:
767:
447:
414:
1722:
796:
weaknesses. E.g., NIST's digital signature standard does include pseudorandom number generators that can be used with ECDSA.
517:
419:
1143:
1058:
1076:
938:
1618:
1337:
https://stackoverflow.com/questions/19665491/how-do-i-get-an-ecdsa-public-key-from-just-a-bitcoin-signature-sec1-4-1-6-k
72:
1553:
1198:
672:
what the heck is "the" 160 bit prime field? there are many primes p between 2^159 and 2^160-1, so Z/pZ is ambiguous
1391:
754:
This is a well known property of many signature schemes based on discrete logarithms. It implies that a new random
634:
Create the
Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
38:
1342:
https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work
1331:
608:
848:
1622:
1584:
1565:
1561:
1540:
1510:
1495:
1479:
1460:
1413:
1409:
1395:
1362:
1316:
1300:
1260:
1240:
Is it possible to show an example (with smaller numbers, of course) to demonstrate what operations are done?
1229:
1210:
1191:
1187:
1164:
914:
871:
852:
805:
775:
748:
744:
713:
1536:
867:
1419:
Just checked this again. Now wikipedia is using TLS 1.3, not TLS 1.2, but still seems to be using ECDSA:
1225:
801:
460:
1580:
882:
There is a very serious error in this page (the same error appears in several languages). In the lines
771:
1206:
974:
910:
902:
78:
1221:
1614:
739:
100 bits, the probability of getting two similar k's is not that high, but still I do not like it...)
1606:
1528:
1379:
1179:
840:
766:
is 1/(n-1). An attacker could just guess the private key with the same small probability of success.
710:
1576:
60:
31:
1202:
922:
906:
898:
463:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
356:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
267:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
134:
on
Knowledge. If you would like to participate, please visit the project page, where you can join
1610:
1557:
1405:
1256:
247:
231:
210:
1601:
1556:? The article needs a diagram showing an ellipse and explaining how it is used for encryption.
1141:
first convert the binary polynomial to a bit string then convert the bit string to an integer.
1502:
1471:
1358:
1312:
1296:
1110:
603:
1160:
1083:
947:
1491:
1456:
1387:
353:
17:
676:
Nope, the algorithm is described correctly. In particular the modular reductions (mod
637:
Find editors who have shown interest in this subject and ask them to take a look here.
1631:
1506:
1475:
1252:
1598:
Please consider adding OpenZeppelin to the list of libraries that implement ECDSA.
1354:
1308:
1292:
340:
319:
131:
531:
1156:
260:
1376:
Is this fact worth putting into the main article (with a proper explanation)?
507:
439:
408:
662:
This article is not correct. Operations are made with no modulos. int() -: -->
264:
237:
1487:
1452:
1383:
1332:
https://crypto.stackexchange.com/questions/42134/ecdsa-pubkey-recovery-issue
456:
1279:
to define the security level, but I do not see how that would be possible.
1067:
929:
762:
are chosen at random then the probability of two signatures using the same
178:
731:
Now an attacker only needs to reconstruct k (or kInv) which he can do by:
452:
828:
is generated with a (secure) symmetric cipher, then I would assume that
118:
91:
593:
824:
is, that it must not be guessed and it must not be reconstructed. If
1197:
Also, I think that this article should use the same notation as the
1073:
935:
54:
26:
1602:
https://docs.openzeppelin.com/contracts/2.x/api/cryptography
592:
530:
506:
177:
1049:{\displaystyle r={\overline {x_{R}}}\operatorname {mod} n}
1368:
Example, this page (currently) authenticated using ECDSA
1005:
using the conversion routine specified in
Section 2.3.9.
832:
meets this criterion. An attacker then only knows that
680:) are neccessary for the security of the algorithm. If
585:
580:
575:
570:
1346:
1113:
1086:
1013:
977:
950:
1738:
C-Class
Computer Security articles of Mid-importance
451:, a collaborative effort to improve the coverage of
352:, a collaborative effort to improve the coverage of
259:, a collaborative effort to improve the coverage of
130:, a collaborative effort to improve the coverage of
1247:
bits, how can the public key be calculated from it?
1688:Mid-importance WikiProject Cryptocurrency articles
1133:
1099:
1048:
997:
963:
615:Review importance and quality of existing articles
1243:if the private key is just a "random number" of
618:Identify categories related to Computer Security
1446:New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
1428:$ openssl s_client -connect wikipedia.org:443
1107:no conversion is required, and if the field is
932:the signing process is described unambiguously:
758:must be chosen for every new signature. If the
1080:Informally the idea is that, if the field is
8:
1718:C-Class software articles of Low-importance
1683:C-Class WikiProject Cryptocurrency articles
697:has to be chosen significantly larger than
1526:
1377:
1323:Public key can be recovered from signature
862:have been proposed (see e.g. IEEE P1363).
624:Identify articles for creation (see also:
554:
403:
314:
205:
86:
1733:Mid-importance Computer Security articles
1653:High-importance Computer science articles
1123:
1118:
1112:
1091:
1085:
1026:
1020:
1012:
984:
978:
976:
955:
949:
606:. Please allow some days for processing.
905:) 11:46, 27 November 2020 (UTC)garweyne
405:
316:
207:
88:
58:
1658:WikiProject Computer science articles
1643:High-importance Cryptography articles
1470:P256. I'm sure otehr examples exist.
7:
445:This article is within the scope of
366:Knowledge:WikiProject Cryptocurrency
346:This article is within the scope of
253:This article is within the scope of
124:This article is within the scope of
1693:WikiProject Cryptocurrency articles
998:{\displaystyle {\overline {x_{R}}}}
930:section 4.1.3 (starting on page 50)
734:s_1 - s_2 = kInv*(e_1 - e_2) mod n
372:WikiProject Cryptocurrency articles
369:Template:WikiProject Cryptocurrency
77:It is of interest to the following
1728:C-Class Computer Security articles
1673:Low-importance numismatic articles
1440:Server Temp Key: X25519, 253 bits
1327:More information please refer to
791:No doubt there. The generation of
144:Knowledge:WikiProject Cryptography
25:
1703:Low-importance Computing articles
1663:WikiProject Cryptography articles
1648:C-Class Computer science articles
1235:Example computation, like in RSA?
631:Identify articles for improvement
277:Knowledge:WikiProject Numismatics
147:Template:WikiProject Cryptography
1713:Low-importance software articles
1678:WikiProject Numismatics articles
1349:dot org/index.php?topic=783694.0
1216:Use the hash value $ e$ or not?
438:
407:
339:
318:
280:Template:WikiProject Numismatics
240:
230:
209:
117:
90:
59:
30:
725:s_2 = kInv*(e_2 + r*d_A) mod n
493:This article has been rated as
473:Knowledge:WikiProject Computing
386:This article has been rated as
297:This article has been rated as
164:This article has been rated as
41:on 14 June 2008. The result of
37:This article was nominated for
1743:All Computer Security articles
1480:16:17, 23 September 2021 (UTC)
1461:23:48, 21 September 2021 (UTC)
1261:16:46, 14 September 2014 (UTC)
723:s_1 = kInv*(e_1 + r*d_A) mod n
476:Template:WikiProject Computing
1:
1638:C-Class Cryptography articles
1566:15:09, 2 September 2020 (UTC)
1547:Simplified explanation needed
1425:Tue Sep 21 19:33:46 EDT 2021
1414:15:11, 2 September 2020 (UTC)
1396:19:23, 24 November 2017 (UTC)
1363:03:37, 20 November 2017 (UTC)
1165:20:27, 27 November 2020 (UTC)
944:2. Convert the field element
915:11:46, 27 November 2020 (UTC)
872:10:40, 20 November 2007 (UTC)
853:10:00, 20 November 2007 (UTC)
806:14:46, 18 November 2007 (UTC)
776:14:05, 17 November 2007 (UTC)
749:03:23, 17 November 2007 (UTC)
602:will be generated shortly by
560:WikiProject Computer Security
542:WikiProject Computer Security
539:This article is supported by
515:This article is supported by
467:and see a list of open tasks.
360:and see a list of open tasks.
271:and see a list of open tasks.
186:This article is supported by
138:and see a list of open tasks.
1541:17:01, 19 January 2019 (UTC)
1434:Peer signing digest: SHA256
1032:
990:
189:WikiProject Computer science
1668:C-Class numismatic articles
1623:01:52, 30 August 2022 (UTC)
1554:Elliptic-curve cryptography
1517:Size of signature is wrong?
1437:Peer signature type: ECDSA
1301:16:51, 28 August 2017 (UTC)
1199:Digital Signature Algorithm
1764:
1698:C-Class Computing articles
1211:13:33, 24 April 2008 (UTC)
499:project's importance scale
349:WikiProject Cryptocurrency
303:project's importance scale
1708:C-Class software articles
1511:20:07, 5 April 2022 (UTC)
1496:16:16, 4 April 2022 (UTC)
1230:13:03, 17 June 2009 (UTC)
1192:00:30, 2 April 2008 (UTC)
1134:{\displaystyle F_{2^{m}}}
666:Sign: r=int(kG)+h s=k-ar
553:
538:
514:
492:
433:
385:
334:
296:
225:
185:
163:
112:
85:
1317:08:42, 9 June 2018 (UTC)
714:14:52, 6 July 2007 (UTC)
669:Verify: h==r-int(sG+rP)
658:Correctness of algorithm
127:WikiProject Cryptography
1594:OpenZeppellin and ECDSA
1585:21:23, 3 May 2022 (UTC)
728:with k*kInv = 1 mod n
688:are not reduced modulo
256:WikiProject Numismatics
18:Talk:Elliptic Curve DSA
1748:All Computing articles
1135:
1101:
1050:
999:
965:
597:
535:
511:
461:information technology
182:
67:This article is rated
1723:All Software articles
1136:
1102:
1100:{\displaystyle F_{p}}
1051:
1000:
966:
964:{\displaystyle x_{R}}
837:cipher (correct ?).
596:
534:
510:
448:WikiProject Computing
181:
150:Cryptography articles
1171:Jargon / readability
1111:
1084:
1011:
975:
948:
621:Tag related articles
558:Things you can help
518:WikiProject Software
1347:https://bitcointalk
609:More information...
283:numismatic articles
1131:
1097:
1046:
995:
961:
598:
536:
512:
479:Computing articles
248:Numismatics portal
183:
73:content assessment
1609:comment added by
1543:
1531:comment added by
1398:
1382:comment added by
1194:
1182:comment added by
1148:
1147:
1063:
1062:
1035:
993:
855:
843:comment added by
655:
654:
651:
650:
647:
646:
643:
642:
402:
401:
398:
397:
313:
312:
309:
308:
204:
203:
200:
199:
53:
52:
16:(Redirected from
1755:
1625:
1177:
1140:
1138:
1137:
1132:
1130:
1129:
1128:
1127:
1106:
1104:
1103:
1098:
1096:
1095:
1074:
1055:
1053:
1052:
1047:
1036:
1031:
1030:
1021:
1004:
1002:
1001:
996:
994:
989:
988:
979:
970:
968:
967:
962:
960:
959:
936:
926:
838:
626:Article requests
611:
555:
481:
480:
477:
474:
471:
442:
435:
434:
429:
426:
411:
404:
392:importance scale
374:
373:
370:
367:
364:
343:
336:
335:
330:
322:
315:
285:
284:
281:
278:
275:
250:
245:
244:
243:
234:
227:
226:
221:
213:
206:
170:importance scale
152:
151:
148:
145:
142:
121:
114:
113:
108:
105:
103:Computer science
94:
87:
70:
64:
63:
55:
34:
27:
21:
1763:
1762:
1758:
1757:
1756:
1754:
1753:
1752:
1628:
1627:
1604:
1596:
1549:
1523:
1519:
1370:
1325:
1268:
1237:
1218:
1173:
1119:
1114:
1109:
1108:
1087:
1082:
1081:
1022:
1009:
1008:
980:
973:
972:
951:
946:
945:
920:
660:
612:
607:
590:
478:
475:
472:
469:
468:
427:
417:
371:
368:
365:
362:
361:
328:
282:
279:
276:
273:
272:
246:
241:
239:
219:
194:High-importance
166:High-importance
149:
146:
143:
140:
139:
107:High‑importance
106:
100:
71:on Knowledge's
68:
23:
22:
15:
12:
11:
5:
1761:
1759:
1751:
1750:
1745:
1740:
1735:
1730:
1725:
1720:
1715:
1710:
1705:
1700:
1695:
1690:
1685:
1680:
1675:
1670:
1665:
1660:
1655:
1650:
1645:
1640:
1630:
1629:
1595:
1592:
1590:
1588:
1587:
1573:
1548:
1545:
1520:
1518:
1515:
1514:
1513:
1483:
1482:
1465:
1417:
1416:
1369:
1366:
1351:
1350:
1344:
1339:
1334:
1324:
1321:
1320:
1319:
1267:
1266:Security level
1264:
1249:
1248:
1241:
1236:
1233:
1217:
1214:
1172:
1169:
1168:
1167:
1152:
1146:
1145:
1142:
1126:
1122:
1117:
1094:
1090:
1078:
1072:
1071:
1066:In turn, that
1061:
1060:
1057:
1045:
1042:
1039:
1034:
1029:
1025:
1019:
1016:
1006:
992:
987:
983:
971:to an integer
958:
954:
943:
940:
934:
933:
881:
879:
878:
877:
876:
875:
874:
810:
809:
808:
786:
784:
782:
724:
717:
716:
659:
656:
653:
652:
649:
648:
645:
644:
641:
640:
639:
638:
635:
632:
629:
622:
619:
616:
600:Article alerts
591:
589:
588:
583:
578:
573:
567:
564:
563:
551:
550:
547:Mid-importance
537:
527:
526:
523:Low-importance
513:
503:
502:
495:Low-importance
491:
485:
484:
482:
465:the discussion
443:
431:
430:
428:Low‑importance
412:
400:
399:
396:
395:
388:Mid-importance
384:
378:
377:
375:
363:Cryptocurrency
358:the discussion
354:cryptocurrency
344:
332:
331:
329:Mid‑importance
326:Cryptocurrency
323:
311:
310:
307:
306:
299:Low-importance
295:
289:
288:
286:
269:the discussion
252:
251:
235:
223:
222:
220:Low‑importance
214:
202:
201:
198:
197:
184:
174:
173:
162:
156:
155:
153:
136:the discussion
122:
110:
109:
95:
83:
82:
76:
65:
51:
50:
43:the discussion
35:
24:
14:
13:
10:
9:
6:
4:
3:
2:
1760:
1749:
1746:
1744:
1741:
1739:
1736:
1734:
1731:
1729:
1726:
1724:
1721:
1719:
1716:
1714:
1711:
1709:
1706:
1704:
1701:
1699:
1696:
1694:
1691:
1689:
1686:
1684:
1681:
1679:
1676:
1674:
1671:
1669:
1666:
1664:
1661:
1659:
1656:
1654:
1651:
1649:
1646:
1644:
1641:
1639:
1636:
1635:
1633:
1626:
1624:
1620:
1616:
1612:
1608:
1603:
1599:
1593:
1591:
1586:
1582:
1578:
1574:
1570:
1569:
1568:
1567:
1563:
1559:
1558:David Spector
1555:
1546:
1544:
1542:
1538:
1534:
1530:
1516:
1512:
1508:
1504:
1500:
1499:
1498:
1497:
1493:
1489:
1481:
1477:
1473:
1468:
1467:
1466:
1463:
1462:
1458:
1454:
1450:
1447:
1444:
1441:
1438:
1435:
1432:
1429:
1426:
1423:
1420:
1415:
1411:
1407:
1406:David Spector
1404:
1401:
1400:
1399:
1397:
1393:
1389:
1385:
1381:
1374:
1367:
1365:
1364:
1360:
1356:
1348:
1345:
1343:
1340:
1338:
1335:
1333:
1330:
1329:
1328:
1322:
1318:
1314:
1310:
1305:
1304:
1303:
1302:
1298:
1294:
1288:
1285:
1280:
1278:
1274:
1265:
1263:
1262:
1258:
1254:
1246:
1242:
1239:
1238:
1234:
1232:
1231:
1227:
1223:
1215:
1213:
1212:
1208:
1204:
1200:
1195:
1193:
1189:
1185:
1184:70.172.221.26
1181:
1170:
1166:
1162:
1158:
1153:
1150:
1149:
1124:
1120:
1115:
1092:
1088:
1079:
1075:
1069:
1068:section 2.3.9
1065:
1064:
1043:
1040:
1037:
1027:
1023:
1017:
1014:
985:
981:
956:
952:
941:
937:
931:
924:
919:
918:
917:
916:
912:
908:
904:
900:
895:
891:
887:
883:
873:
869:
865:
861:
857:
856:
854:
850:
846:
845:213.70.137.67
842:
835:
831:
827:
823:
819:
815:
811:
807:
803:
799:
794:
790:
789:
779:
778:
777:
773:
769:
765:
761:
757:
753:
752:
751:
750:
746:
742:
735:
732:
729:
726:
721:
715:
712:
708:
704:
700:
696:
691:
687:
683:
679:
675:
674:
673:
670:
667:
664:
657:
636:
633:
630:
627:
623:
620:
617:
614:
613:
610:
605:
601:
595:
587:
584:
582:
579:
577:
574:
572:
569:
568:
566:
565:
561:
557:
556:
552:
548:
545:(assessed as
544:
543:
533:
529:
528:
524:
521:(assessed as
520:
519:
509:
505:
504:
500:
496:
490:
487:
486:
483:
466:
462:
458:
454:
450:
449:
444:
441:
437:
436:
432:
425:
421:
416:
413:
410:
406:
393:
389:
383:
380:
379:
376:
359:
355:
351:
350:
345:
342:
338:
337:
333:
327:
324:
321:
317:
304:
300:
294:
291:
290:
287:
270:
266:
262:
258:
257:
249:
238:
236:
233:
229:
228:
224:
218:
215:
212:
208:
195:
192:(assessed as
191:
190:
180:
176:
175:
171:
167:
161:
158:
157:
154:
137:
133:
129:
128:
123:
120:
116:
115:
111:
104:
99:
96:
93:
89:
84:
80:
74:
66:
62:
57:
56:
48:
44:
40:
36:
33:
29:
28:
19:
1605:— Preceding
1600:
1597:
1589:
1550:
1527:— Preceding
1524:
1484:
1464:
1451:
1448:
1445:
1442:
1439:
1436:
1433:
1430:
1427:
1424:
1421:
1418:
1402:
1378:— Preceding
1375:
1371:
1352:
1326:
1289:
1283:
1281:
1276:
1272:
1269:
1250:
1244:
1222:Annie Yousar
1219:
1196:
1174:
896:
892:
888:
884:
880:
859:
833:
829:
825:
821:
817:
813:
792:
763:
759:
755:
741:84.154.9.170
736:
733:
730:
727:
722:
718:
706:
702:
698:
694:
689:
685:
681:
677:
671:
668:
665:
661:
599:
540:
516:
494:
446:
387:
347:
298:
254:
187:
165:
141:Cryptography
132:Cryptography
125:
98:Cryptography
79:WikiProjects
46:
1533:45.2.119.34
1275:instead of
1178:—Preceding
864:85.2.41.154
839:—Preceding
274:Numismatics
261:numismatics
217:Numismatics
47:speedy keep
1632:Categories
798:85.2.68.87
781:trouble...
711:85.2.26.40
701:, so that
265:currencies
1577:Jannaston
1282:However,
768:85.2.63.5
604:AAlertBot
470:Computing
457:computing
453:computers
415:Computing
1619:contribs
1607:unsigned
1529:unsigned
1422:$ date
1392:contribs
1380:unsigned
1253:RokerHRO
1203:Cherullo
1180:unsigned
923:Garweyne
907:Garweyne
899:Garweyne
841:unsigned
424:Security
420:Software
39:deletion
1355:Jackzhp
1309:Maghnus
1293:Pashley
1284:average
1277:maximum
1273:minimum
1007:3. Set
576:history
497:on the
390:on the
301:on the
168:on the
69:C-class
1611:Smdear
1403:Agree.
1157:Nanite
1056:. ...
707:s=k-ar
459:, and
75:scale.
1353:Jack
1070:says:
586:purge
581:watch
562:with:
1615:talk
1581:talk
1572:one.
1562:talk
1537:talk
1507:talk
1492:talk
1488:DRLB
1476:talk
1457:talk
1453:DRLB
1443:...
1431:...
1410:talk
1388:talk
1384:DRLB
1359:talk
1313:talk
1297:talk
1257:talk
1226:talk
1207:talk
1188:talk
1161:talk
911:talk
903:talk
868:talk
849:talk
802:talk
772:talk
745:talk
705:and
684:and
571:edit
263:and
160:High
45:was
1503:Ewx
1472:Ewx
1038:mod
942:...
738:-->
489:Low
382:Mid
293:Low
1634::
1621:)
1617:•
1583:)
1564:)
1539:)
1509:)
1494:)
1478:)
1459:)
1412:)
1394:)
1390:•
1361:)
1315:)
1299:)
1259:)
1251:--
1228:)
1209:)
1190:)
1163:)
1155:--
1144:”
1077:“
1059:”
1041:
1033:¯
991:¯
939:“
913:)
870:)
851:)
804:)
774:)
747:)
699:ar
549:).
525:).
455:,
422:/
418::
196:).
101::
1613:(
1579:(
1560:(
1535:(
1505:(
1490:(
1474:(
1455:(
1408:(
1386:(
1357:(
1311:(
1295:(
1255:(
1245:n
1224:(
1205:(
1186:(
1159:(
1125:m
1121:2
1116:F
1093:p
1089:F
1044:n
1028:R
1024:x
1018:=
1015:r
986:R
982:x
957:R
953:x
925::
921:@
909:(
901:(
866:(
860:k
847:(
834:k
830:k
826:k
822:k
818:k
814:k
800:(
793:k
770:(
764:k
760:k
756:k
743:(
703:r
695:k
690:n
686:s
682:r
678:n
628:)
501:.
394:.
305:.
172:.
81::
49:.
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
