Title: jeeq: ECDSA encryption Post by: jackjack on May 06, 2013, 12:43:45 AM Hey all
I read everywhere that ECDSA can't be used to encrypt The fact is it can, I made a basic implementation: https://github.com/jackjack-jj/jeeq It uses a kind of secret sharing and it looks like that works well It's in python and requires no dependencies Code: > pubkey='0479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8'.decode('hex') Code: > pvk = str_to_long('0000000000000000000000000000000000000000000000000000000000000001'.decode('hex')) My concern is about the security, can a crypto-pro give it a quick look? I'm sure it's as sure as signing because breaking it would need the same discrete logarithm than in Bitcoin but well, you never know... Edit: I'd be happy to receive some crypted messages, you can find my public key on blockchain.info (http://blockexplorer.com/address/19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3) Title: Re: jeeq: ECDSA encryption Post by: etotheipi on May 06, 2013, 02:06:46 AM Did you look at ECIES (http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme)?
Title: Re: jeeq: ECDSA encryption Post by: Zeilap on May 06, 2013, 02:08:41 AM You've come up with ElGamal encryption (https://en.wikipedia.org/wiki/ElGamal_encryption) independently. Pretty impressive :).
Title: Re: jeeq: ECDSA encryption Post by: jackjack on May 06, 2013, 06:54:23 AM Did you look at ECIES (http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme)? No, but as I understand the wikipedia article, it seems a bit more complicated (or maybe it's just because I'm not comfortable with KDFs and HMACs)Can it be used with ECDSA private keys? You've come up with ElGamal encryption (https://en.wikipedia.org/wiki/ElGamal_encryption) independently. Pretty impressive :). Yeah that's true it's really similar! Not being a crypto guy (even though I'm rather good at maths) I can't imagine I'm the only one who tried that kind of things, so why is it not used?Also, as I understand the article my implementation seems secure Title: Re: jeeq: ECDSA encryption Post by: Shevek on May 06, 2013, 09:04:32 AM Did you look at ECIES (http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme)? No, but as I understand the wikipedia article, it seems a bit more complicated (or maybe it's just because I'm not comfortable with KDFs and HMACs)Can it be used with ECDSA private keys? AFIK, HMAC is needed only when you use a non self-authenticate symmetric encryption. For example, CTR mode must be used with external authentication (HMAC). But, in principle, CBC does not need HMAC (and so don't KDF, because the shared secret can be used as the single key). Title: Re: jeeq: ECDSA encryption Post by: archaeopteryx on May 06, 2013, 09:13:41 AM Did you look at ECIES (http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme)? No, but as I understand the wikipedia article, it seems a bit more complicated (or maybe it's just because I'm not comfortable with KDFs and HMACs)Can it be used with ECDSA private keys? You've come up with ElGamal encryption (https://en.wikipedia.org/wiki/ElGamal_encryption) independently. Pretty impressive :). Yeah that's true it's really similar! Not being a crypto guy (even though I'm rather good at maths) I can't imagine I'm the only one who tried that kind of things, so why is it not used?Also, as I understand the article my implementation seems secure I'm not a crypto expert, but if your implementation is truly the same as ElGamal, well it is being used. For example, Pretty Good Privacy implementations use ElGamal as one of the options. Title: Re: jeeq: ECDSA encryption Post by: jackjack on May 06, 2013, 10:01:57 AM AFIK, HMAC is needed only when you use a non self-authenticate symmetric encryption. For example, CTR mode must be used with external authentication (HMAC). But, in principle, CBC does not need HMAC (and so don't KDF, because the shared secret can be used as the single key). Hmm ok I think I get it, I'll look into an ECIES implementation to see how they handle thatI'm not a crypto expert, but if your implementation is truly the same as ElGamal, well it is being used. For example, Pretty Good Privacy implementations use ElGamal as one of the options. I meant ElGamal with ECDSA. ElGamal is only with DSA, doesn't it?Title: Re: jeeq: ECDSA encryption Post by: jackjack on May 14, 2013, 09:59:38 PM I just pushed a new version
You no more need to mess with the code, -i, -k and -o options handle files and data Example: Code: #ENCRYPTION (-e) The options are of course mixable Title: Re: jeeq: ECDSA encryption Post by: Qwedcxza1 on June 20, 2013, 11:08:26 AM I'm not a programmer so it's difficult to understand this without seeing a proper mathematical description of the encryption and decryption methods.
If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system. There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve. The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used. Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there. Title: Re: jeeq: ECDSA encryption Post by: jackjack on June 20, 2013, 11:20:50 AM I'm not a programmer so it's difficult to understand this without seeing a proper mathematical description of the encryption and decryption methods. If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system. There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve. The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used. Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there. Let's say I want to encrypt 'hello' to your address Quote pubkey: your public key privkey: your private key I split my message in 32-char long chunks and put "0x00"s at the end of the last one to make it 32-char long too. That gives here only one chunk: 'hello---------------------------'. ('-' represents one 0x00) Now each chunk is used as an X. Let's call the correponding point M (Two M's are possible but it doesn't matter as I never use Y) Then I take a random N and calculate:
Those points are the encrypted data to be sent to the recipient. As pubkey=privkey*G, M is easily calculated. Note: Not all X values leads to a point on the EC. In such cases I just use offsets. Title: Re: jeeq: ECDSA encryption Post by: oleganza on June 20, 2013, 11:37:47 AM How about using ECC point multiplication and AES:
1. Get recipient's public key R (R = r*G, r is private key) 2. For each message, generate unique keypair S,s: S = s*G. 3. Create a shared secret: K = R*s 4. Compute 256-bit encryption key out of that shared secret: key = SHA256(SHA256(K)) 5. Encrypt the message with that key and send the message together with unique pubkey S. 6. Recipient gets the message and computes key using his private key r and S: key = SHA256(SHA256(r*S)) 7. Recipient's key turns out to be the same because r*S = R*s = r*s*G. I like this scheme more because it allows to efficiently encrypt messages of arbitrary sizes. Title: Re: jeeq: ECDSA encryption Post by: Qwedcxza1 on June 20, 2013, 12:24:32 PM I'm not a programmer so it's difficult to understand this without seeing a proper mathematical description of the encryption and decryption methods. If it uses elliptic curves then I doubt if you have reinvented EIGamal crypto system. There are hybrid cryptosystems based on elliptic curves such as ECIES but the plain text is not required to be a point on the curve. The problems of using elliptic curve implementations of EIGamal rather than discrete logarithm implementations relate to message expansion factors and difficulties of deterministically generating points on the curve which is why hybrid solution such as ECIES are used. Generally I would say that home made crypto systems should be approached with caution. There are plenty of good crypto systems out there. Let's say I want to encrypt 'hello' to your address Quote pubkey: your public key privkey: your private key I split my message in 32-char long chunks and put "0x00"s at the end of the last one to make it 32-char long too. That gives here only one chunk: 'hello---------------------------'. ('-' represents one 0x00) Now each chunk is used as an X. Let's call the correponding point M (Two M's are possible but it doesn't matter as I never use Y) Then I take a random N and calculate:
Those points are the encrypted data to be sent to the recipient. As pubkey=privkey*G, M is easily calculated. Note: Not all X values leads to a point on the EC. In such cases I just use offsets. Title: Re: jeeq: ECDSA encryption Post by: jackjack on June 20, 2013, 12:59:28 PM How about using ECC point multiplication and AES: It's indeed much more efficient1. Get recipient's public key R (R = r*G, r is private key) 2. For each message, generate unique keypair S,s: S = s*G. 3. Create a shared secret: K = R*s 4. Compute 256-bit encryption key out of that shared secret: key = SHA256(SHA256(K)) 5. Encrypt the message with that key and send the message together with unique pubkey S. 6. Recipient gets the message and computes key using his private key r and S: key = SHA256(SHA256(r*S)) 7. Recipient's key turns out to be the same because r*S = R*s = r*s*G. I like this scheme more because it allows to efficiently encrypt messages of arbitrary sizes. Just out of curiosity, is it possible to tweak this a bit to make the sender unable to read the crypted message? Title: Re: jeeq: ECDSA encryption Post by: oleganza on June 20, 2013, 02:18:08 PM How about using ECC point multiplication and AES: It's indeed much more efficient[...] I like this scheme more because it allows to efficiently encrypt messages of arbitrary sizes. Just out of curiosity, is it possible to tweak this a bit to make the sender unable to read the crypted message? What do you mean? Sender must know the message it is about to send. Title: Re: jeeq: ECDSA encryption Post by: jackjack on June 20, 2013, 02:40:49 PM How about using ECC point multiplication and AES: It's indeed much more efficient[...] I like this scheme more because it allows to efficiently encrypt messages of arbitrary sizes. Just out of curiosity, is it possible to tweak this a bit to make the sender unable to read the crypted message? What do you mean? Sender must know the message it is about to send. If I use your method, the computer may keep s somewhere (HDD, RAM, bash history, etc) and if it's compromised the attacker might be able to retrieve it and decrypt the message. Now that I'm writing it I realize that the same goes for the message and the random N... Title: Re: jeeq: ECDSA encryption Post by: Shevek on June 20, 2013, 03:24:44 PM How about using ECC point multiplication and AES: 1. Get recipient's public key R (R = r*G, r is private key) 2. For each message, generate unique keypair S,s: S = s*G. 3. Create a shared secret: K = R*s 4. Compute 256-bit encryption key out of that shared secret: key = SHA256(SHA256(K)) 5. Encrypt the message with that key and send the message together with unique pubkey S. 6. Recipient gets the message and computes key using his private key r and S: key = SHA256(SHA256(r*S)) 7. Recipient's key turns out to be the same because r*S = R*s = r*s*G. I like this scheme more because it allows to efficiently encrypt messages of arbitrary sizes. It's OK but: 1) There is no need of doubling SHA256 to obtain the symmetric key. SHA256^2 is a bitcoinish thing that does not improve the security of SHA256. In fact, there is no need of SHA256. Take "Kx" as symmetric key and it's ok. 2) It is better to use "S" as the shared secret and send "K" to the recipient. She can get the secret "S" as S = r^(-1) * K. This way, you can send the same encrypted message to many recipients: just create the K1, K2, K3, etc, pubkeys for de recipient's keys R1, R2, R3, etc Title: Re: jeeq: ECDSA encryption Post by: jackjack on June 20, 2013, 03:40:29 PM How about using ECC point multiplication and AES: 1. Get recipient's public key R (R = r*G, r is private key) 2. For each message, generate unique keypair S,s: S = s*G. 3. Create a shared secret: K = R*s 4. Compute 256-bit encryption key out of that shared secret: key = SHA256(SHA256(K)) 5. Encrypt the message with that key and send the message together with unique pubkey S. 6. Recipient gets the message and computes key using his private key r and S: key = SHA256(SHA256(r*S)) 7. Recipient's key turns out to be the same because r*S = R*s = r*s*G. I like this scheme more because it allows to efficiently encrypt messages of arbitrary sizes. It's OK but: 1) There is no need of doubling SHA256 to obtain the symmetric key. SHA256^2 is a bitcoinish thing that does not improve the security of SHA256. In fact, there is no need of SHA256. Take "Kx" as symmetric key and it's ok. 2) It is better to use "S" as the shared secret and send "K" to the recipient. She can get the secret "S" as S = r^(-1) * K. This way, you can send the same encrypted message to many recipients: just create the K1, K2, K3, etc, pubkeys for de recipient's keys R1, R2, R3, etc 1. Wouldn't you lose one bit of entropy? (As only half of x values between 0 and n-1 leads to a pair of points) Using Kx+(Ky&1) should make it a bit better right? Title: Re: jeeq: ECDSA encryption Post by: Shevek on June 20, 2013, 03:47:26 PM 1. Wouldn't you lose one bit of entropy? (As only half of x values between 0 and n-1 leads to a pair of points) Using Kx+(Ky&1) should make it a bit better right? Uhmm... if you don't want to leak even a single entropy bit, I think it's better SHA256(K) Title: Re: jeeq: ECDSA encryption Post by: oleganza on June 20, 2013, 04:10:43 PM 2) It is better to use "S" as the shared secret and send "K" to the recipient. She can get the secret "S" as S = r^(-1) * K. This way, you can send the same encrypted message to many recipients: just create the K1, K2, K3, etc, pubkeys for de recipient's keys R1, R2, R3, etc This is smart. Thanks for suggestion. Title: Re: jeeq: ECDSA encryption Post by: oleganza on June 20, 2013, 04:13:09 PM I was thinking about the private key s. The computer I'm using everyday should be safe but I wouldn't trust it for something risky. If I use your method, the computer may keep s somewhere (HDD, RAM, bash history, etc) and if it's compromised the attacker might be able to retrieve it and decrypt the message. Now that I'm writing it I realize that the same goes for the message and the random N... If you are trusting your computer with your message, you can trust it to hold a secret for a fraction of a second. Once you send out a message, simply clear the secret from memory, so it's not swapped on disk or otherwise extracted due to some corruption later on (it's a standard security practice, btw: put some secret in memory, use it, then zero it out ASAP). Title: Re: jeeq: ECDSA encryption Post by: crypto_trader#43xzEXrP on October 29, 2019, 04:23:06 AM Just leave here my implementation of Elliptic-Curve-Cryptography (ECC): https://github.com/username1565/mini_ecdsa/commit/54d2ba23973819806e85456941c3c1a099434bc7
Encrypt-decrypt messages, using elliptic curve bitcoin secp256k1. Draft code. Tests added, and working. Title: Re: jeeq: ECDSA encryption Post by: gmaxwell on October 30, 2019, 07:58:44 AM Just leave here my implementation of Elliptic-Curve-Cryptography (ECC): The above posters archive implements a similar totally cryptographically busted technique as was originally discussed in this thread.No one should ever use it, unless like.. you're trying to trick your enemies into using something insecure. :) [See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004720.html and following posts.] Title: Re: jeeq: ECDSA encryption Post by: crypto_trader#43xzEXrP on October 31, 2019, 10:34:23 AM Just leave here my implementation of Elliptic-Curve-Cryptography (ECC): The above posters archive implements a similar totally cryptographically busted technique as was originally discussed in this thread.No one should ever use it, unless like.. you're trying to trick your enemies into using something insecure. :) [See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004720.html and following posts.] there is info about ECIES, KDF-function, and some oracle value. But the script which I'd posted earlier, there is not using any KDF-function and oracle. There is using the multiplication of points (for encrypt) and division (to decrypt), and this multiplication and division is making to secret skalar (priv_key), which can be a long number (up to n, - the number of unique points on elliptic curve in finite field). But, if the same value will be used to multiply many points, in this case, maybe, there is some frequency analysis vulnerability, if some values of original points will be known for attacker... So I think will be better using some Key Derive Function (KDF) - to derive the key for each block... For example, encrypt by next way: Code: encrypted_point = ( current_point * (priv_key XOR (hash( the coordinates from next not encrypted point) ) Code: decrypted point = ( current_point / (priv_key XOR (NULL if no privious point, he cann't get key, because point cann't be divided to the point, on elliptic curve in finite field: Else: Code: Q = k*G; Q/G = k; where Q = pubkey, G - generator point (predefined for EC), k - privkey for bitcoin address; And, as you can see, the second operation is impossible easy, because ECDLP. But... For many points, with the same key, maybe, it will be mush easier. That I meaning, with "frequency analysis vulnerability", so regullary changing the key will be not superfluous. Also, as you can see, when message is encoding, the information redundancy appears. This is probably why elliptic cryptography is not used anywhere and not developed, because it is easier to use symmetric ciphers, which have a ciphertext length equal to the length of the message. Nevertheless, here is the code, you can research it, conduct an audit, start test, optimize and develop it. |