Jeśli nie masz specjalnych wymagań, po prostu przy użyciu malloc jest rozsądne podejście. Ma tę zaletę, że valgrind i podobne mogą przechwytywać błędy użytkowania, które są jednym z głównych sposobów powstawania typów luk, na które możesz się martwić. Jak pokazało nam fiasko OpenSSL, próba zrobienia czegoś wymyślnego i spartaczenia jest dużym ryzykiem.
Jeśli masz bardziej wymagające wymagania, to naprawdę wiele zależy od twojego przypadku użycia. Zakładam, że twoje klucze są przejściowe, albo unikanie przechowywania ich na dysku nie ma większego sensu. Oto moje polecane zmniejszania zagrożenia dla poszczególnych ryzyk:
Zamiana na dysku: Jeśli Twój system wymaga zabezpieczenia przed atakami fizycznymi, nie powinno mieć w ogóle zamianę. Indywidualna próba ochrony określonych danych za pomocą mlock jest czymś w rodzaju żartu. Po prostu włącz swap off i zainstaluj wystarczającą ilość pamięci, a to nie jest problem. mlock należy uważać za funkcję planowania w czasie rzeczywistym, a nie funkcję zabezpieczeń.
heartbleed-podobne kwestie, umiarkowany Obrona: Przydzielanie pamięci poprzez mmap ze strony straży po obu stronach: po pierwsze mmap 2 stron więcej niż trzeba, wszystkie z PROT_NONE, a następnie użyć mprotect zrobić wszystko, ale pierwszej i ostatniej strony PROT_READ|PROT_WRITE. Uwolnij go za pomocą munmap, gdy tylko skończysz.
Problemy z Heartbleed, silna obrona: Rozwiąż proces potomny, aby wykonać całą kryptografię.
Przy okazji, jaki szyfr używasz, gdy klucze 256-bitowe oferują jakiekolwiek zabezpieczenia? –
@R .. Nowoczesne szyfry symetryczne (jak AES)? Duże rozmiary, takie jak 4096-bit, są przeznaczone dla algorytmów asymetrycznych, takich jak RSA. –
OP powiedział "klucze prywatne", więc założyłem krypto z kluczem publicznym, ale być może intencją było po prostu "klucze, które muszą być prywatne". –