Talk:Protecting Memory Secrets: Difference between revisions
Content added Content deleted
EnigmaticC (talk | contribs) (Created page with "== Draft Status == Despite the wording in some of the standards which may sound overly prescriptive, I expect the intent is not to ban the use of popular languages from use. As such I expect that the requirements will evolve. This is an attempt to step back from some of the wording to look at the risks and a broader set of options to meet the objective. This task should evoke a healthy constructive discussion. As such, I don't see this as cast in stone. == Motivation...") |
(→Perhaps missing the point: new section) |
||
| Line 42: | Line 42: | ||
* [https://www.chef.io/chefconf-keynotes/secrets-management-in-complex-environments-at-scale scaling secrets management] |
* [https://www.chef.io/chefconf-keynotes/secrets-management-in-complex-environments-at-scale scaling secrets management] |
||
* [https://lwn.net/Articles/804658/ LWN Keeping memory contents secret]] |
* [https://lwn.net/Articles/804658/ LWN Keeping memory contents secret]] |
||
== Perhaps missing the point == |
|||
This is sort of like trying to close the barn door while the horse is walking through it. |
|||
Proper protection for "memory secrets" has to be viable outside of the machine. |
|||
In other words, secrets need to be mixed in with garbage such that a snoop has a high probability of picking up plausible looking garbage when looking for secrets. |
|||
Worse, from a rosettacode point of view, the fact that there is no "task" here, means that there's no way for us to compare implementations, let along judge the viability of any claims about implementations for the general case. (We might judge in the context of specific machines, but without intimate knowledge of the machine architecture we'll have difficulty even there.) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 03:31, 13 January 2023 (UTC) |
|||