I am still on my journey to implement Monero key derivation in C#. I have worked out so far hashing private spends keys and reducing them to obtain private views keys.

I now try to derive public keys from private keys. I was first trying this with Curve25519, but helpful people told me being on the wrong curve and using Ed25519

So I tried this: pypi.org/project/PyNaCl and this: github.com/hanswolff/ed25519

The results these two packages give agree, they produce identical verifying keys from private keys. However, Monero comes up with different keys, as checked here: xmr.llcoins.net/addresstests.html

I could not find anything in "Zero to Monero" that I could interpret as info how Monero would do something different from plain / pure / stock Ed25519.

Any advice for this crypto noob?

Do you have the non functioning code to share?

Well, both with the C# library and with the NaCl Python code it's basically one-liners to go from private key to public key. The Python code: paste.centos.org/view/35b83954

Code is from here: pypi.org/project/PyNaCl

And I only started to really wonder when it was 2 packages with identical results versus Monero :)

(the other one being the C# implementation)

rbrunner: have you checked endianness?

You mean whether all my bytes are just the wrong way round?

Yeah

No, not yet.

Will try

There was a stack exchange question solved by endianness in the last few months

monero.stackexchange.com/questions/…ain-wor/11946?r=SearchResults#11946 not sure if relevant

Just to be sure: To change the endian-ness would just mean to reverse the order of the bytes, right? The bytes themselves keep their values, I mean to say.

If reversing the order of the bytes is the correct way to try, the answer is probably: No, that does not seem to be the problem, the resulting public keys are still different

Yes in monero afaik everything is little endian byte order

I remember from your book, UkoeHB_, that Monero has some mysterious factor of 8 in another place. Maybe we have another such mysterious difference at work here?

It seems unlikely. What happens if you use a private key of '1'?

To be clear rbrunner, you're seeing mismatches between representations of private keys mapping to representations of public keys (not addresses, at least for the purpose of this discussion)?

Yes, I purely deal with keys now. It's going from 3. to 5. here: xmr.llcoins.net/addresstests.html

That's interesting. With my C# package I can't reproduce that very special value that Monero spits out: 5866666666666666666666666666666666666666666666666666666666666666

Both way round, concerning endianness.

I've gotten key mapping representations to work in Python, so I can take a look at that library's innards later today if you like (not available to do so right now)

That's interesting, and somewhat unexpected. I was expecting an info what I obviously do wrong, like that story with the wrong curve. Now it could be something about "key mapping representations" which I never heard. Huh?

If I understand correctly that Python library is a more-or-less direct descendant of djb code. Monero could be doing something substantially different here then?

Sorry, I just mean that I've gotten hex representations working as expected in Python

Basically it goes (private key representation) -> (internal scalar representation) -> (internal point representation via scalarmult) -> (public key representation)

Apologies if my poor wording was confusing

No problem :)

I can take a look later today at the library if you like

So you mean to say that if I want to feed that Python library the value 1, as was UkoeHB's idea, maybe I have to feed not simply 010000000... (or ...0000001) to that Python library?

But something completely different?

Might depend on how the library parses the hex representation

e.g. will it apply padding or not

Hence needing to examine the innards of the library :)

Alright, in any case I don't want to waste your time, but on the other hand I would very much to break through with this, and I am afraid without help I am lost

Assuming it's doing the scalar-to-point mult correctly, it's going to be an issue of how it's translating hex representations to internal structures for scalars/points

Happy to help

I'm sure this could also be useful to anyone else who decides to use these libraries in the future too

Yeah, it *is* a little strange. Google, take a well-renowned Ed215519 libary, different result from Monero. Take *another* well-know library, same result as the first one, again different from Monero. And the programmer goes wtf :)

heh

It's probably worth a small write-up on the encoding

and inclusion in something like ZtM

Usually people use libraries so these kinds of questions don't appear too often. I wasn't even aware

What do you mean with "peope use libraries"?

Oh I didn't mean to fault you UkoeHB_ for lack of inclusion in ZtM

That's my problem, I can do nothing else than use libraries, being a complete noob, and they don't give what Monero gives. And if I want to use Monero code I would have to translate myself from C++ to C#

well they use the Monero library basically; mininero also uses that library afaik

as well as mymonero

sorry which lib?

for crypto

correct me

not whatfor but what name?

would it be ref10_commented_combined?

mymonero uses monero core

