Talk:Data-at-rest encryption

From ArchWiki
(Redirected from Talk:Disk Encryption)
Jump to navigation Jump to search

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)

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:
--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)

Was Serpent judged most secure?

According to the fact sheet available from the relevant link (, 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)

Encfs with Windows

I changed the "Encfs works in Microsoft Windows" statement from Yes to No. Had already done that a few years ago.

It is true that some tools exist. I could actually use them (after a lot of time spent to figure it out), but only *sometimes*. The software Safe for Windows (, which uses WebDAV, used to work without administration rights but as today (2020-07-16) it's over-outdated and doesn't work. Other solutions *require by design* that the user have administration rights on Windows. The right links for EncFSMP are and . Actually, with EncFSMP, one might be able to decrypt and copy to a new folder all encrypted data without administration rights but they won't have a filesystem opened because this is the part that requires administration rights.

I tried to use Encfs, simply because I had to share files at home and at work, possibly without any Internet connection and definitely no administration rights at work. IMHO, it's a very common situation: many Archlinux users use Archlinux at home and possibly Windows at work because they don't have a choice. In that case, they most probably don't have administration rights in Windows either. So it seems misleading to just write: "Yes" in the table.

Tétrapyle (talk) 08:23, 16 July 2020 (UTC)