Talk:Data-at-rest encryption

From ArchWiki
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)

Discontinued Windows software

The Windows compatibility row of the comparison table links four discontinued programs (CrossCrypt, FreeOTFE, LibreCrypt and encfs4win).

Should we just remove them as using unmaintained encryption software is a bad idea?

--Larivact (talk) 08:30, 15 July 2018 (UTC)

The same issue can be said about Linux software: see issues of encfs v1.0 and still listing Truecrypt.
I vote for dropping them and move them to a section of unmaintained/possible dangerous solutions.
Francoism (talk) 12:02, 19 November 2018 (UTC)
Quite a few adaptations have been done to mark Truecrypt as outdated. I'd be generally ok with dropping it, but don't see it urgent and would only be wary about losing info (applicable, not yet migrated to Veracrypt). If there was a new software to feature in the table, I'd be for replacing the Truecrypt column. Encfs development slowed for a long time, yes, but is used widely and supported (same applies for ecryptfs).
I'm generally against a section of unmaintained software, particularly stuff not in the official repos. Let's drop those windows programs. --Indigo (talk) 18:10, 19 November 2018 (UTC)
Done [1]. The librecrypt bug tracker appears to be unattended for 1.5 years. Done [2] too. --Indigo (talk) 22:06, 8 January 2019 (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. [3], [4] or even [5]. 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)