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

the other clamping was to help prevent leaks with crummy implementations (technically clearing them shouldn't matter if the implementation is done properly)

jamtis unit test working: github.com/UkoeHB/monero/blob/89e24…/tests/unit_tests/seraphis.cpp#L572

btw tevador, randomx's blake2b implementation is not exposed so I had to copy your files over to `src/crypto`

I also implemented `clear_internal_memory()` as a wrapper on `memwipe`.

luigi1111w maybe it's possible that

there could be an issue on a multi-user system

or an EM leak

not really sure

vtnerd interesting re: crummy implementations. did you figure that out yourself, or is there somewhere i can read up about that issue?

I recall that being the explanation in the paper (or perhaps on DJBs website) -

if the implementation does bit-by-bit with shifting, it always does a computation on the first bit, partially mitigating issues with constant-time

i.e. it doesn't leak the first "real-bit" - which always seemed like an odd explanation but I recall seeing that somewhere

especially since other implementations could just botch it - but I don't see how setting those bits _makes it constant-time_

*first bit->same bit

there was a stackoverflow question that claimed that about constant-time

i think people were questioning it though

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

vtnerd this stackexchange answer 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"

which i think is why it was thought important to always set the MSB to a fixed position

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)

which, perhaps thats why ed25519 doesnt even bother

vtnerd is the ed25519 scalarmult supposed to be constant-time?

i'd have thought that wouldn't have been a design consideration

it doesn't matter for verification, but it matters for signatures

*producing signature, the prover

i guess yeah it would be bad to leak k

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

in asm. like, its just a really shitty implementation if it wasnt' trying to be constant-time

it's weird that people don't say "use ed25519 for performance when verifying signatures, but use curve25519 for performance when creating signatures"

there must be certain situations where it's more of a performance consideration to optimize for signing rather than verifying

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

interesting, thanks for the info

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?

Specifically, I want to test the 'cn_fast_hash' with some inputs and check the outputs.

Are you writing C++ code?

<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

(But to create my tools I will need to understand a lot about the monero code (in c++))

Well `cn_fast_hash` is pretty easy to use: `#include "ringct/rctOps.h"` and `cn_fast_hash(some_rct_key_output, data, data_length)`.

There are a bunch of different `cn_fast_hash` overloads, but they all do the same thing.

There is also `hash_to_scalar()` which calls `cn_fast_hash()` then reduces the result modulo the ed25519 group order.

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.

I am not quite there to use ringct. I basically want to do the same as here: monero.stackexchange.com/questions/…lating-a-transaction-id/12236#12236

But for the v1

dangerousfreedom cnfasthash is this in python: stackoverflow.com/questions/4627912…an-i-find-keccak-256-hash-in-python

it's a little odd that you're referring to (version,unlock time, vin, vout, extra) as a "string"

if you want to calculate the txid yourself, you'll need to serialize the data exactly as the C code does

which means thinking about bytes and data types

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

knaccc: Yeah, I guess so. Which I dont understand properly yet :p

yeah you're probably going to have to get a lot more familiar with the C code

why are you trying to recalcualte tx ids?

I hope I won't need to understand the C code for now. I just want to understand what is being hashed.

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

It is not the tx id. It is the prefix_hash

why is that useful for you to calculate?

That it part of the signature in a transaction.

right, but what is the overall objective? are you just looking to learn about monero by re-implementing some stuff?

And I want to understand what the signature means so I can check if they are valid (at least the amounts are matching)

oh then you're going to need to learn a lot about crypto

like how to do elliptic curve stuff

and what pedersen commitments are

My objective is to prove that there is no inflation in monero using only a python code

that's already implemented as a feature in the node

In python?

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

knaccc: I'm trying :p

it'll be a fun project

but i'd start with understanding the crypto, rather than starting with coding

it's probably several weeks of work

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

knaccc: Yeah, maybe months :p

i assume you've seen this? github.com/monero-project/monero/bl…onote_basic/cryptonote_basic.h#L156

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.

what do you mean by "play with it"

Im trying to use the cn_fast_hash but Im confused about the data I need to pass

And how to easily do it

i assume you're starting with the bytes of a raw transaction, and just want to isolate the bytes of the prefix hash?

i mean isolate the bytes of the data you need to hash to get the prefix hash

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

knaccc: Yeah, basically that

And call the function

which one do you want to do: get the data from the json, or get the data from the raw transaction bytes

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?

there is a reason i'm asking. monero uses varints. if you are starting with the raw tx bytes, you already have the varints

if you start with the json, you have stuff that you need to convert to varints to get the right byte representation

Ah okay. I have the json. So how I start from the json information?

you have to cross-reference the json with that github link i just sent you

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

and then represent each field in the json in the byte format that is required for the hash

so you can't just write an int

you need to convert the int to a varint, which is a particular way of writing the int

if i were you, i'd write code to parse the raw tx bytes and check your results against what the json is reporting

and that'll get you familiar with data types like varints and uint64_t

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

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.

what i'm saying is you can't just see a number being reported by the json and use it directly

that'll get you the wrong result

you need to know what a varint is or you'll get nowhere

Ahhh... I hope not. Let me rephrase what I'm trying to do.

here is a simple example:

you look at the json, and it gives you the unlock time 796803

how do you convert that into bytes?

if you don't convert it to bytes in exactly the right way, the hash will fail

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.

yeah i understand that, but the hash is expecting a series of bytes

and so how do you convert the number 796803 into the correct series of bytes?

knaccc: Thats a good question :p

I'm hoping that there are simple functions to do it.

right, and to learn what functions you need to implement or look up, you need to understand exactly what data formats are required

because it turns out that unlocktime needs to be written as a uint64_t

and other things need to be written as varints

and the extra field is just a series of bytes

and vin and vout are varints

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

But I dont even know how to use the monero cn_fast_hash to hash for example the string '1' in bytes

what is 1? is it a hex character?

a string for example

1 as a string is the byte 31

monero doesn't use strings

because 1 is an ascii code if it's treated as a string

so you need to stop thinking about strings, and start thinging about either hex strings or byte sequences

Yes. Thanks for answering these questions, my c++ skills and data structure knowledge are pretty rusty.

knaccc: I remember that :p

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

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?

the objective is just to check that your python version of cn_fast_hash is working properly right?

knaccc: You will have to specify, of course.

knaccc: Yes!

not only will you need to specify, but you might even need to write your own varint code

because it's not a common data format

(But with the future goal to check that I get the same prefix_hash as I get in monero.)

if i just tell you a test vector, like what cn_fast_hash should output for a certain test input, will that be enough?

you don't need to actually call the C version if you know an example of what input and output should happen in python

If you tell me, then I would need to trust you and that is much harder to verify :p

hehe well then i guess you're going to have to learn how to set up a C environment :)

knaccc: Would be great to have a small list of inputs and outputs though

knaccc: I hope I wont have to go to assembly later haha

here is something to get you started: if you hash a 32 byte sequence consisting of zeroes, you'll get 290decd9548b62a8d60345a988386fc84ba6bc95484008f6362f93160ef3e563

this tool will help you

make sure you set the input type to hex if you give it a hex string

Ok. I see that the cn_fast_hash calls the keccak1600. Is it the same as this keccak256 ?

yes

Is there a reason to have different names?

`cn_fast_hash` forces the result to 32 bytes

256 is the output length in bits, 1600 = 1088+512 which is an internal thing

Ok thanks :)