earonesty

All you have to do is wait for all the other signers to report their shares. Then you and your attacker partner can ksums attack R. You don't need to...

The attacker can have m without being able to get m0, and that's enough. On Mon, Mar 9, 2020 at 5:54 AM shumy-tools wrote: > @earonesty By R you meen...

Not really good at math proofs. But, it's easy to see that you can birthday-attack to control for a specific R. Which implies you already have m. On Mon, Mar...

The idea is that two or more attackers are "lying" about their shares of the public nonce. They aren't following your formula and hashing the message. They are just controlling...

Seems this answer here shows the issue better than I can: https://crypto.stackexchange.com/questions/77683/is-this-distributed-random-oracle-scheme-safe

i got this to work in the latest astroid. just had to do this: `astroid.parse(open(fp, encoding="utf8").read(), module_name=derive_module_name(fp), path=fp)` as long as the derived module name is correct.... everything worked fine...

for posterity, my crappy module name function was this: ``` def derive_module_name(fp): fp = os.path.splitext(fp)[0] fp = fp.replace("/", ".") fp = fp.replace("\\", ".") return fp ```

Consider using `os.path.join(tempfile.gettempdir(), os.urandom(24).hex())` instead. It's reliable, cross-platform, and the only caveat is that it doesn't work on FAT partitions.

isolating in a venv worked for me, because when you install conan, it goes into scripts/conan.exe, and that shows up first in the path ``` #!/bin/sh python -mvirtualenv venv ....

that looks great. should work to deal with the effect of that policy change