TODO: Difference between revisions

fix punctuation
add more notes to the LUKS article
Line 10: Line 10:
** NOTES:  
** NOTES:  
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are ok. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are ok. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique i've seen is to use random.org , eg `curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random`
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, imo
*** ZFS actually uses an authenticated encryption mode by default (aes-gcm) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS"  is a little less clear than "XTS has vulnerabilities *under certain threat models*, such as A, B and C [imo if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context,,,]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that " zfs and brtfs will help with the corruption issues of xts " they may not have even been talking about luks directly and i just got cornfused ( it was probably wikipedia )
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a noob who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* Templates
* Templates
** user profile information template (need to flesh out how this will look)
** user profile information template (need to flesh out how this will look)