4 ms·
I know this is only tangentially related, but when you're bringing up UNIX philosophy... > - Store data in flat text files. Storing encryption keys or the lik
by beefhash 7y ago
I know this is only tangentially related, but when you're bringing up UNIX philosophy...
> - Store data in flat text files.
Storing encryption keys or the like in flat text files is surprisingly hard, at least in C. I don't think it's even possible to use sscanf(3) without unexpected explosions, and otherwise you get to hand-roll your hex parsing code yourself (Base 64? Get yourself a library).
- derekp7 7y ago> - Use software leverage to your advantage. openssl's libcrypt has Base 64 routines in it.
- avar 7y agoThen don't do it the hard way and store something like a password in some general text file that needs to be parsed, just have the password in its own file. This is also good practice when that's otherwise a sane idea because you can apply separate permissions to that password file. Working with that sort of file in C is trivial, you either open() and read() from that file, or mmap() it.
- marcosdumay 7y agoThe GP is probably more focused on textual logs. But yes, C is very weak on converting data from one encoding into another. You end-up always having to write your own encoder/decoder. You should be able to convert between binary and base64 on memory more easily than during IO, and for encryption keys the buffers all have known size limits. As a rule sscanf will add security vulnerabilities to your code, so one should better avoid it if you do not trust your inputs.
- akira2501 7y ago> Storing encryption keys or the like in flat text files is surprisingly hard, at least in C. Storing keys (or other binary) data is _exceptionally_ easy with C. What's hard is _multiplexing_ it with other data in the same file, but you probably don't need to: some.config: keyfile=/some/path/to/just/the/key