You are not logged in.

#1 2013-07-01 20:13:06

root
Member
From: 127.0.0.1
Registered: 2012-04-13
Posts: 297

Encryption vs performance

As a laptop user I have always felt attracted by the use of encryption but as the laptop I am using is quite old (T23 - 1.13 Ghz / 256 RAM) I wonder if the gain of security would come at a too high price in terms of performance.

Someone has used or is using encryption for a similar (or old in general) laptop and can share his/her experience in terms of gain/loss?

Thanks in advance for any input.


\(o_X)/
                        'Cause I wanna be an Archy - An Archy in the UK // Sex Pistols

Offline

#2 2013-07-01 22:10:50

R00KIE
Forum Moderator
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 3,282

Re: Encryption vs performance

If you have some free space on the HD then create a test partition there and check for yourself.

First test read/write speed (maybe with dd, use a big file when compared with the amount of ram you have) without encryption and then after encrypting the partition.

It may be that the limiting factor is your HD speed, or your cpu may be slow enough to be the limiting factor. What you'll notice for sure is that your cpu has to work a lot harder when you care copying (big) files around.


R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

#3 2013-07-02 18:04:17

Vedexent
Member
Registered: 2013-06-27
Posts: 6

Re: Encryption vs performance

Typically, the "overhead" of encryption is minimal. Mathematically - so long as you have the key - there's not a lot of intensive computation (it's cryptanalysis when you don't have the key that requires supercomputing).

I agree that experimenting is a good idea.

Offline

#4 2013-07-02 18:26:01

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 13,140

Re: Encryption vs performance

Vedexent wrote:

Typically, the "overhead" of encryption is minimal. Mathematically - so long as you have the key - there's not a lot of intensive computation (it's cryptanalysis when you don't have the key that requires supercomputing).

Yes, and no.

Encryption:
DES is not too bad in terms of performance.  3DES can take a bit longer.
AES can be very fast; especially as it lends itself to hardware acceleration.
Asymmetrical (RSA) public key techniques are very processor intensive -- that is why they are only used for small blocks.

As to Hashes:
MD5: Fast, not overly strong
SHA-1 : not as fast and compromised
SHA-2 : Takes a while,  still considered secure.

It boils down to -- how strong does your encryption need to be?


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence.  You must not work with the public much. -- Trilby
----
How to Ask Questions the Smart Way

Offline

#5 2013-07-02 18:37:59

alphaniner
Member
From: Ancapistan
Registered: 2010-07-12
Posts: 2,725

Re: Encryption vs performance

ewaller wrote:

SHA-1 : not as fast and compromised

not as fast and not as compromised
or
not as fast; compromised

Apologies for pedantry. I assume it's the latter but you know what they say about assumptions...


But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner

Offline

#6 2013-07-02 18:39:40

drcouzelis
Member
From: Connecticut, USA
Registered: 2009-11-09
Posts: 3,497
Website

Re: Encryption vs performance

Also, you may not need to encrypt the entire thing. If you only have 5 GB of what you would consider "sensitive data" then you could just make a 5 GB TrueCrypt volume.

If someone steals your laptop, they might not care about the 10 GB of pictures and 30 GB of movies...

Offline

#7 2013-07-02 18:54:21

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 13,140

Re: Encryption vs performance

alphaniner wrote:

