ECC Curves: secp256k1 versus secp521r1

[chan] bitmessage
Jul 8 15:41

I have questions for any crypto guru who may lurk here. I altered my code to use a different curve prime field for address key generation. Using the new SSL configuration this is the key output for [chan] general: [BM-2cTP8f6C9YsVwdRcyZq5atuyGLTtsaoxGW] label = [chan] general enabled = true decoy = false chan = true It seems to work, and strangely it seems compatible with the addresses using the secp256k1 curves. Using secp521r1 added only about 1/100 second time to address generation. (Wait, it appears that bitmessage protocol will not process a message object from this address). I was able to send to myself, but apparently the message can't go out on the network via unmodified nodes. My question is, does using the secp521r1 curve provide better computational security for the sender? If it does what if the recipient's keys are not based on the larger field keys? Or, what is the most secure curve available in openssl, as listed in the command: $ openssl ecparam -list_curves? Is there a way to get larger and more secure key fields into openssl? I would love to use ECC above 2048 bit range if I could have them. If it takes ten minutes to generate an address, then so be it. Really I'd like to up to 8192 bit ECC since that should be future secure for 30+ years even if RSA/DSA get broken. I'd be willing to wait an entire hour for address generation if that's what it cost to use humongous ECC fields. Someone might want to say: "you don't need keys that big" or "think of the small devices that would choke on them." Don't bother. It's bull. I don't buy that argument of "keep yourself insecure for speed's sake," as if I should have manners about my data security. I want my communication security to make an attacker's job unbearable in every way possible. ~ cl!Q

BM-87bghfw3YzEDyNYMX21FANfo9nkswwUgS4H
Jul 8 15:41

I have questions for any crypto guru who may lurk here. I altered my code to use a different curve prime field for address key generation. Using the new SSL configuration this is the key output for [chan] general: [BM-2cTP8f6C9YsVwdRcyZq5atuyGLTtsaoxGW] label = [chan] general enabled = true decoy = false chan = true It seems to work, and strangely it seems compatible with the addresses using the secp256k1 curves. Using secp521r1 added only about 1/100 second time to address generation. My question is, does using the secp521r1 curve provide better computational security for the sender? If it does what if the recipient's keys are not based on the larger field keys? Or, what is the most secure curve available in openssl, as listed in the command: $ openssl ecparam -list_curves? Is there a way to get larger and more secure key fields into openssl? I would love to use ECC above 2048 bit range if I could have them. If it takes ten minutes to generate an address, then so be it. Really I'd like to up to 8192 bit ECC since that should be future secure for 30+ years even if RSA/DSA get broken. I'd be willing to wait an entire hour for address generation if that's what it cost to use humongous ECC fields. Someone might want to say: "you don't need keys that big" or "think of the small devices that would choke on them." Don't bother. It's bull. I don't buy that argument of "keep yourself insecure for speed's sake," as if I should have manners about my data security. I want my communication security to make an attacker's job unbearable in every way possible. ~ cl!Q

BM-NBNf1bT2S7NdVPuGtXe1zKt4bhxUppWA
Jul 8 15:57

Well, key generation wouldn't take ages when using larger elliptic curves. The time-taking operation with elliptic curves is checking if a curve fullfills a few basic safety checks. Once this is done, key generation and everything else is rather quick, unlike with RSA. However, actually DOING this verification of a curve takes hours to days (to my knowledge) even for 1024 bit curves. And the time increases rather harshly with the size of the curve parameters. I.e. it's unlikely for any verified curves with much more than 1024 bits to show up anytime soon. I agree with you that more is more in terms of crypto, but I kinda doubt this kind of thing will really show up soon, unless we find better algorithms. If anyone has examples for larger, already checked curves, and has a source to post, I'd love to see that.

BM-87ZQse4Ta4MLM9EKmfVUFA4jJUms1Fwnxws
Jul 8 19:23

> What if the recipient's keys are not based on the larger field keys? Only the recipients encryption key is used to encrypt a message. So what encryption key the sender is using doesn't affect security. But because the senders public encryption and signing keys are included in the message, an unmodified client will not understand the message if the sender uses a longer key. > My question is, does using the secp521r1 curve provide better computational security for the sender? There is some concern that secp521r1 might have been backdoored, so I would not recommend it. And no matter how large of a key you use, it is still susceptible to attack by a quantum computer. So a better solution is to add a new post quantum algorithm and use it in combination with secp256k1.

[chan] bitmessage
Jul 8 19:26

> So a better solution is to add a new post quantum algorithm gibz me samplz

