00:12:46 <vtnerd> knaccc: clearing the lowest 3-bits has nothing to do with constant-time, and technically makes the algo 3-bits weaker than the current ed25519 scalarmult
00:13:23 <vtnerd> the other clamping was to help prevent leaks with crummy implementations (technically clearing them shouldn't matter if the implementation is done properly)
00:14:59 <UkoeHB> jamtis unit test working: https://github.com/UkoeHB/monero/blob/89e24340da1e213ffc37e74d41053d442158eb2d/tests/unit_tests/seraphis.cpp#L572
00:23:51 <UkoeHB> btw tevador, randomx's blake2b implementation is not exposed so I had to copy your files over to `src/crypto`
00:24:53 <UkoeHB> I also implemented `clear_internal_memory()` as a wrapper on `memwipe`.
00:48:41 <knaccc> luigi1111w maybe it's possible that 
00:49:05 <knaccc> there could be an issue on a multi-user system
00:49:09 <knaccc> or an EM leak
00:49:11 <knaccc> not really sure
00:50:14 <knaccc> vtnerd interesting re: crummy implementations. did you figure that out yourself, or is there somewhere i can read up about that issue?
00:51:00 <vtnerd> I recall that being the explanation in the paper (or perhaps on DJBs website) -
00:51:53 <vtnerd> if the implementation does bit-by-bit with shifting, it always does a computation on the first bit, partially mitigating issues with constant-time
00:52:25 <vtnerd> i.e. it doesn't leak the first "real-bit" - which always seemed like an odd explanation but I recall seeing that somewhere
00:52:43 <vtnerd> especially since other implementations could just botch it - but I don't see how setting those bits _makes it constant-time_
00:52:56 <vtnerd> *first bit->same bit
00:53:06 <knaccc> there was a stackoverflow question that claimed that about constant-time
00:53:28 <knaccc> i think people were questioning it though
00:54:10 <vtnerd> theres been vague discussions about it on modern-crypto? mailing list, and it came up yet again on another list let me see if I can find some links to the archives
00:55:06 <knaccc> vtnerd this stackexchange answer https://crypto.stackexchange.com/a/11818/43864 says "In practice, the first step of the ladder will be to find the most significant bit of the exponent. This is not hard, of course, but doing so may leak, through timing, information about the most significant bits of the exponent"
00:55:39 <knaccc> which i think is why it was thought important to always set the MSB to a fixed position
00:56:57 <vtnerd> hmm maybe have to go back and look at the ladder implementation. I dont see how this could matter with the window-method of ed25519 (both scalarmult and scalarmultbase)
00:57:21 <vtnerd> which, perhaps thats why ed25519 doesnt even bother
00:57:23 <knaccc> vtnerd is the ed25519 scalarmult supposed to be constant-time?
00:57:35 <knaccc> i'd have thought that wouldn't have been a design consideration
00:57:57 <vtnerd> it doesn't matter for verification, but it matters for signatures
00:58:07 <vtnerd> *producing signature, the prover
00:58:36 <knaccc> i guess yeah it would be bad to leak k
00:59:16 <vtnerd> the x86-64 scalarmultbase in supercop is definitely designed to be constant-time, it touches every value in the pre-generated table and does cmov instead of branching
00:59:35 <vtnerd> in asm. like, its just a really shitty implementation if it wasnt' trying to be constant-time
00:59:37 <knaccc> it's weird that people don't say "use ed25519 for performance when verifying signatures, but use curve25519 for performance when creating signatures"
01:00:26 <knaccc> there must be certain situations where it's more of a performance consideration to optimize for signing rather than verifying
01:00:30 <vtnerd> perhaps our adapation for arbitrary ed25519 botched something (really hope not), but the prover code from supercop would be modified if someone found it to be variable timed
01:01:06 <knaccc> interesting, thanks for the info
21:12:14 <dangerousfreedom> What is the easiest way to test the cryptographic functions used by monero? Is there a help guide showing the commands and how to use it? 
21:12:14 <dangerousfreedom> Specifically, I want to test the 'cn_fast_hash' with some inputs and check the outputs.
21:18:15 <UkoeHB> Are you writing C++ code?
21:45:26 <dangerousfreedom> <UkoeHB> "Are you writing C++ code?" <- I'm trying not to. I just want to do the minimum in C++ to create my tools in Python
22:00:33 <dangerousfreedom> (But to create my tools I will need to understand a lot about the monero code (in c++))
22:05:44 <UkoeHB> Well `cn_fast_hash` is pretty easy to use: `#include "ringct/rctOps.h"` and `cn_fast_hash(some_rct_key_output, data, data_length)`.
22:06:09 <UkoeHB> There are a bunch of different `cn_fast_hash` overloads, but they all do the same thing.
22:07:06 <UkoeHB> There is also `hash_to_scalar()` which calls `cn_fast_hash()` then reduces the result modulo the ed25519 group order.
22:12:34 <dangerousfreedom> Ok. Thanks UkoeHB . What I am trying to do is to understand the meaning of the 'prefix_hash' in the v1 transactions. From my understanding, I need to pass the tx string (version,unlock time, vin, vout, extra) and hash it with the cn_fast_hash algorithm. I will see if I can create a new file then in C++ and only play with this function alone.
22:15:09 <dangerousfreedom> I am not quite there to use ringct. I basically want to do the same as here: https://monero.stackexchange.com/questions/12229/questions-about-calculating-a-transaction-id/12236#12236
22:15:09 <dangerousfreedom> But for the v1
22:23:43 <knaccc> dangerousfreedom cnfasthash is this in python: https://stackoverflow.com/questions/46279121/how-can-i-find-keccak-256-hash-in-python
22:25:07 <knaccc> it's a little odd that you're referring to (version,unlock time, vin, vout, extra) as a "string"
22:25:56 <knaccc> if you want to calculate the txid yourself, you'll need to serialize the data exactly as the C code does
22:26:08 <knaccc> which means thinking about bytes and data types
22:26:53 <dangerousfreedom> Thanks knaccc . I am already using some libraries in python (pysha3 is one of those). My problem is to understand what I need to hash so my code in python matches with what is happening inc c++
22:27:44 <dangerousfreedom> knaccc: Yeah, I guess so. Which I dont understand properly yet :p
22:28:36 <knaccc> yeah you're probably going to have to get a lot more familiar with the C code
22:28:42 <knaccc> why are you trying to recalcualte tx ids?
22:29:55 <dangerousfreedom> I hope I won't need to understand the C code for now. I just want to understand what is being hashed.
22:29:56 <knaccc> i assume you're not trying to build your own txs, and the place you get the tx from will already report the txid to you
22:30:07 <dangerousfreedom> It is not the tx id. It is the prefix_hash
22:30:20 <knaccc> why is that useful for you to calculate?
22:31:04 <dangerousfreedom> That it part of the signature in a transaction.
22:31:35 <knaccc> right, but what is the overall objective? are you just looking to learn about monero by re-implementing some stuff?
22:31:48 <dangerousfreedom> And I want to understand what the signature means so I can check if they are valid (at least the amounts are matching)
22:32:05 <knaccc> oh then you're going to need to learn a lot about crypto
22:32:17 <knaccc> like how to do elliptic curve stuff
22:32:24 <knaccc> and what pedersen commitments are
22:32:32 <dangerousfreedom> My objective is to prove that there is no inflation in monero using only a python code
22:32:49 <knaccc> that's already implemented as a feature in the node
22:33:12 <dangerousfreedom> In python?
22:34:10 <knaccc> no C. i'm just letting you know that it'll be a huge amount of work to learn enough about how the signatures are verified
22:34:15 <dangerousfreedom> knaccc: I'm trying :p
22:34:20 <knaccc> it'll be a fun project
22:34:30 <knaccc> but i'd start with understanding the crypto, rather than starting with coding
22:35:02 <knaccc> it's probably several weeks of work
22:35:53 <dangerousfreedom> I believe I have basic understanding about everything (coding and math). I want to do stuff now. So, I will start with the v1 and move forward chronologically
22:36:09 <dangerousfreedom> knaccc: Yeah, maybe months :p
22:37:24 <knaccc> i assume you've seen this? https://github.com/monero-project/monero/blob/298c9a357f6e57eccf28db1f3e734eb6da080d9a/src/cryptonote_basic/cryptonote_basic.h#L156
22:40:12 <dangerousfreedom> knaccc: Exactely! Thats why I believe that there is only the version,unlock time, vin, vout and extra. I dont know how to play with it though.
22:40:26 <knaccc> what do you mean by "play with it"
22:40:31 <dangerousfreedom> Im trying to use the cn_fast_hash but Im confused about the data I need to pass
22:41:03 <dangerousfreedom> And how to easily do it
22:41:27 <knaccc> i assume you're starting with the bytes of a raw transaction, and just want to isolate the bytes of the prefix hash?
22:41:53 <knaccc> i mean isolate the bytes of the data you need to hash to  get the prefix hash
22:43:04 <dangerousfreedom> I have my json of my tx (or just the data corresponding to these fields) but I dont know how to call this function alone or if there is any binding to easily do it
22:43:29 <dangerousfreedom> knaccc: Yeah, basically that
22:43:33 <dangerousfreedom> And call the function
22:43:53 <knaccc> which one do you want to do: get the data from the json, or get the data from the raw transaction bytes
22:44:54 <dangerousfreedom> First I want to know how it is hashed. I assume than that I need to pass the bytes? But in which order and how?
22:45:24 <knaccc> there is a reason i'm asking. monero uses varints. if you are starting with the raw tx bytes, you already have the varints
22:45:41 <knaccc> if you start with the json, you have stuff that you need to convert to varints to get the right byte representation
22:46:53 <dangerousfreedom> Ah okay. I have the json. So how I start from the json information?
22:48:09 <knaccc> you have to cross-reference the json with that github link i just sent you
22:48:28 <dangerousfreedom> (I could have the raw tx bytes I guess but then it would be horrible to read and make sense of what I am doing)
22:48:29 <knaccc> and then represent each field in the json in the byte format that is required for the hash
22:48:38 <knaccc> so you can't just write an int
22:48:59 <knaccc> you need to convert the int to a varint, which is a particular way of writing the int
22:49:33 <knaccc> if i were you, i'd write code to parse the raw tx bytes and check your results against what the json is reporting
22:50:01 <knaccc> and that'll get you familiar with data types like varints and uint64_t
22:50:33 <knaccc> and once you are familiar, you'll know how to then either extract the right parts of the raw tx, or how to use the json values to produce the correct bytes that need hashing
22:52:49 <dangerousfreedom> I see... I accept your suggestion. For now I will believe that what the code gives me as a json readable version is the same as it is passed by raw bytes and continue with my project. If I get the same thing in Python, I will assume it is correct and wont try to understand what these C files are doing.
22:54:00 <knaccc> what i'm saying is you can't just see a number being reported by the json and use it directly
22:54:03 <knaccc> that'll get you the wrong result
22:54:10 <knaccc> you need to know what a varint is or you'll get nowhere
22:55:33 <dangerousfreedom> Ahhh... I hope not. Let me rephrase what I'm trying to do.
22:56:16 <knaccc> here is a simple example:
22:56:27 <knaccc> you look at the json, and it gives you the unlock time 796803
22:56:37 <knaccc> how do you convert that into bytes?
22:56:53 <knaccc> if you don't convert it to bytes in exactly the right way, the hash will fail
22:56:59 <dangerousfreedom> I have an implementation of cn_fast_hash in Python and I want to check that I get the same thing as I get in monero from a known transaction that I have the json file.
22:57:19 <knaccc> yeah i understand that, but the hash is expecting a series of bytes
22:57:34 <knaccc> and so how do you convert the number 796803 into the correct series of bytes?
22:57:55 <dangerousfreedom> knaccc: Thats a good question :p
22:57:55 <dangerousfreedom> I'm hoping that there are simple functions to do it.
22:58:35 <knaccc> right, and to learn what functions you need to implement or look up, you need to understand exactly what data formats are required
22:58:43 <knaccc> because it turns out that unlocktime needs to be written as a uint64_t
22:58:57 <knaccc> and other things need to be written as varints
22:59:06 <knaccc> and the extra field is just a series of bytes
22:59:26 <knaccc> and vin and vout are varints
23:00:29 <dangerousfreedom> For example: cn_fast_hash(bytes(version)+bytes(unlock_time)+...). In python I think it would be easy (if there is no implementation problems with these functions...)
23:01:26 <dangerousfreedom> But I dont even know how to use the monero cn_fast_hash to hash for example the string '1' in bytes
23:02:21 <knaccc> what is 1? is it a hex character?
23:02:33 <dangerousfreedom> a string for example
23:03:09 <knaccc> 1 as a string is the byte 31
23:03:30 <knaccc> monero doesn't use strings
23:04:59 <knaccc> because 1 is an ascii code if it's treated as a string
23:05:36 <knaccc> so you need to stop thinking about strings, and start thinging about either hex strings or byte sequences
23:05:44 <dangerousfreedom> Yes. Thanks for answering these questions, my c++ skills and data structure knowledge are pretty rusty.
23:05:54 <dangerousfreedom> knaccc: I remember that :p
23:06:51 <knaccc> the bottom line is: there is no way that if you give python an integer, that it will magically know how to convert that into the correct byte sequence
23:06:55 <dangerousfreedom> Ok, so how is the easiest way to call the cn_fast_hash in monero? Should I create a file with the implementation of this function to play with it or is there an easy way to call this function?
23:07:43 <knaccc> the objective is just to check that your python version of cn_fast_hash is working properly right?
23:07:47 <dangerousfreedom> knaccc: You will have to specify, of course.
23:08:00 <dangerousfreedom> knaccc: Yes!
23:08:16 <knaccc> not only will you need to specify, but you might even need to write your own varint code
23:08:23 <knaccc> because it's not a common data format
23:08:41 <dangerousfreedom> (But with the future goal to check that I get the same prefix_hash as I get in monero.)
23:08:51 <knaccc> if i just tell you a test vector, like what cn_fast_hash should output for a certain test input, will that be enough?
23:09:28 <knaccc> you don't need to actually call the C version if you know an example of what input and output should happen in python
23:09:31 <dangerousfreedom> If you tell me, then I would need to trust you and that is much harder to verify :p
23:10:01 <knaccc> hehe well then i guess you're going to have to learn how to set up a C environment :)
23:10:07 <dangerousfreedom> knaccc: Would be great to have a small list of inputs and outputs though
23:10:42 <dangerousfreedom> knaccc: I hope I wont have to go to assembly later haha
23:13:11 <knaccc> here is something to get you started: if you hash a 32 byte sequence consisting of zeroes, you'll get 290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563
23:14:32 <knaccc> this tool will help you
23:14:35 <knaccc> https://emn178.github.io/online-tools/keccak_256.html
23:14:42 <knaccc> make sure you set the input type to hex if you give it a hex string
23:16:17 <dangerousfreedom> Ok. I see that the cn_fast_hash calls the keccak1600. Is it the same as this keccak256 ?
23:16:46 <knaccc> yes
23:18:24 <dangerousfreedom> Is there a reason to have different names?
23:19:20 <UkoeHB> `cn_fast_hash` forces the result to 32 bytes
23:19:24 <knaccc> 256 is the output length in bits, 1600 = 1088+512 which is an internal thing
23:22:52 <dangerousfreedom> Ok thanks :)