[not as fast and not as compromised
or
not as fast; compromised

Apologies for pedantry. I assume it's the latter but you know what they say about assumptions...

Point taken.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence.  You must not work with the public much. -- Trilby
----
How to Ask Questions the Smart Way

Offline

#8 2013-07-02 21:14:09

root
Member
From: 127.0.0.1
Registered: 2012-04-13
Posts: 297

Re: Encryption vs performance

Thanks for all the feedback.

@ROOKIE

Unfortunately no room for testing. The hdd is quite small (30 Gb) and when I installed Arch I decided to squeeze the most out of it (100M (boot)/ 512M (swap)/ 20G (root)/ rest (home)).

Though to some extent I think that the hdd could actually be a bottleneck. I have run the command recommended in the Wiki to know the read speed,

hdparm -t --direct /dev/sda

And the result that came out was around 14,25 Mb/s.

As for the write speed, after copying 599 MB of data (again following the Wiki suggestion) the result that came out was 12,6 MB/s.

@Vedexent

I agree that sooner or later it will end up in comparing state of security vs state of satisfaction as to how the system is performing. But if someone can offer some 'ahead' info I would sincerely appreciate it.

@ewaller

I presume that the encryption level should at least provide a decent amount of security. Of course, I am aware (especially taking into account the info of the hdd) that in the end there may be a need for a good balance between performance and security. Knowing that the loss of (hopefully minimal) performance reverts in a good security. But even if performance takes the upper hand the security should still be considered decent.

@drcouzelis

An interesting idea. I may consider it as a 'security container' alternative if in the end the encryption process (all > home + swap > swap etc.) is not possible with a satisfactory performance result.


\(o_X)/
                        'Cause I wanna be an Archy - An Archy in the UK // Sex Pistols

Offline

#9 2013-07-02 22:05:32

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 13,140

Re: Encryption vs performance

root wrote:

I presume that the encryption level should at least provide a decent amount of security.

There is a saying that data are only safe as long their value is less than the cost of obtaining them. 

I guess you need to put a value on the data;  Are they banking credentials? Something that might be embarrassing? Something that an adversary wants?
Also, against whom are you protecting the data?  Someone looking to fence your laptop? Someone trying to steal your identity? Your spouse's lawyer? A government?

Depending on the answers, a 56 bit symmetric key strength might be fine.  OTOH, some things might want 192 or 256 bits.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence.  You must not work with the public much. -- Trilby
----
How to Ask Questions the Smart Way

Offline

#10 2013-07-02 22:13:19

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: Encryption vs performance

Now that you got an idea about the disk "speed", you can use

cryptsetup benchmark

which will you give an idea about crypto performance for the cpu (it runs in ram; not taking into account disk i/o). You will see that the results for the ciphers available in the kernel do indeed vary depending on cpu/32/64 bit So it is worthwile checking that, Still, my experience is similar to Vedexent's; the perceived performance overhead of reasonable disk encryption is often negligible.

Offline

#11 2013-07-04 19:54:02

root
Member
From: 127.0.0.1
Registered: 2012-04-13
Posts: 297

Re: Encryption vs performance

@ewaller

Even if one has nothing to hide, it is always a good idea to ask for the warrant wink

I presume that in these days where, especially online for better or worse, most of the stuff is shared it would sound strange that someone, in this case me, puts a high value on his own or that of others stuff and doesn't see the need to share it with anyone who is not allowed to do so.

And that would apply to both the ones that would have granted access to the laptop/any other computer meant to be used (f.e. using the tool drcouzelis suggested) or , and especially, those who do not (laptop loss/robbery).

For some this may sound like paranoia but it is just that I value my privacy.

@Strike0

Thanks for this benchmark tip.
I presume that on the basis of the disk speed noted in my earlier posts the next step would be to find the 'equivalent pair' in the benchmark results?
If so, it seems that the serpent ones are the closest to the disk speed capacities.
As for the performance I presume it is too related to the hardware used. Though, as you state, the second step is to figure out the 'reasonable disk encryption' part.


\(o_X)/
                        'Cause I wanna be an Archy - An Archy in the UK // Sex Pistols

Offline

#12 2013-07-04 20:25:30

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 13,140

Re: Encryption vs performance

root wrote:

@ewaller

Even if one has nothing to hide, it is always a good idea to ask for the warrant wink

I presume that in these days where, especially online for better or worse, most of the stuff is shared it would sound strange that someone, in this case me, puts a high value on his own or that of others stuff and doesn't see the need to share it with anyone who is not allowed to do so.

To put things in perspective, I design microprocessor based cryptographic machines that read your credit card information and obtain your PIN when you buy something with a bank card.  We assume that bad guys have physical access and that any computer we connect to is compromised.  Let's just say we use aggressive cryptography and go to extreme measures to protect the cryptographuc keys.  It makes me sad when I see corporate giants attempt to use the same techniques to lock down consumer equipment.


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence.  You must not work with the public much. -- Trilby
----
How to Ask Questions the Smart Way

Offline

#13 2013-07-04 21:02:19

fledermann
Member
From: Bielefeld, Germany
Registered: 2013-06-24
Posts: 34

Re: Encryption vs performance

Generally speaking, I'd say that an enceypted filesystem does not cause a real, noticeable slowdown. I used completetly encrypted hdd on a similar setup (it had 512MiB RAM) and it worked fine.
But it also depends on what you're using you computer for.
'

Offline

#14 2013-07-05 17:25:59

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: Encryption vs performance

root wrote:

And that would apply to both the ones that would have granted access to the laptop/any other computer meant to be used (f.e. using the tool drcouzelis suggested) or , and especially, those who do not (laptop loss/robbery).

If you _really_ deem it necessary to protect your machine (system and data) against both of those, then one of the methods discussed here will not be enough but you have to combine them (and use even more measures, depending on your needs. All you deem necessary will either have performance or convenience impacts. So you might want to answer the questions ewaller asked above more to the point (to yourself or here for others to comment). In order to figure out your requirement for a reasonable level of protection that is necessary. Take the wiki as guidance, it discusses it well (but is imho maybe a bit biased on the need to use encryption;): https://wiki.archlinux.org/index.php/Encryption

Offline

#15 2013-07-06 19:54:22

root
Member
From: 127.0.0.1
Registered: 2012-04-13
Posts: 297

Re: Encryption vs performance

@fledermann

Do you recall further details of that setup (f.e. algorythm used etc.)? Thanks in advance.

@Strike0

I confess that I have come to the same conclusion or at least I consider them pretty much the same. For example, for 'users that have access to the computer' I think the best method would be that of using Truecrypt in order to deny access to given files (folders even?). And for those I do not want to share anything at all 'in general' with a more integral (hdd encryption) would be necessary.

As far as I understand it ewaller's questions are aimed at knowing the level of the attacker and that depending on it this or that level of encryption would be needed just as he points out himself,

ewaller wrote:

Depending on the answers, a 56 bit symmetric key strength might be fine.  OTOH, some things might want 192 or 256 bits.

And I honestly do not know the exact answers as, regarding hardware loss, one never knows whose hands the laptop will end up in (either directly, an average computer user (lmgtfy) or indirectly 'I have got a friend who knows about (cracking) this stuff').

But as a general approach, if that is accepted as an 'answer', I would want the first layer (hdd encryption) to provide a decent lock to avoid a 'too easy' access the the system (f.e. using live cds etc.).
And even if this lock isn't as strong as wanted (see below) this would be when the second layer (truecrypt) would come into play to secure specific content.

I am aware that the hardware specifics may limit the possibilities in this case but, to some extent, I have also trying to figure out the basics (both in terms of available tools and answers to ewaller's security questions) in order to take advantage of them when using more 'capable' hardware, so to speak.


\(o_X)/
                        'Cause I wanna be an Archy - An Archy in the UK // Sex Pistols

Offline

#16 2013-07-07 00:04:06

fledermann
Member
From: Bielefeld, Germany
Registered: 2013-06-24
Posts: 34

Re: Encryption vs performance

@root:
I was using xts-aes with a 512 byte keysize. I chose xts-aes because it was sufficiently secure for me needs, while still being pretty fast.
But dont't take my word for it when it comes to security - I have a very limited knowledge about encryption.

Offline

#17 2013-07-07 12:54:09

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: Encryption vs performance

You did not show your benchmark results here, but you will have seen that doubling keysize does not equate to halving throughput. Likewise for XTS the keysize is halved technically, that is why you dont get an XTS-128 offered in the cryptsetup benchmark.  When ewaller mentioned 56-bit DES above, it was meant in perspective. That cipher was fundamentally publically broken >10 years ago and is, hence, not suitable for blockdevice encryption. Yet a non-computer biased spouse would not be able to crack it. That is unless s/he has a real determination for some reason and makes you show the contents, which you will happily do of course without a warrant (yes, increasing keysize does not help then). Your hacker friend might be. If you let kids on the machine, you are likely vulnerable with it ..

DES was as an 'official' standard replaced by AES after a long, semi-public NIST competition. That is the reason the new cpus have it in silicon. The cipher you quote, Serpent, was the runner-up by votes and has, to my understanding also since then, stood strong against a lot of published cryptanalysis.

The main reason for me triggering you again on defining what you want to protect against was you mentioning "privacy" and "other legitimate users" of your machine. But you are aware of that obviously.

Depending on the amount of private data you want to keep in a "truecrypt" or similar container, another alternative suggested before in the forum is to use a different encryption for a separate /home partition. (My favourite is ecryptfs for that).
Doing that you don't double encryption overhead for the container data, but it is a bit more effort to setup. Dont ask me about performance stats or differences. It is more a common sense thought that doubling encryption overhead should be adverse (e.g. to your low RAM too!). Maybe someone else has input on that. Again the same thing holds, as mentioned early by Rookie in the thread: if you regularly move a lot of data around, you will notice it a lot too. If you don't, you probably won't.

As a final thought from me, another point worth considering is the actual filesystem used (in the encrypted blockdevice). In some other thread it was suggested that there are in fact noticable performance differences in some usecases. Maybe you want to look into that too, if you decide to re-install anyway. Fab tagline btw.

Offline

#18 2013-07-08 11:40:03

drasticraft
Member
From: mars
Registered: 2013-07-05
Posts: 55
Website

Re: Encryption vs performance

ewaller wrote:

DES is not too bad in terms of performance.

But what it is bad at is encryption. It's been around since the early 1970s.
There has been a lot of time to learn how to crack it, and now there are even online guides on how to decrypt it! Of course I won't be handing out links, but still.

Offline

#19 2013-07-08 13:25:02

ewaller
Administrator
From: Pasadena, CA
Registered: 2009-07-13
Posts: 13,140

Re: Encryption vs performance

drasticraft wrote:
ewaller wrote:

DES is not too bad in terms of performance.

But what it is bad at is encryption. It's been around since the early 1970s.
There has been a lot of time to learn how to crack it, and now there are even online guides on how to decrypt it! Of course I won't be handing out links, but still.

I thought that was my point.  It will, however, dissuade most people who are not determined.  OTOH, 3DES is still in use, and is approved for use by NIST for a couple more years.

AES is an excellent replacement, but for now, almost every encrypted credit card transaction uses 3DES

Last edited by ewaller (2013-07-08 13:25:32)


Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
You assume people are rational and influenced by evidence.  You must not work with the public much. -- Trilby
----
How to Ask Questions the Smart Way

Offline

#20 2013-07-09 20:06:34

root
Member
From: 127.0.0.1
Registered: 2012-04-13
Posts: 297

Re: Encryption vs performance

@fledermann

No worries. Thanks anyway for the info.

@Strike0

I totally forgot about that. A kernel update came along and I thought 'Well, will reply after rebooting and paste it' but as usual new things started crossing my mind afterwards and in the end I did not include the results in my reply.

The results are as follows:

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1        51522 iterations per second
PBKDF2-sha256      46545 iterations per second
PBKDF2-sha512      17210 iterations per second
PBKDF2-ripemd160   75851 iterations per second
PBKDF2-whirlpool   22080 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    21,6 MiB/s    30,7 MiB/s
 serpent-cbc   128b    12,8 MiB/s    16,5 MiB/s
 twofish-cbc   128b    36,1 MiB/s    38,1 MiB/s
     aes-cbc   256b    23,5 MiB/s    23,7 MiB/s
 serpent-cbc   256b    12,9 MiB/s    16,5 MiB/s
 twofish-cbc   256b    36,0 MiB/s    38,2 MiB/s
     aes-xts   256b    30,7 MiB/s    29,8 MiB/s
 serpent-xts   256b    12,9 MiB/s    16,4 MiB/s
 twofish-xts   256b    37,4 MiB/s    37,0 MiB/s
     aes-xts   512b    23,7 MiB/s    23,3 MiB/s
 serpent-xts   512b    13,0 MiB/s    16,3 MiB/s
 twofish-xts   512b    37,1 MiB/s    37,0 MiB/s

As for ewaller's example I understood it both as an simple example of a possible encryption scheme and as the suggestion of using more than one security 'layer' depending on the needs. Taking into account your comment I presume I should disregard the example and focus more on the suggestion.
Regarding the access of 'other legitimate users' I didn't mean to refer specifically to a spouse, partner etc. which I consider to be part of a trustworthy circle but to 3rd persons that ocassionally may use the equipment. Like a guest who wants to check his mail or the tech support in case something is wrong with the computer. Especially in the later case I have personal 1st hand experience of the technicians being at the same time (or even more) interested in going through the user's personal data (the client was a girl) and fixing the problem the computer had.
Taking this into account you will understand that I don't consider myself the provider of any content for this or similar kind of people even if it the most harmless one can think of (still private in the end though).

The size of the 'private container' is indeed a tricky thing, just like it is when thinking of how to setup the different partitions when installing a Linux distro.
The size drcouzelis suggested looks fine to me, even, to some extent, excessive but I presume it is better to overestimate than to underestimate.

As for 'excluding' the home partition from a general disk encryption setup, well, as long as it works as it should I wouldn't mind trying that out but as you yourself state it indeed sounds trickier to setup. Thus I would be tempted to first try out the secure directory setup as explained in the wiki. But I understand, at least I think I do, the idea of your suggestion. Once I go through the documentation available I will most likely end up more or less convinced.

Just as with regards to a specific/'personalized' encryption for the home partition in terms of using a different filesystem I wonder if it wouldn't come to the considerations of using X filesystem for X type of files just as one does when choosing the filesystem for the partitions. I mean filesystem A might show better performance because the encrypted files are of type B which it handels best.
Therefore wouldn't I end up being a 'hostage' of those type of files when the data to be encrypted would be of 'mixed nature' (larger, lighter etc.)?


\(o_X)/
                        'Cause I wanna be an Archy - An Archy in the UK // Sex Pistols

Offline

#21 2013-07-09 22:29:46

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: Encryption vs performance

Interesting to see the benchmark results, is it not? According to those you have a few with throughput of ~triple your disk i/o, some with the longest keysize, on the machine. You might have misunderstood the relation when you quoted Serpent earlier. The higher the benchmarked crypto throughput, the less overhead it is for the cpu.

Your current thought to have a separate crypt directory is good for filesystem usage, since it is fully flexible sizewise (it grows and shrinks with usage).

The filesystem choice I brought up because it will affect performance too - more so with lower-spec hardware (you did a quick hdparm benchmark yourself). I am a bit agnostic for filesystem choices myself, i.e. I tend to use those I have had good long experiences with and not experiment. I share your point about file types, but then again we have no idea about your PC usecase. This is a bit old kernel, but good read about crypto performance (for the inclined).

edit: deleted sentence about dmcrypt being single-threaded (it really depends on the disk setup and sort of disk i/o operation whether the crypto is single- or multithreaded).

Last edited by Strike0 (2013-07-10 17:01:45)

Offline

#22 2013-07-10 00:07:57

thiagowfx
Member
Registered: 2013-07-09
Posts: 532

Re: Encryption vs performance

Is there a quick way of encrypting a partition which already has some data, but without wiping it out first? That is, suppose that I want to encrypt my /home partition right now, but without formatting it. Any decent ways to do that?

Last edited by thiagowfx (2013-07-10 00:08:34)

Offline

#23 2013-08-26 13:39:57

root
Member
From: 127.0.0.1
Registered: 2012-04-13
Posts: 297

Re: Encryption vs performance

Sorry to pick up the discussion after so much time but time constraints didn't help.

@Strike0

It is not that I misunderstood the relation but that I didn't actually know how to interpret them as stated in #11,

I presume that on the basis of the disk speed noted in my earlier posts the next step would be to find the 'equivalent pair' in the benchmark results?

I am happy though to see that I have several options at my disposal.

As for using a different filesystem I think if I explore the container option for now I will stick to the known ones. Tests are a possibility as always but first I would like to have a stable structure 'for the real thing'.


\(o_X)/
                        'Cause I wanna be an Archy - An Archy in the UK // Sex Pistols

Offline

#24 2013-08-26 20:50:56

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,277

Re: Encryption vs performance

Sure, have a bit of experimenting with filesystems and ciphers. Plus its no need to change any setup for a container, if you dont want automount at boot. If you want to use cryptsetup instead of Truecrypt for it, there is a wiki section for that too I believe. It's called loopback filesystem. Once you've done it, it is very quick. Just without GUI.

Offline

Board footer

Powered by FluxBB