10:45:49 <dangerousfreedom> Hello! I'm trying to print the serialized version of the transaction prefix so I can understand what the 'prefix_hash' means in the v1 transactions... so, is there an easy way to print the data in the function cn_fast_hash in src/crypto/hash.c ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c969a8938ba846acbc292c01cdf81dbd26daede5)
11:07:54 <moneromooo> Call obj_to_json_str on the object.
11:08:36 <moneromooo> monero-debug-utils-deserialize will do it for you if you're interested in just a particular bitstring.
11:49:47 <dangerousfreedom> Thank you again moneromooo !!
22:27:13 <knaccc> btw regarding timing attacks: i learned that there is a good reason that certain bits are cleared in x25519 private keys: https://crypto.stackexchange.com/a/11818/43864
22:27:53 <knaccc> which means that depending on whether we want view-key scanning to be constant-time or not, it's a consideration for how the tx private key is chosen
22:28:25 <knaccc> and a consideration for how the private view key is generated
22:33:12 <UkoeHB> isn't the key derivation function supposed to be constant time?
22:35:19 <knaccc> UkoeHB i assume you're referring to the scalarmult and not the kdf after the scalarmult?
22:35:54 <knaccc> it's not constant-time if you don't clear certain bits
22:37:36 <UkoeHB> the scalarmult
22:48:54 <knaccc> i think that clearing the most significant bit is to make it constant-time, and forcing the second-most significant bit to 1 is for performance because apparently it helps to "Use a fixed position for the leading 1 in the secret key" according to DJB's paper
22:50:31 <knaccc> http://cr.yp.to/ecdh/curve25519-20060209.pdf
22:50:34 <UkoeHB> does that imply some special optimizations?
22:53:57 <knaccc> he says to check sections 4 and 5 in the paper for details, but i can't see anything about the fixed position for the leading 1
22:54:18 <knaccc> he says "Making a few bad choices can destroy performance"
22:54:23 <knaccc> so this makes me wonder  
22:54:55 <knaccc> we need to look at those benchmarks again, but ensuring we preserve the proper bit clearing and forcing on the secret key
22:55:26 <knaccc> otherwise the benchmarks may be too slow for curve25519 because we've "destroyed performance" with a bad choice
22:55:38 <knaccc> cc jberman
22:57:38 <knaccc> i wonder if there is a significant performance difference
23:01:49 <knaccc> i thought it was curious that e.g. signal creates ed25519 pubkeys from curve25519 pubkeys, and not the other way around
23:02:35 <knaccc> since they jump through hoops to change the sign of the ed25519 private key to remove the mapping ambiguity of the public key
23:02:55 <knaccc> but maybe there is a really good reason they did it that way around
23:03:14 <knaccc> (they talk about the conversion here: https://signal.org/docs/specifications/xeddsa/)
23:48:15 <luigi1111w> what's the benefit of constant time?
23:56:47 <merope> usually it's to prevent side-channel/timing attacks, no?