BM-87ZQse4Ta4MLM9EKmfVUFA4jJUms1Fwnxws
Jul 8 19:44

NewHope is the most promising one at the moment. https://github.com/tpoeppelmann/newhope If implemented correctly, you would need to break both NewHope and ECDH/secp256k1 in order to decrypt a message. So even if NewHope is totally broken we would still have the same security as before.

[chan] bitmessage
Jul 8 20:03

I like to think of it that way; layers, with different crypto on each layer. One thing I don't see done, that could be, is key fragmentation. This defeats several cryptanalysis tactics. If the keys are fragmented then mixed, not according to a pattern, but according to hidden secrets with no pattern, then just the fragmentation of the keys becomes a huge computational problem for the attacker. If each bitmessage private address key went out in fragments through several different bands, an only a person with the address could locate them, this would be really secure. If the encrypted objects went the same way the ability to break secp curves would not necessarily enable you to decrypt the objects. Thanks for the info on newhope. I'll have a look.

[chan] bitmessage
Jul 8 20:18

I'm reading the white paper and they go right into lattices. This is correct. Well- implemented lattices are a doozie. There is a way to overlay lattices with the old knapsack trick that completely removes the knapsack vulnerability and actually turns it into extra computational security. To beef it up even more, we could combine banach space compression with a relative prime dictionary into the algorithm, keyed to the knapsack, in a way that an attacker would not know if he guessed the correct key. What this does is completely eliminates the use of large primes and instead allows huge fields of composite numbers to be used as if they were primes, using modulo arithmetic. Imagine guessing the correct keys, applying them to the message, and having no way to tell from the result that you have the correct keys, unless you also have the correct secondary keys which are obfuscated via a multi-pass protocol of randomized key fragments. Add to that a 4-pass key exchange / wrapper protocol based on composite cubes, and I don't think quantum ideas could ever touch it. The attackers would have to pray for divine guidance at that point.

[chan] bitmessage
Jul 8 23:21

Let me make sure I understand. If I use a different ECC curve for address generation, I surmise then the pubkeys and sent message still propogate on the network as a valid object? And if that is true, I would be very, very, very happy. I would be happy because I have some utils for creating and testing curves. I have not studied these yet, but here they are. If I were able to create and test some of my own curves, and they show to be solid, then I could share these curves with my correspondents and it would be one extra difficulty for an eavesdropper to figure out. It would be a fun way to learn more.

[chan] bitmessage
Jul 9 08:49

Mind sharing those tools?

[chan] bitmessage
Jul 9 11:25

I recall someone in the past experimenting with different crypto suites and ran into an issue where pubkeys are size-constrained in PyBitmessage - that is pubkey objects that are too small or too large are not propagated. This applies even if you define a new pubkey version. You'll have to create a new object type. I'm sure there was an issue opened in github about it but I can't find it. In the meantime see https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/shared.py#L461

[chan] bitmessage
Jul 9 11:30

This issue also exists in new async code as well: https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/network/bmobject.py#L91

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 9 11:44

The code you refer to is obsolete, the check is now here: https://github.com/Bitmessage/PyBitmessage/blob/v0.6/src/network/bmobject.py#L91 However, yes, I recommend to create a new object type if you're making incompatible changes. I discourage creating objects that have have conditional fields. Peter Surda Bitmessage core developer

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jul 9 11:51

Actually, the object-type specific checks now only apply when trying to decode their contents. They are still forwarded independently as long as the other checks (max object-independent size, expiration, PoW, stream, non-duplicate) pass. However, I still recommend new object types for incompatible changes / conditional fields, in order to allow for simpler parsers. Peter Surda Bitmessage core developer

[chan] bitmessage
Jul 11 05:02

seccure sks-ecc ecdsautils (freifunk) eclib-tools nacl-tools pyecm python-axolotl-curve25519 python-nacl mcrypt sagemath-database-elliptic-curves gmp-ecm gdl-mpfit libuecc0 pari-elldata sympow

[chan] bitmessage
Jul 11 05:23

> Mind sharing those tools? seccure sks-ecc ecdsautils (freifunk) eclib-tools nacl-tools pyecm python-axolotl-curve25519 python-nacl mcrypt sagemath-database-elliptic-curves gmp-ecm gdl-mpfit libuecc0 pari-elldata sympow

[chan] bitmessage
Jul 11 05:25

sjcl is a node lib that lets you do cool stuff with ecc crypto: https://github.com/bitwiseshiftleft/sjcl.git

[chan] bitmessage
Jul 11 05:38

