Curve25519 elliptic curve, public key function

[Keya]

weird, the forum isn't showing any of your posts in this thread as Edited?!? must be an April Fools thing because yes i can see EC_LoadKeys and EC_SaveKeys plus the 'Updated 31/3/16' you typed in the header playing with them now to try to learn, thankyou!!!

btw is this "just the elliptic curve (Curve25519) to be used with Diffie-Hellman (not included)",
or is it a full "Elliptic Curve (Curve25519) + Diffie-Hellman"? im trying to get my head around it from http://en.wikipedia.org/wiki/Elliptic_c ... %93Hellman

I ask because the code seems mostly if not all about the Curve (its surprising but awesome how there isnt too much code!), and there's not much DH stuff but there is for example DHKeys struct, but im wondering if thats more a placeholder because at the start you use "salt n pepper" as Bob and Alice's shared secret, and it seems as long as the MITM doesnt know that then the channel is secure, but im wondering if Alice and Bob have to use Diffie-Hellman first before all this to establish what "salt n pepper" would actually be in real life?

^ or just a simpler way of asking the above...

Code: Select all

   client = modEC::NewEC("salt n pepper")  ;Create new EC context with out of channel passphrase
   server  = modEC::NewEC("salt n pepper")

Should the comment perhaps be ";Create new EC context with out of channel passphrase which normally would be created/established using Diffie-Hellman" ? or....?

thanks and sorry for my confusion!

[idle]

It's just the elliptic curve, how you implement the key exchange is up to you.
As far as I know you can't guarantee to establish a secure channel without having forward secrecy and that's the conundrum.
If there was a man in the middle a dh key exchange could fail as the man intercepts and returns
his public key to you and the other party. If he knows the protocol you use your toast.
By adding an out of channel salt, it will throw off a man in the middle so when you switch to encryption and send a challenge to the other party
the man in the middle won't be able to echo the challenge back and then you'll know the channel is compromised.
How you get the out of channel salt across to the other party is another thing.
but once you've got a secure channel you can create a set of keys for that group or peer and then use them
with forward secrecy.
I don't know if adding the salt is a bad thing but I couldn't work out how one's supposed to do it without some secret

[Keya]

If there was a man in the middle a dh key exchange could fail as the man intercepts and returns
his public key to you and the other party. If he knows the protocol you use your toast.

i thought Diffie-Hellman was what prevented the MITM attack though, as it allows Alice and Bob to establish a shared secret over insecure comms? assuming the DH is authenticated to prevent the MITM that is:

In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. Mallory may establish two distinct key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing her to decrypt, then re-encrypt, the messages passed between them. Note that Mallory must continue to be in the middle, transferring messages every time Alice and Bob communicate. If she is ever absent, her previous presence is then revealed to Alice and Bob. They will know that all of their private conversations had been intercepted and decoded by someone in the channel.

A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie–Hellman, such as STS protocol, may be used instead to avoid these types of attacks.

all these chickens and eggs! lol. but anyway it sounds like authenticated Diffie-Hellman is all that's needed to securely establish salt'n'pepper?

[idle]

yes it is chicken and egg.
if you had an https server at your disposal you could use that to dish out keys for your programs users
so then the users of your program could connect to each other with forward secrecy but without it, it gets complicated.
An out of channel pass phrase will at least detect if there's a man in the middle the issue is how do you convey that secret
slip it across a table in a cafe? choose a phrase from a sentence in your secret book?

[Bo Marchais]

Ah, the old "passing the tiny folded note in a tiny cafe in a small european city" cipher, and the only one that requires sun glasses to be worn if you want it to work. When used farther south - say, south of italy, I think one must wear both the sun glasses AND a fez.
It's very popular in movies and spy novels; almost as popular as people running hacker OS, the colorful operating system that runs only with random key strokes...and lets you control alien flying saucers and see things in great detail that you actually have no data for.

Probably way more secure than elliptic curves, though.

[Keya]

Probably way more secure than elliptic curves, though.

what do you suggest instead?

[Bo Marchais]

Me? I like that one trick professional cryptologists hate!
I'm not real wild about the side channel attacks, though.

But... my only secret is my watermelon BBQ sauce, so...

[idle]

Tested with c backend on x64 and Raspberry Pi

[jack]

hello idle
sorry to say that it fails to run on Windows 11 x64 PB 6.00 beta 1 with the C backend, runs ok if using the asm backend
the console abruptly closes

[idle]

OK I will take another look, has an IMA line 479 on linux X64 with c backend
I must have tested it with v6 with fasm backend thinking i was the c backend and moved on before the penny dropped that I had to compile from the command line.