View previous topic :: View next topic |
Author |
Message |
dermund Apprentice
Joined: 28 Aug 2007 Posts: 205 Location: Sprawl
|
Posted: Sun Jun 27, 2010 11:13 am Post subject: truecrypt performance on amd64 |
|
|
Hey,
I am going back to gentoo because I miss it...
I'm playing with the thought of doing a amd64 install. Since I have a truecrypt enabled partition I guess there should be a heavy speed gain with IO actions on it.
Does someone has a link of a comparison between amd64 and x86 truecrypt applications to support my guess. Or is someone here who have experienced this behaviour.
Kind regards,
Dermund |
|
Back to top |
|
|
rufnut Apprentice
Joined: 16 May 2005 Posts: 247
|
Posted: Mon Jun 28, 2010 9:06 am Post subject: |
|
|
Hi,
You might be better too use an alternative encryption method.
http://www.stoned-vienna.com/
Maybe try this:
http://en.gentoo-wiki.com/wiki/Root_filesystem_over_LVM2,_DM-Crypt_and_RAID
Quote: | I guess there should be a heavy speed gain with IO actions on it. |
I guess you mean loss.
It depends on a lot of things, does your CPU have hardware AES hardware ?
I lose about 30% speed on a quad core cpu and about 60% on an intel Atom. Yes 60%
Neither have AES support in the CPU. |
|
Back to top |
|
|
dermund Apprentice
Joined: 28 Aug 2007 Posts: 205 Location: Sprawl
|
Posted: Mon Jun 28, 2010 9:26 am Post subject: |
|
|
Hi rufnut,
Thanks for the link, I didn't know about that. Interesting...
I've had luks+dm-crypt-partitions in the past, but I found no way to mount them comfortably in window$. Since I still use it sometimes, truecrypt is a compromize.
I don't use it for full-system encryption though.
Quote: | I guess you mean loss.
It depends on a lot of things, does your CPU have hardware AES hardware ?
I lose about 30% speed on a quad core cpu and about 60% on an intel Atom. Yes 60%
Neither have AES support in the CPU. |
Hmm, I think you perhaps misunderstood me. I don't mean speed comparison between encrypted and unencrypted file transfers but: speed comparison between 32-bit and 64-bit enabled file transfers. |
|
Back to top |
|
|
rufnut Apprentice
Joined: 16 May 2005 Posts: 247
|
Posted: Mon Jun 28, 2010 12:31 pm Post subject: |
|
|
dermund wrote: |
Hmm, I think you perhaps misunderstood me. I don't mean speed comparison between encrypted and unencrypted file transfers but: speed comparison between 32-bit and 64-bit enabled file transfers. |
Sorry about that, I am not real sure but I think some 32 bit drivers/applications can do 64 bit transfers.
Would be interesting to find out?
dermund wrote: | I've had luks+dm-crypt-partitions in the past, but I found no way to mount them comfortably in window$. |
You could look at this one , I don't think it supports ext4 though:
http://www.freeotfe.org/features.html
Good luck with it anyway.
|
|
Back to top |
|
|
dermund Apprentice
Joined: 28 Aug 2007 Posts: 205 Location: Sprawl
|
Posted: Mon Jun 28, 2010 2:58 pm Post subject: |
|
|
Quote: | Sorry about that, I am not real sure but I think some 32 bit drivers/applications can do 64 bit transfers.
Would be interesting to find out?
|
Well if I had a amd64 system already I could make a few tests...
Assumed there is a speed boost on a amd64 system - this would be the only reason, why I would go for a amd64 profile.
The containers have ntfs in it - that's quite bitter, but a compromize also. Since it's the only thing windows wants to understand.
I am looking into freeotfe, but it can be quite a pain to change the decryption standard for a whole bunch of data, if you have no spare drives... |
|
Back to top |
|
|
kernelOfTruth Watchman
Joined: 20 Dec 2005 Posts: 6111 Location: Vienna, Austria; Germany; hello world :)
|
|
Back to top |
|
|
dermund Apprentice
Joined: 28 Aug 2007 Posts: 205 Location: Sprawl
|
Posted: Wed Jul 14, 2010 9:42 pm Post subject: |
|
|
I haven't execized all of the "Stoned Vienna" Site, but - If it's resident in the MBR, all I have to do to prevent the bootkit from being executed is to scan the MBR before every shutdown for malicious code - or am I wrong?!
Thus it would be no real threat for 'alerted' users. |
|
Back to top |
|
|
|