> Writing software that may run in a potentially hostile environment should be done with great care, and a thorough analysis of what you are actually protecting against.
The first section of his documentation states what the purpose of the module is and what's it is trying to protect against. The use of RSA there is pretty reasonable, so I don't know why you're being so hard on him. It also talks about how this project is a variation on another project, so it's not like he is going off half-cocked and implementing something crazy.
> This is a job for people who take programming seriously, not amateurs
Everyone starts out as an amateur. You can either be an internet know-it-all that wants to show off how little you know or you can provide constructive feedback.
> who can't be bothered to read the documentation of the modules they are using, e.g. http://stuvel.eu/files/python-rsa-doc/usage.html
> Note especially the bits about signing RSA, and how to use it to encrypt files. Doing raw RSA on strings longer than 245 bytes is unwise, and inventing new protocols for RSA is unwise. That the author does these things is strong evidence that the author is not demonstrating "great care".
Did you bother to read the documentation yourself? It directly talks about encrypting large files. Yes, it's true that trying to encrypt more data than is supported for a key size will leak information, which is why implementations throw an error if you try to do that. The usage documentation you pointed to discusses that and provides options to cope with it. But, in this case, he is not even encrypting the whole file, just the values of certain properties, which are probably going to be small enough to not require any extra measures.
And, again, what does signing have to do with how RSA is being used in greybox?
> If the author believes forgery/tampering is orthogonal and/or protection from in-process attacks, then the author should state that. That's part of the analysis step.
They did state the scope of the project and there is really no need for them to go into deep detail about deployment. Are you going to criticize him for not pointing out that the whole system needs to be secured from tampering? Of course not, so stop acting like a douchebag.
>> Of course, the key can be recovered if you have the ability to ptrace. What's your point? That's going to be true of any solution out there.
> Nonsense. If you delete the key from memory, it is obvious that someone cannot use ptrace to recover it afterwards. Detailing what is at risk, and what is not at risk is part of the analysis step.
You have to ask, where did the key come from in the first place? The private key file has to exist somewhere that is accessible on the box so that the process can read it in the first place. If someone has ptrace, they can probably read a file as well.
Ultimately, it's about the level of risk people are willing to live with. For what greybox seems targeted at, it's encrypting properties in files that are committed to a repo and then using a private key that is only available on certain machines to read that property. For some use cases, that is probably a perfectly fine level of security and better than what is being done in some cases anyways.