Difference between revisions of "Talk:Disk encryption"

From ArchWiki
Jump to: navigation, search
(Multithreading support)
(Multithreading support: re)
Line 104: Line 104:
 
:::: My knowledge on that matter is far too basic to be able to write extensive tips about that. As for (1) I would have to test and report back here. I agree that the table should provide comparable results. In the case TC does true multithreading one would possibly have to adjust the other marks as there seem to be two different notions about multithreading here. (2) Yes, maybe I wasn't clear on that. I want to include the issue on the respective dm-crypt page. With the new layout I am not sure it would fit into the Specialties page. Most pages here have a Troubleshooting section and I thought of adding there something like "dm-crypt only utilizes one core and IO is slow" and then explain the issue and possibly present the dm-crypt kernel patch (https://people.redhat.com/mpatocka/patches/kernel/dm-crypt-paralelizace/current/). I applied that for me and it worked for the most part very well. However, since dm-crypt is now restructured I would have to find an appropriate place for it. As for (3) as stated above, I don't have enough knowledge to give out recommendations on that subject, so I would leave that to those who know what they are talking about :). My simple goal is to get this information somewhere so I can save other people the time of searching through the mailing list.  
 
:::: My knowledge on that matter is far too basic to be able to write extensive tips about that. As for (1) I would have to test and report back here. I agree that the table should provide comparable results. In the case TC does true multithreading one would possibly have to adjust the other marks as there seem to be two different notions about multithreading here. (2) Yes, maybe I wasn't clear on that. I want to include the issue on the respective dm-crypt page. With the new layout I am not sure it would fit into the Specialties page. Most pages here have a Troubleshooting section and I thought of adding there something like "dm-crypt only utilizes one core and IO is slow" and then explain the issue and possibly present the dm-crypt kernel patch (https://people.redhat.com/mpatocka/patches/kernel/dm-crypt-paralelizace/current/). I applied that for me and it worked for the most part very well. However, since dm-crypt is now restructured I would have to find an appropriate place for it. As for (3) as stated above, I don't have enough knowledge to give out recommendations on that subject, so I would leave that to those who know what they are talking about :). My simple goal is to get this information somewhere so I can save other people the time of searching through the mailing list.  
 
:::: --[[User:Javex|Javex]] ([[User talk:Javex|talk]]) 11:23, 1 February 2014 (UTC)
 
:::: --[[User:Javex|Javex]] ([[User talk:Javex|talk]]) 11:23, 1 February 2014 (UTC)
 +
::::: Remark to (2): If you have gathered positive experience with the patches proposed by Milan, explaining in which usecase and how to utilize those would imo fit very well in the "Specialties" subpage. Start a talk on the dm-crypt subpage where you feel it more appropriate, if you like. But keep in mind the special usecase you apply and we cover usage of the generic packages. Remark to (3): Don't play your experiences down; this wiki is super because of the collaboration taking place. Yet I agree the "performance" page will probably be frequented by users who solder devices like notebooks with raid0 SSDs .. so it is off-topic there to cover the patches. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:01, 1 February 2014 (UTC)

Revision as of 16:01, 1 February 2014

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)

Proposed renaming of this article to "System Encryption" or "Encryption"

This was proposed by Kynikos in the form of a template added to this article, and also discussed here.

I disagree with the proposal, and still believe that "Disk Encryption" is the right name for this article. Let me try to explain why.

"Encryption" is a huge topic, encompassing a much bigger scope than this article could sensibly cover in the level of detail set out by the content I already added here, and the content that is to be merged here from System_Encryption_with_LUKS. There is (among others)...

  • manual encryption of pieces of data (no matter where it comes from / is stored / is going to)
    • GnuPG, ...
  • cryptographically protecting a communication channel
    • HTTPS, SSH, ...
  • cryptographically protecting a logical part of a storage disk (real or virtual)
    • Loop-AES, dm-crypt+LUKS, Truecrypt, eCryptfs, EncFs, ...

I believe that the article should exclusively deal with the latter topic. Trust me, there's enough valuable information on this to fill a whole article (just look at how big the comparison table alone grew already). It would only add confusion and result in TL;DR to mix other encryption-related topics into the same article.

I.e., the article should exclusively be about techniques which will cause all data written to a logical part of a disk to be automatically encrypted, and data read from it to be automatically decrypted.

All of the following are examples of logical parts of (real or virtual) storage disks:

  • a whole disk
  • a partition (or anything else represented as a block device)
  • a folder