FWIW this simple (but _not_ audited and therefore not production-suitable) Python library does proper encodings: github.com/SarangNoether/skunkworks/tree/curves/dumb25519

ok bye

the `Scalar` constructor takes a string with a hex representation (like from that address page you linked)

then multiply that `Scalar` by `G` (the standard curve generator) and it'll produce a `Point` whose representation returns the expected hex string

rbrunner: you could see if there is a specific 'SUPERCOP ref10' implementation other than Monero's: github.com/monero-project/monero/tr…aster/src/crypto/crypto_ops_builder

I just checked: If you search NuGet for packages with key word "Ed25519", each that I could find seems to derive somehow from that famous djb et al "NaCl"

If I search for "SUPERCOP ref10" for C#, not much turns up. One implementation I saw is 6 years old and would probably require work to try on the latest .NET Core 3 framework

In any case that's not something I could easily try today

As it looks to me that this "NaCl" stuff is very widespread nowadays, it would probably be nice to have some instruction how to go from that to Monero, and vica-versa

vtnerd says here that ref10 comes from nacl monero.stackexchange.com/questions/…d-group-elements-used-for/3764#3764

Seems the often-used "libsodium" Linux library also comes from NaCl

sarang: Will be interesting to see how much is visible at all in the Python part, because I just noticed this on the project page: "PyNaCl is a Python binding to libsodium"

By the way, sarang, I gave the wrong code above in the paste, that was the earlier code for Curve25519. The Ed25519 code is this: paste.centos.org/view/64664f8e

everything comes from SUPERCOP

I think it's the other way around - NaCl came from SUPERCOP

Might be. Just that today almost nothing else except NaCl and its many ports and descendants seem to be still around, if I understand correctly

rbrunner: if I'm reading the PyNaCl code correctly, the byte representation of the private key is actually a representation of a seed value

How that's used to internally generate the private key is not clear

rbrunner: there are plenty of crypto libraries if you want to stuff outside of the djb stack

but if you're going full djb-crypto then you want libsodium / NaCl / TweetNaCl / SUPERCOP

What I would like to have, ideally, is not some library, but x lines of C# code (with "x" a reasonable number) with the least number of dependencies that can go from Monero private keys to Monero public keys.

Just like Monero has it, just unfortunately in C++.

To me it looks more and more that I will go and simply translate that from C++ to C#

If you don't care about speed, the djb-style code isn't terrible complicated

s/terrible/terribly

Well, the Monero code isn't either :)

It's just some kind of defeat, in my eyes. Really, how hard can that be? Such a simple job, in principle. Ed25519, and you are set. Yeah, right :)

Maybe with the info that my input is not yet the private key, but only a seed, I can see in the C# implementation whether there is a neat point to intervene, with the private key as a temporary result for example

It's only 300 lines: github.com/hanswolff/ed25519/blob/master/Ed25519/Ed25519.cs

Well, if it's helpful, that `dumb25519` library shows how the encoding maps to scalar and point internal values

and vice versa

Ok, will have a look. My journey continues. Thanks for the help!

I do wonder if it's simply that your library was reporting an intermediate seed value instead of the actual scalar representation

In any case that library can technically give almost anything it likes, because probably it's expected people will do nothing else than go into the signing method with it, and that will know what it gets

<IBurnMyCD (TRTL)> @rbrunner check out github.com/turtlecoin/cs-turtlecoin…master/CantiLib/Cryptography/Native it’s most (if not all) of the CN ED25519 code ported to C#. May help you out.

IBurnMyCD: That looks suspiciously like the C++ code. Looks promising, maybe you did the work already that I saw ahead for me!

<IBurnMyCD (TRTL)> Aye. A couple of the lads went down the C# route a while ago and got some basics pounded out.

<RockSteady (TRTL)> :praise:

ref10 is from supercop

crypto_sign/ed25519/ref10 iirc

oh no sorry it was nacl, and included in supercop. or whatever dont know which was first, probably supercop/ref10 name

rbrunner I didn't check all of the scrollback, but if you need this to remain constant time, it is not easy at all

and copying tweetnacl will be the easiest but worst performing. requires 64-bit integers

vtnerd: Thanks for the cautionary hint, but no, constant time or other security measures are no problem, like it isn't for Luigi's veteran website at xmr.llcoins.net/addresstests.html

rbrunner I might take a look at that library today. Been awhile