6 ms·

I wrote a library to handle mixed configuration values by using asymmetric RSA encryption [1]. [1]: https://github.com/jacobgreenleaf/greybox https://github.co

I wrote a library to handle mixed configuration values by using asymmetric RSA encryption [1]. [1]: https://github.com/jacobgreenleaf/greybox https://github.com/jacobgreenleaf/greybox

geocar 12y ago
There are lots of problems with this, not the least of which being: • Configuration files can be trivially forged (rsa without signing) • Many configuration files can be trivially decrypted without the key (rsa use on potentially big files) • Keys can be trivially recovered in multiple ways (global variable, ptrace) Users might be tricked into using your library despite the fact it offers them no real security except false security. I recommend placing a warning that it is not intended to be used by anyone at any time.
- tstack 12y ago
  Your criticisms don't seem to make much sense... * Preventing forgery/tampering is an orthogonal issue and can be done by intrusion-detection software. * "trivially decrypted without the key" -- How? The size of the file is not going to make any difference here. * 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. Why don't you make some constructive criticism instead of being obnoxious.
  - geocar 12y ago
    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. This is a job for people who take programming seriously, not amateurs 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 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". 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. > 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.
    - tstack 12y ago
      > 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 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.

I wrote a library to handle mixed configuration values by using asymmetric RSA encryption [1]. [1]: https://github.com/jacobgreenleaf/greybox https://github.com/jacobgreenleaf/greybox

geocar 12y ago

There are lots of problems with this, not the least of which being: • Configuration files can be trivially forged (rsa without signing) • Many configuration files can be trivially decrypted without the key (rsa use on potentially big files) • Keys can be trivially recovered in multiple ways (global variable, ptrace) Users might be tricked into using your library despite the fact it offers them no real security except false security. I recommend placing a warning that it is not intended to be used by anyone at any time.

tstack 12y ago
Your criticisms don't seem to make much sense... * Preventing forgery/tampering is an orthogonal issue and can be done by intrusion-detection software. * "trivially decrypted without the key" -- How? The size of the file is not going to make any difference here. * 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. Why don't you make some constructive criticism instead of being obnoxious.
- geocar 12y ago
  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. This is a job for people who take programming seriously, not amateurs 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 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". 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. > 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.
  - tstack 12y ago
    > 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 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.