Topic: jeeq: ECDSA encryption (Read 5532 times)

Hm, I see the in text, the link on which you did provided,
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:
In this case:
But, if attacker will know the original point, and know encrypted point,
he cann't get key, because point cann't be divided to the point, on elliptic curve in finite field:
Else:

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.

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.]

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.

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).

This is smart. Thanks for suggestion.

Uhmm... if you don't want to leak even a single entropy bit, I think it's better SHA256(K)

2. Indeed!
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?

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

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...

What do you mean? Sender must know the message it is about to send.

It's indeed much more efficient
Just out of curiosity, is it possible to tweak this a bit to make the sender unable to read the crypted message?

To be honest with you, I'm a bit busy and I haven't got time to study all of this. I'm really not knowledgeable enough to be properly commenting on this stuff anyway so I hope it does work and I'm going to retire and let you find some real experts.

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.

Let's say I want to encrypt 'hello' to your address

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:

• G*N
• pubkey*N + M

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.

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.

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:

The options are of course mixable

Hmm ok I think I get it, I'll look into an ECIES implementation to see how they handle that

I meant ElGamal with ECDSA. ElGamal is only with DSA, doesn't it?

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.

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).

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?

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