"7.2 Can I at least define my own curve then? Please don't. As with the answer to the previous question, people who define curves and choose generator points really know what they're doing. They have years of experience (and probably one or two Ph.D.s in mathematics more than you)." You read this tripe everywhere... "don't attempt crypto at home. we're the experts." Yet there is hardly a mathematician alive who has the skill and knowledge to IMPLEMENT crypto in a software system. Terry Ritter said it best when he said the software developer who implements crypto is smarter than the mathematician. The big proof that these mathematicians are fools is this: they stake your data security on unproven assumptions about computational security of prime numbers. It has never been proven secure. Not. Ever. And they tell you to stake your privacy and freedom on an unproven assumption, then, have the arrogance to say you are not smart enough to design your own crypto. These guys actually believe that their degree gives them "authority." This is a pagan Roman concept, that because the sun god's Caesar gives you a degree, people must listen to you, well, because the sun god and Caesar say so. It is a baseless appeal to imaginary authority. The average person who can code, who has a zeal for the subject, can create and implement secure cryptography, if he or she is ZEALOUS about detail and doing it right. If you're not ZEALOUS, then by all means DON'T. But if you are passionate about it, and willing to put in the long hours of testing, attacking, and refactoring things, you could be the next person who creates the new crypto. Don't ask other people's opinions about your work. It is almost a guarantee they will try to shoot you down. Perfect your work and release it with a whitepaper, and let the lazy bitmouths get off their asses and do som work to attack the crypto...instead of your "misguided" motivation. To hell with naysayers who claim to know everything. Most crypto made by these experts has been broken repeatedly, and had to be redesigned repeatedly to fix the broken schemes. Their authority keeps crypto breakable. A man told me I could never be President of the United States. So I thought that in about 30 years, rather than run for President, I should just raise a revolutionary army and conquer the entire continent and make the President one of my employees. If I can't be president, that means being president is not good enough for me. Have that kind of zeal. See you in 30 years when I become your over-Presidential warlord. Who knows? Your "inadvisable" crypto might secure successful battle plans for my warlord army.

[chan] bitmessage
Jul 11 07:28

True security is a paradox - if you can truly secure something it becomes useless.

[chan] bitmessage
Jul 11 08:03

Instead of my own curve then? A guarantee they have the new crypto. This. Can I could never the software system. Can claim to attack the long hours of the broken repeatedly, to design your own curve then, have years of experience and Caesar say you, are fools is a man pagan Roman concept, that in mathematics more than the mathematician; alive who has the new crypto at least define my employees. We're the new crypto at least thought that their degree, people who implements crypto at least define my employees. It with a guarantee they stake your privacy and knowledge to hell with a mathematician alive who can I at least define my employees: average sun god's Caesar freedom on unproven assumptions about years, of the experts has the experts. Their degree people who can I at least define my own curve then have the new crypto. Can I at least define my employees: over Presidential warlord. To hell with a baseless appeal to the crypto. Don't attempt crypto breakable. We're the next person who can I could never been proven secure cryptography, if you to hell with a software arrogance to attack the long hours of the broken repeatedly to put in the experts. Yet there is this tripe everywhere: means Don't attempt crypto: is not smart enough to You, to attack the big proof that in the previous question, people who claim to you could never the subject, can I at least define my own curve then have the sun god's Caesar say you (could never been proven secure cryptography if he or two in years of my employees: who implements crypto at least define my own curve then have the software system: will try to shoot know what they're doing). The software sun god's Caesar say you, in a mathematician. As with the experts. Their authority: keeps crypto. To attack the answer to design your own curve then, have the next person who has the skill and they have the skill and willing doing it (best when I at least define my own curve then have years of zeal). Please don't. Ever: unproven assumptions about years, when of experience and conquer the sun god's Caesar say you, imaginary authority: keeps crypto at least define my employees. Their degree people who creates the long hours of your years, of zeal: for the arrogance to the skill and release it with the big sun god's Caesar say you, are fools is hardly a mathematician alive who implements crypto.

[chan] bitmessage
Jul 11 08:16

This promises to be an interesting thread. Many Thanks to the OP for the comprehensive list from their own research Lets bring some peer review audit into this please. And take it to another level to guide choices 1) How often are they updated - whats the changelog history for each one? 2) More important - if they use libraries in a core function that affects cryptographic quality - what is it? Is THAT also updated. WHERE is it? 2.1 Static (embodied with the code as a standalone solution) 2.2 Dynamically linked - thus having a security dependancy upon the host OS 3) Dependant upon some other "middle" application - such as python There may be OS packaged version defaults, usually with dynamic OS library deps. 3.1 modules / libraries / builtin codebase dependancies isolated from OS updates 3.2 system / OS binary library dependancies Add more numbers if I've missed an important code security class here. Best displayed as a tree or graph, perhaps. Lends itself to automation. ( For the bright eyed ans bushy-tailed recent CS grad or other expert ) posted with 28day TTL