So I don't see how the term "Disk Encryption" should be inclusive of block device encryption, but not of filesystem-level encryption, as Kynikos suggested in the renaming-proposal. The level at which the protected logical part of the disc is defined, is an just implementation detail - I don't see a conceptual difference there.

So that's why I believe "Disk Encryption" is a more sensible title than "Encryption".

Regarding "System Encryption", I believe that would actually not be inclusive enough of everything encompassed by the encryption methods described here.

In my mind, system encryption is a potential application of disk encryption - it's about securing the "system" itself (as in, an Arch Linux installation) from unauthorized access to its system and user data while the system is not running.

But disk encryption can also be used for simple data encryption, e.g. protecting a partition or folder in which confidential data files are to be stored, and letting the user unlock/lock the encrypted data container on demand or on login/logout. This has nothing to do with the "system" and whether it is running. (This is especially the case for the filesystem-based disk encryption methods.)

And of course there are many possible combinations and shades of grey in between.

"Disk encryption", to my ears at least, captures all of that quite nicely.

--Sas (talk) 18:37, 17 June 2012 (UTC)

Wow, you provided such an exhaustive argumentation in support of the current title that I don't think anyone will try to reply (including me) :) Let's stick with Disk Encryption then! It's worth to be noted that Wikipedia itself is a bit ambiguous in finding a consistent naming for this topic, see for example the intro of wikipedia:Filesystem-level encryption ("Filesystem-level encryption, often called file or folder encryption, is a form of disk encryption [...]") versus wikipedia:Disk encryption#Disk encryption vs. filesystem-level encryption. -- Kynikos (talk) 21:10, 19 June 2012 (UTC)

Proposed expansion for dm-crypt without LUKS

Hi, I want to gather quick feedback regarding the addition of [Plain_dm-crypt_without_LUKS]. The addition to Disk_Encryption#Block_device_encryption is swift. After that comes the sophisticated comparison table. Question for that is: Do we need to add an extra column for plain dm-crypt? A major disadvantage is the complexity of the table width. Now it scales great with the browser window; adding it as a separate column does not make that better. Further, the column should not be needed, because the original author gladly already mentioned when the LUKS extension is intrinsic for gaining a dm-crypt feature (e.g. Key salting states "Yes (with LUKS)"). So, in order not to complicate things, I would propose to just rename the column heading to "dm-crypt +/- LUKS" and reviewing the appropriate distinctions in the table are made. Ok?

Certain other features of plain dm-crypt may be added to the following text sections starting from Disk_Encryption#Preparation too, e.g. the dis-/advantages of the absence of a crypt header, but those are all free-text and can be expanded as required. --Indigo (talk) 07:42, 29 August 2013 (UTC)

Just renaming the column heading sounds reasonable, go for it! -- Kynikos (talk) 03:34, 31 August 2013 (UTC)
Done. Thanks, also for reviewing! closing this. I'll return later. I think next it would be great to phrase and link the setup examples in Disk_Encryption#Choosing_a_setup to the howtos again done. Next parts that should get edited are Disk_Encryption#Basic_principle by adding a differentiation between a plain and a master key. Disk_Encryption#Keys.2C_keyfiles_and_passphrases should be split up into the basics about passphrases/keyfiles and the rest (diagrams explaining key-derivation, master key, salting, etc.). The later may be better put into Disk_Encryption#Cryptographic_metadata and perhaps Disk_Encryption#Data_integrity.2Fauthenticity. For the connection to Disk_Encryption#Keys.2C_keyfiles_and_passphrases those two should be moved atop Disk_Encryption#Ciphers_and_modes_of_operation. On the way, plain can be mentioned too as an example again against the others with encrypted master keys, headers or key-sigs. One point I am unsure about is to keep Disk_Encryption#Data_integrity.2Fauthenticity. It could also be mentioned briefly in Disk_Encryption#Basic_principle. Won't that not be enough? --Indigo (talk) 20:02, 4 September 2013 (UTC)
I think it's perfectly fine if you mention Disk_Encryption#Data_integrity.2Fauthenticity into Disk_Encryption#Basic_principle or Disk_Encryption#How the encryption works. Also Disk_Encryption#Plausible deniability has a good article on Wikipedia:Plausible deniability, we could, and probably should, just link there. -- Kynikos (talk) 10:28, 8 September 2013 (UTC)
+1 on should (good one indeed; yes, we can). I have re-shuffled those sections and added references to plain mode. In fact we now mention it all the way through the article. Have a look sometime please, if we can close this and the expansion tag can be purged. --Indigo (talk) 19:21, 12 September 2013 (UTC)
Wonderful job Indigo! I'll leave the final tasks of removing the Exp tag and closing this discussion to you ;) Thank you -- Kynikos (talk) 02:23, 14 September 2013 (UTC)
Thanks! On to new endeavours. Closing. --Indigo (talk) 11:29, 14 September 2013 (UTC)

