rns.recipes

The static from_bytes(prv_bytes) function has a big warning that says HAZARD! Never use this to generate a new key by feeding random data in prv_bytes. Is this simply because it’s not the intended way of doing it and you don’t know where someone might get their random data from, or does Reticulum have a way of generating identities that is somehow more secure than cat /dev/urandom | xxd -ps -l 64? And what if I’ve memorised 16 bytes I got from /dev/urandom, would hashing those with sha512 be a secure way of creating an identity that I can easily take with me anywhere I go without needing to store it on a USB or other storage device?

Also, have you ever thought about adding a way to keep identities encrypted on disk and only decrypt them in memory when needed? For example, if I have an rnsh identity it should be encrypted on disk, and then when I try to use it rnsh will detect that it’s encrypted and ask for the password. This way the unencrypted identity will only be stored in memory for the duration of the rnsh session, and if someone grabs the computer out of my hands after I’ve finished they won’t be able to get the identity, even if the computer is still unlocked or doesn’t have FDE. Such a feature could of course be implemented by application developers, but if different applications use different encryption algorithms or formats for encrypted identities then one application may not be able to use an identity that was encrypted by another application, so maybe it would make sense to include it in the stack itself so it becomes more standardised?

So I did some googling and it seems I’ve found answers for my 1st 2 questions. Apparently, in order for X25519 keys to be secure they have to go through a clamping process that consists of clearing a few bits and setting one. So then all I need to do to generate a key that is as secure as any other reticulum identity is:

seed = os.urandom(16)
key = bytearray(hashlib.sha512(seed).digest())
key[0] &= 248
key[31] &= 127
key[31] |= 64
key = bytes(key)

However, the public key for this identity is the same as the public key for:

key = hashlib.sha512(seed).digest()

So I’m guessing the functions used by RNS automatically clamp X25519 keys if they aren’t already clamped. So does that mean the warning isn’t necessary, it can just be safely ignored because whatever random data is provided will just be forcibly made into a secure key?