Talk:Data-at-rest encryption
Add filesystem encryption
It is possible to use encryption offered by filesystems, instead of using something like dm-crypt and eCryptfs. In most cases they are even better because they offer more flexibility, performance and without the need of something like FUSE (but that's not part of this scope).
Should we extend the table listing encryption solutions or simple link to the filesystem page instead?
Francoism (talk) 11:53, 19 November 2018 (UTC)
- Agree. The comparison table mentioned fscrypt; as far as I know, bcachefs also natively support encryption. I’m not sure about the advantages, though; there are some tests claiming that LUKS is actually faster overall (a little slower write, much faster read). Franklin Yu (talk) 07:59, 4 May 2024 (UTC)
- While bcachefs is an exciting candidate, I'd still give it time before it's added. It's doc points to open todos and testing/fixing enc is still very active (and mainly focussed on chacha, not AES-GCM), to name two reasons. As of today my choice would be ext4 (#Add EXT4 transparent folder encryption) to add. A re-grouping of methods (block devices, then filesystems before FUSE) may be useful. --Indigo (talk) 18:48, 11 December 2024 (UTC)
Add EXT4 transparent folder encryption
-- EXT4 has also a transparent folder-based encrption implemented!
Nonie689 (talk) 13:31, 22 June 2022 (UTC)
Unicode graphs/patterns
[Original title was Ascii graphs/patterns]
Hi, A small issue unrelated topic : how are ascii graphs/patterns made?
- One method I know is: http://www.asciiflow.com/#Draw
- --Indigo (talk) 20:45, 3 September 2013 (UTC)
- Note that those graphs are not made with simple ASCII characters, but Unicode (I've fixed the title of the discussion).
- Anyway, this is a very interesting question indeed, I too would like to know if there are any editors that can make it easy to draw such diagrams.
- This would also solve Talk:Installing Arch Linux with EVMS#Image replacement contest.
- Finally, an editor like that should be mentioned in Help:Style#Non-pertinent content.
- -- Kynikos (talk) 05:47, 4 September 2013 (UTC)
- I created these diagrams manually using Kate, which is a normal text editor (but it has an advanced feature called "Block Selection Mode" that helps a lot with this kind of stuff). I also kept a window of gucharmap open on one side of the screen, which allowed me to easily find and pick suitable Unicode characters.
- --Sas (talk) 19:21, 19 November 2013 (UTC)
Move out of User page
This page is quite good IMO. So it can be moved to a normal page. It can receive updates there and other pepole can contribute. -- Fengchao (talk) 06:20, 11 June 2012 (UTC)
- +1 -- Kynikos (talk) 09:18, 12 June 2012 (UTC)
- No respons from author. This will block [System_Encryption_with_LUKS] restructure so I do the job to move on.-- Fengchao (talk) 02:22, 15 June 2012 (UTC)
- Hi, and sorry for abandoning this article half-way through and then forgetting about it.
- As for writing the general introduction/explanation text (part of which consists of merging the corresponding sections from the System_Encryption_with_LUKS article into this one), I had already started working on that locally back when I created this article, but I have that file on a different computer than I am on now. If you give me until tomorrow (Monday) evening (European time), I'll bring what I have into a readable state and upload it to this page, and then everybody can help modifying/extending it.
- The reason why I created the article as a user page and didn't move it into the main namespace right away, is that I originally planned to first discuss some feature requests with the wiki maintainers which would make the page more maintainable (without sacrificing user-friendliness). Namely, support for automatically numbered footnotes, and moving the comparison table formatting into a wiki-wide "comparison-table" CSS class (or maybe, separate "comparison-table-vertical" and "comparison-table-horizontal" classes). Right now, the comparison table's wiki markup is so messy and difficult to work with that I would feel guilty asking other people to help add info to it. --Sas (talk) 17:35, 17 June 2012 (UTC)
- I added the main text sections now. It would be great if a native speaker with good language skills could do some copyediting for the individual subsections to formulate them more concisely and make them nicer to read. --Sas (talk) 20:42, 18 June 2012 (UTC)
- Hi Sas, thank you for getting back working on this article!!
- About the numbered footnotes, that would require the installation of an extension (involving web developers) and if we can keep it simpler instead it'd be better, since this would be the only article using that feature.
- About the comparison-table class, can you report an existing example (in another wiki I guess) of what you mean exactly?
- -- Kynikos (talk) 20:57, 19 June 2012 (UTC)
- I added the main text sections now. It would be great if a native speaker with good language skills could do some copyediting for the individual subsections to formulate them more concisely and make them nicer to read. --Sas (talk) 20:42, 18 June 2012 (UTC)
Was Serpent judged most secure?
According to the fact sheet available from the relevant link (https://web.archive.org/web/20020211162045/http://csrc.nist.gov:80/encryption/aes/round2/aesfact.html), Serpent was not the finalist selected for the relevant standard. According to that fact sheet, the judgement was not that the other finalists (including Serpent) were insecure, but claiming it was judged the most secure seems unmotivated. Have I missed something? What's the source for this? The linked papers are by the researchers who proposed Serpent, aren't they? That's not the judgement of impartial evaluators. --cfr (talk) 05:03, 4 November 2017 (UTC)
About hardware-based full disk encryption
There's a line stating
"The best remedy might be hardware-based full disk encryption and Trusted Computing."
As it became known over the last few years, disk-based encryption is often either weak, broken or vulnerable to other attaks, like altering the firmware.
So the Arch Wiki recommends a propritary solution, which (from the vendors point of view) must be as cheap and fast as possible.
Should the statement be altered or a warning added?
Baerbeisser (talk) 15:23, 27 July 2019 (UTC)
- About hardware-based FDE, there's already Self-Encrypting Drives#Disadvantages, I think we can expand that if needed.
- About Wikipedia:Trusted Computing, I think the Wikipedia article is a bit biased actually, "trusted computing" may be a term originally suggested by the Trusted Computing Group, but to me it has a more generic meaning, and the TCG technology is only an implementation of the idea (although basically the only one in practice), see e.g. [1], [2] or even [3]. Since we don't link to a specific TC vendor site, and we already say "The best remedy might be ..." (not is), I think the Wikipedia article already does a decent job at following up by introducing the possible flaws of the technology, but perhaps we could link to a more neutral external page, or Wikipedia:trusted systems?
- -- Kynikos (talk) 07:14, 28 July 2019 (UTC)
File encryption
I think it is a good idea to include some file encryption methods. It is useful for some cases like sharing files and backup important data on a friend's computer. | Huupoke12 (talk) 14:17, 7 July 2020 (UTC)
- What do you propose more specifically? -- Kynikos (talk) 02:58, 12 July 2020 (UTC)
- I propose using 7z with -p flag to set the password which also encrypt it. | Huupoke12 (talk) 08:29, 14 July 2020 (UTC)
- That's already mentioned in p7zip.
- Mentioning manual encryption/decryption of single files in this article would contradict the introduction in the first place, which currently limits the scope to on-the-fly encryption, so a much broader restructuring would be needed.
- Maybe Security#Data-at-rest encryption is a better place to mention manual single-file encryption?
- -- Kynikos (talk) 23:57, 14 July 2020 (UTC)
- I went on a quest and found Special:diff/705490. Closing. --Indigo (talk) 18:26, 11 December 2024 (UTC)
Remove deprecated encryptions
Like TrueCrypt and encfs which are deprecated and halted. The TrueCrypt page is archived... --Tiziodcaio (talk) 23:54, 17 July 2022 (UTC)
- Yes, others have thankfully replaced Truecrypt with VeraCrypt already, as well as added filesystem alternatives for Encfs to the tables.
- Perhaps, the table columns for enfcs can be removed in one edit. This would make it easier to re-add, in case it's version 2[4] does land. --Indigo (talk) 20:44, 1 March 2024 (UTC)
- encfs moved to unmaintained status meanwhile. So, it's a candidate to remove in my opinion. --Indigo (talk) 18:38, 11 December 2024 (UTC)
rclone
rclone may also be a good option (with rclone crypt + rclone mount). Coolwanglu (talk) 22:12, 3 October 2022 (UTC)
Move the page to "Encryption"
I think the page should be more generally oriented, maybe naming it with a more general name and moving all the thing truly related with Data-at-rest encryption to a subpage near to File system encryption on other page
--Tiziodcaio (talk) 16:49, 21 February 2023 (UTC)
- The Category:Encryption contains different topics and this article heads its subcat Category:Data-at-rest encryption. It is a generally used term, see wikipedia:Data at rest. "File system encryption" is more ambigious in my view (see zfs encryption as an example). --Indigo (talk) 21:56, 22 February 2023 (UTC)