Multithreading support

Looking at the performance section, multithreading support is claimed for dm-crypt and TC. However, particularly for dm-crypt, in my opinion this is no real multithreading support (or at least, I think, it should be defined below the table).

My understanding of multithreading would be, that for a single IO task (e.g. copying files), read and write tasks are spread over multiple threads thus allowing it to reach multiple cores. For example, if my CPU is capable of encrypting AES with 100 MB/s, then my 8 core CPU should reach 800 MB/s.

The reality is different: Each IO task gets a single thread, but starting more than one of these, each will run on a different thread. I guess the reference linked in the article refers to an entry that creates this exact feature: Instead of every IO task having to go through the same encryption thread, each gets their own. But for each, only one is spawned nonetheless.

For me, this distinction leads to a performance loss of a factor of 5, having a 500MB/s SSD but only being capable of de-/encrypting at 100MB/s. I spent a lot of time wondering why this was so slow because I understood the notion of multithreading differently. Maybe we should clarify this? I don't want to go ahead and just add something before not hearing other opinions.

--Javex (talk) 17:40, 19 January 2014 (UTC)

+1. In order not to make the table overly complicated, you could put the green tick in brackets and add some explanation and/or references to the already existing footnote 8, e.g. this The topic comes up frequently on the mailing list, I remember one last Nov/Dec. Regarding comparability, I don't know if TC does it better.
--Indigo (talk) 22:32, 19 January 2014 (UTC)
I have thought about doing it this way but I'd much rather have some space to explain the issue. Now the question is where to do that? Maybe on the dm-crypt page? Open a new section, e.g. in troubleshooting and then discuss the issue there and link to it (this could then be done with a bracket referencing that particular section). What do you guys think?
--Javex (talk) 22:42, 31 January 2014 (UTC)
If you ask me: (1) The table row on this page should represent comparable results. So, does TC it better? (2) you could add external links to the footnote and once it is properly discussed on the respective wiki pages here, you can simply replace the links. Adding a troubleshooting section on this page goes too far, yes. It should be included on the respective tools pages. (3) For dm-crypt there is multithreading, but how effective it is depends on drive layout and what type of io is fed through the encryption. If you want to draft a section on it, I would find dm-crypt/Specialties most appropriate (we have moved the SSD trim section to that subpage too). If your discussion has more general partitioning recommendations (i.e. maximising encrypted mappers for performance), maybe better a new section in Performance#Device_layout and a cross-link from Dm-crypt/Drive_Preparation#Partitioning.
--Indigo (talk) 10:41, 1 February 2014 (UTC)
My knowledge on that matter is far too basic to be able to write extensive tips about that. As for (1) I would have to test and report back here. I agree that the table should provide comparable results. In the case TC does true multithreading one would possibly have to adjust the other marks as there seem to be two different notions about multithreading here. (2) Yes, maybe I wasn't clear on that. I want to include the issue on the respective dm-crypt page. With the new layout I am not sure it would fit into the Specialties page. Most pages here have a Troubleshooting section and I thought of adding there something like "dm-crypt only utilizes one core and IO is slow" and then explain the issue and possibly present the dm-crypt kernel patch (https://people.redhat.com/mpatocka/patches/kernel/dm-crypt-paralelizace/current/). I applied that for me and it worked for the most part very well. However, since dm-crypt is now restructured I would have to find an appropriate place for it. As for (3) as stated above, I don't have enough knowledge to give out recommendations on that subject, so I would leave that to those who know what they are talking about :). My simple goal is to get this information somewhere so I can save other people the time of searching through the mailing list.
--Javex (talk) 11:23, 1 February 2014 (UTC)
Remark to (2): If you have gathered positive experience with the patches proposed by Milan, explaining in which usecase and how to utilize those would imo fit very well in the "Specialties" subpage. Start a talk on the dm-crypt subpage where you feel it more appropriate, if you like. But keep in mind the special usecase you apply and we cover usage of the generic packages. Remark to (3): Don't play your experiences down; this wiki is super because of the collaboration taking place. Yet I agree the "performance" page will probably be frequented by users who solder devices like notebooks with raid0 SSDs .. so it is off-topic there to cover the patches. --Indigo (talk) 16:01, 1 February 2014 (UTC)