06:19:05 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. 06:19:50 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 06:20:35 So I tried this: https://pypi.org/project/PyNaCl/ and this: https://github.com/hanswolff/ed25519 06:21:31 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: https://xmr.llcoins.net/addresstests.html 06:23:31 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. 06:23:47 Any advice for this crypto noob? 12:13:45 Do you have the non functioning code to share? 12:17:37 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: https://paste.centos.org/view/35b83954 12:18:36 Code is from here: https://pypi.org/project/PyNaCl/ 12:22:36 And I only started to really wonder when it was 2 packages with identical results versus Monero :) 12:23:01 (the other one being the C# implementation) 13:39:16 rbrunner: have you checked endianness? 13:39:57 You mean whether all my bytes are just the wrong way round? 13:40:13 Yeah 13:40:26 No, not yet. 13:40:58 Will try 13:42:03 There was a stack exchange question solved by endianness in the last few months 13:44:09 https://monero.stackexchange.com/questions/11944/definitively-answering-a-question-about-sc-reduce32-with-a-simple-to-explain-wor/11946?r=SearchResults#11946 not sure if relevant 13:55:53 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. 14:05:27 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 14:06:21 Yes in monero afaik everything is little endian byte order 14:06:35 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? 14:07:51 It seems unlikely. What happens if you use a private key of '1'? 14:10:58 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)? 14:12:01 Yes, I purely deal with keys now. It's going from 3. to 5. here: https://xmr.llcoins.net/addresstests.html 14:14:10 That's interesting. With my C# package I can't reproduce that very special value that Monero spits out: 5866666666666666666666666666666666666666666666666666666666666666 14:14:23 Both way round, concerning endianness. 14:15:18 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) 14:17:58 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? 14:18:48 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? 14:19:27 Sorry, I just mean that I've gotten hex representations working as expected in Python 14:20:07 Basically it goes (private key representation) -> (internal scalar representation) -> (internal point representation via scalarmult) -> (public key representation) 14:20:16 Apologies if my poor wording was confusing 14:20:46 No problem :) 14:21:54 I can take a look later today at the library if you like 14:22:04 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? 14:22:20 But something completely different? 14:22:30 Might depend on how the library parses the hex representation 14:23:08 e.g. will it apply padding or not 14:23:15 Hence needing to examine the innards of the library :) 14:23:29 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 14:24:02 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 14:24:18 Happy to help 14:24:41 I'm sure this could also be useful to anyone else who decides to use these libraries in the future too 14:25:51 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 :) 14:26:23 heh 14:26:45 It's probably worth a small write-up on the encoding 14:26:52 and inclusion in something like ZtM 14:28:47 Usually people use libraries so these kinds of questions don't appear too often. I wasn't even aware 14:29:10 What do you mean with "peope use libraries"? 14:29:16 Oh I didn't mean to fault you UkoeHB_ for lack of inclusion in ZtM 14:30:31 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# 14:37:34 well they use the Monero library basically; mininero also uses that library afaik 14:38:20 as well as mymonero 14:39:50 sorry which lib? 14:40:05 for crypto 14:40:08 correct me 14:40:19 not whatfor but what name? 14:40:40 would it be ref10_commented_combined? 14:40:45 mymonero uses monero core 14:41:17 FWIW this simple (but _not_ audited and therefore not production-suitable) Python library does proper encodings: https://github.com/SarangNoether/skunkworks/tree/curves/dumb25519 14:42:01 ok bye 14:43:10 the `Scalar` constructor takes a string with a hex representation (like from that address page you linked) 14:43:45 then multiply that `Scalar` by `G` (the standard curve generator) and it'll produce a `Point` whose representation returns the expected hex string 14:44:50 rbrunner: you could see if there is a specific 'SUPERCOP ref10' implementation other than Monero's: https://github.com/monero-project/monero/tree/master/src/crypto/crypto_ops_builder 14:45:15 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" 14:51:21 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 14:51:37 In any case that's not something I could easily try today 14:52:40 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 14:54:13 vtnerd says here that ref10 comes from nacl https://monero.stackexchange.com/questions/3748/what-are-field-elements-and-group-elements-used-for/3764#3764 14:55:39 Seems the often-used "libsodium" Linux library also comes from NaCl 14:58:53 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" 15:09:34 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: https://paste.centos.org/view/64664f8e 15:42:23 everything comes from SUPERCOP 15:42:39 I think it's the other way around - NaCl came from SUPERCOP 15:46:34 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 16:07:46 rbrunner: if I'm reading the PyNaCl code correctly, the byte representation of the private key is actually a representation of a seed value 16:08:00 How that's used to internally generate the private key is not clear 16:10:36 rbrunner: there are plenty of crypto libraries if you want to stuff outside of the djb stack 16:11:01 but if you're going full djb-crypto then you want libsodium / NaCl / TweetNaCl / SUPERCOP 16:22:27 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. 16:22:51 Just like Monero has it, just unfortunately in C++. 16:23:18 To me it looks more and more that I will go and simply translate that from C++ to C# 16:25:06 If you don't care about speed, the djb-style code isn't terrible complicated 16:25:10 s/terrible/terribly 16:25:11 sarang meant to say: If you don't care about speed, the djb-style code isn't terribly complicated 16:25:28 Well, the Monero code isn't either :) 16:26:14 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 :) 16:27:55 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 16:28:36 It's only 300 lines: https://github.com/hanswolff/ed25519/blob/master/Ed25519/Ed25519.cs 16:29:46 Well, if it's helpful, that `dumb25519` library shows how the encoding maps to scalar and point internal values 16:29:48 and vice versa 16:30:25 Ok, will have a look. My journey continues. Thanks for the help! 16:30:57 I do wonder if it's simply that your library was reporting an intermediate seed value instead of the actual scalar representation 16:34:14 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 16:34:22 @rbrunner check out https://github.com/turtlecoin/cs-turtlecoin/tree/master/CantiLib/Cryptography/Native it’s most (if not all) of the CN ED25519 code ported to C#. May help you out. 16:36:14 IBurnMyCD: That looks suspiciously like the C++ code. Looks promising, maybe you did the work already that I saw ahead for me! 16:37:45 Aye. A couple of the lads went down the C# route a while ago and got some basics pounded out. 16:41:17 :praise: 16:52:37 ref10 is from supercop 16:52:59 crypto_sign/ed25519/ref10 iirc 16:54:30 oh no sorry it was nacl, and included in supercop. or whatever dont know which was first, probably supercop/ref10 name 16:55:29 rbrunner I didn't check all of the scrollback, but if you need this to remain constant time, it is not easy at all 16:55:50 and copying tweetnacl will be the easiest but worst performing. requires 64-bit integers 17:23:16 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 https://xmr.llcoins.net/addresstests.html 18:54:31 rbrunner I might take a look at that library today. Been awhile