[chan] bitmessage
Jul 11 19:10

> True security is a paradox - if you can truly secure something it becomes useless. How? If you mean like 'impossible to physically interact with', then yeah--but unless you're trying to secure toxic waste or something, why would you want that? I like how this: > people who define curves and choose generator points really know what they're doing. They have years of experience (and probably one or two Ph.D.s in mathematics more than you. leads to this: > "don't attempt crypto at home. we're the experts." and this: > because the sun god and Caesar say so. It is a baseless appeal to imaginary authority. and this: > See you in 30 years when I become your over-Presidential warlord. Who knows? Your "inadvisable" crypto might secure successful battle plans for my warlord army. It's like a real-life cartoon or something. But enough probably-not-subtle mockery. To summarize: 1: *Good* crypto is very hard to do. You seem to know this when you say "Most crypto made by these experts has been broken repeatedly", but you're attempting to frame it like they know nothing. What they made *was* secure until weaknesses were found--which is a good way to learn what not to do and how to improve. You can't learn without failing a bit in the process. If no cryptographic algorithim was *ever* broken, wouldn't that be *really* suspicious? 2: Nobody is telling you "don't roll your own crypto"--if you read between the lines, they are saying "you can, but don't expect it to be sound". All these people have toiled devising this shit so you don't have to--if you go on and on about your wheel-reinventing quest, a bit of eyerolling should be expected. That said, the patient ones *will* work with you and calmly discuss the security of your work--but the multitudes of wheel-reinventers drain that patience faster in some people than others. If you're doing it just to learn, nobody will give you shit for that. If you're insisting that you can do better than stuff that's been trusted and in production use for some time, expect *some* shit for that. Also keep in mind that that's far more likely if you're trying to create your own primitives.

[chan] bitmessage
Jul 11 21:54

> *Good* crypto is very hard to do. You seem to know this when you say "Most crypto made by these experts has been broken repeatedly", but you're attempting to frame it like they know nothing. You are putting words on my finger tips. I said the coders are smarter than the mathematicians, which is true. Mathematicians live in a bubble. Coders make things that must work with which real people interact. > If you're doing it just to learn, nobody will give you shit for that. If you're insisting that you can do better than stuff that's been trusted and in production use for some time, expect *some* shit for that. Also keep in mind that that's far more likely if you're trying to create your own primitives. This is the same brainwashy spiel the mathematicians spout. You glossed over the fact that, mathematical cryptography has NEVER, EVER, EVER BEEN PROVEN SECURE. It is based on unproven assumptions about security. Certain symmetric key cryptos are secure and provable. But mathematical cryptography is not provably secure. And the "experts" are telling you to trust your life to an unproven assumption. "Just trust us."

[chan] bitmessage
Jul 12 04:12

Right, it's never been proven "secure", but all crypto we use has some kind security reduction to a problem which, by all means and knowledge, we cannot feasibly break currently. Even though it's not the "perfectly uber nice secure" cipher that you want to have, it's still worlds better than some random guy going "I made a thing, it secure yo!"

[chan] bitmessage
Jul 12 04:27

You glossed over the fact that cryptography CAN NEVER, EVER, EVER BE PROVEN SECURE.

[chan] bitmessage
Jul 12 05:22

Bull. Certain symmetric key schemes have been proven secure. It's the mathematical crypto that's not proven.

[chan] bitmessage
Jul 16 20:43

Hey, me again. Hoboy, another round of this. First off, dude below me has got the right idea. In short, we don't have any cipher that is provably perfectly secure (save for OTPs)--Instead we use feasibility as a measure. If you need to burn up a sun to provide the computational power to break it, you are pretty damn well off. Aaaanyway... > You are putting words on my finger tips. I swear, "you put words in my mouth bruh" is becoming a meme here. We can *all* see what you've written previously. If I've misinterpreted what you've said, It's *your* job to clarify, not complain more. Don't be going 'what I *actually* meant was...' every time a point of yours falls through. Being as clear as possible the first time is far better. > I said the coders are smarter than the mathematicians, which is true. Mathematicians live in a bubble. Coders make things that must work with which real people interact. *Cryptography is based on math.* This shouldn't be so hard to understand. https://www.cs.drexel.edu/~introcs/Fa08/notes/10.1_Cryptography/algorithm2.html?CurrentSlide=11 https://www.cs.drexel.edu/~introcs/Fa08/notes/10.1_Cryptography/RSAWorksheetv4b.html And here's an explanation explicitly demonstrating how math plays a role in RSA--it even includes examples for your reading pleasure (page 6): http://www.claysturner.com/dsp/totient.pdf The most important passage is as follows: > "The RSA method exploits the fact that factoring a large number into smaller components is more difficult than forming a large number by multiplying together smaller numbers. If the large number is a product of two near equal length primes, then this computational disparity can be quite extreme. This is an example of a one way trap door function. To ensure the one wayness of this function, RSA type cryptosystems use numbers with thousands of digits." Mathematicians deal with the underlying algorithmic work of ciphers, while programmers put said work to use. The implementation cannot exist without the abstract concept it's based upon. The people who do the math either produce useful results that can be implemented in real life, or they don't (publish or perish), and The most useful results eventually earn the right to be called secure* (secure _enough_, that asterisk is always there) when they become battle-tested enough in the real world--not becasue of whatever some paticular person said. There is no point in which the personality or attitutes of the people who develop said algorithims factor into this process. > mathematical cryptography has NEVER, EVER, EVER BEEN PROVEN SECURE. It is based on unproven assumptions about security. See second paragraph again ("First off [...]"), and the linked pages demonstrating exactly what 'good enough' entails. > Certain symmetric key cryptos are secure and provable. But mathematical cryptography is not provably secure. This needs a source besides 'because I said it'. Provable how? And how is it 'provable', but not 'mathematically provable?' and what is the difference? > And the "experts" are telling you to trust your life to an unproven assumption. "Just trust us." Are you in life-or-death situations that often? If so, I'd think that you'd be somewhat better versed in the thing you trust your life on than this. The amount of rage you're spoting off here doesn't sell that idea too well. From earlier: > 2: Nobody is telling you "don't roll your own crypto"--if you read between the lines, they are saying "you can, but don't expect it to be sound". All these people have toiled devising this shit so you don't have to--if you go on and on about your wheel-reinventing quest, a bit of eyerolling should be expected. You seem to have ignored this point of mine (and several other things) so you could continue to rant about how mathematicians are stupid or whatever--It's making you look like you have no actual proof backing that up--if you do, please feel free to share. I always appreciate a chance to hone my mad critical reading skillz™. PS: here have a knowledge or two: https://www.crypto101.io As a side note, math and code coexist in this doc-- hope you don't get too upset over that.

BM-NBNf1bT2S7NdVPuGtXe1zKt4bhxUppWA
Jul 16 20:44

Another informative and well written post by <anonymous bitmessage poster>

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
why are all the channels blank Nov 19 20:51 7
BitMessage crash Nov 19 12:50 7
Alternative Bitmessage port for official assignment with IANA? Nov 19 08:28 5
Tor replacement Nov 18 23:04 5
codewordtest2 Nov 17 21:52 1
bitmessage history Nov 15 08:43 28
stream and pool diagram Nov 12 12:05 21
( ͠° ͟ ʖ ͡°) Nov 10 09:51 2
I'm back. Nov 9 17:55 1
streams and pools Nov 7 01:37 1
How to examine bitmessage objects Nov 7 00:45 5
Tor curve vs bm curve Nov 7 00:45 4
keys.dat values Nov 6 23:16 2
Bitmessage history Nov 6 08:08 9
Pseudo-mailinglist vs chans? Nov 5 21:47 2
bitmessage node rating? Nov 5 21:32 2
can I connect to both onions and standard? Nov 5 19:33 11
Bitmessage won't exit cleanly Nov 4 18:06 2
keys.dat must be encrypted Nov 4 12:09 12
Question Nov 3 20:09 5
It's actually not that hard to de-anonymize someone on bitmessage. Nov 3 19:49 8
It's actually not that hard to de-anonymize someone on Nov 2 14:18 1
Bitmessage snapshots Nov 2 13:14 3
Why chan address? Nov 1 06:26 2
HASH Q Oct 31 21:16 1
bitpetite scam Oct 31 08:34 2
GitHub Supports Islamic Clitoris Removal Oct 31 01:02 14
What exactly is the address of [chan] general? Oct 30 05:29 7
MiNode addr bug Oct 27 11:53 1
Hi, users ! Oct 27 07:18 5
No incoming connections now Oct 26 09:40 31
RE: bitmessage implementation in any other programming language Oct 23 17:01 1
disabled address still working Oct 23 12:47 8