Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: TrueCrypt 7.0 Released With Hardware-Accelerated AES

  1. #11
    Join Date
    Oct 2009
    Posts
    2,138

    Default

    Quote Originally Posted by robo47 View Post
    It is a lot easier to use, has a simple gui for easy creation of encrypted containers, partitions and drives,
    and.... you need to compile it manually from source.
    OR, you could just hit the "encrypt" button during the install of your favorite distro.... I'm sure that most of the big ones have an install time option to encrypt, I know Fedora does. And a gui to format flash sticks with encryption..... and a PROMPT that automatically appears when you insert an encrypted flash stick. It does NOT get any easier than native LUKS.

    supports multiple cores!! and AES-NI, no need to create multiple dmcrypt-devices and a raid above them, to use multiple cores (on slower systems with fast disks/ssds without hadrware acceleration (VIA Eden, AES-NI, ... ) especially on older dual/quadcore-systems where cpu can be a real bottleneck for system-performance if you have your system encrypted, and want copy data on other fast encrypted discs (internal sata/sas or external e-sata/usb3).

    From the performance-point of view:

    My old p4 1.73 in my notebook got 44mb/s with dmcrypt and truecrypt, so copying data to an external encrypted drive was about 20mb/s and the cpu was completely used, lowering the processes priority only made it slower, so copying data, extracting big achives and stuff like that always meant i had to way until it is done and go on with my work then, no real background-thing.

    Now I get ~570mb/s on a single core (i7 620M [dualcore]) with dmcrypt [aes-ni-support] and with truecrypt ~1600-1700mb/s on both cores.

    Without AES-NI truecrypt (6.0) got about 250mb/s while dmcrypt on one core got about 100mb/s [older kernel/dmcrypt, think 110-120mb/s would be possible on an up2date kernel/dmcrypt]

    My benchmarks:
    Truecrypt 7.0 AES-NI Benchmark on Linux
    dmcrypt AES-NI Benchmark

    I will keep my dmcrypt for the operating system (since truecrypt for linux-system encryption isn't supported) and use truecrypt for external drives.
    Another thing, truecrypt runs on windows, linux, mac, solaris, ... , especially for external harddrives you want to use on more than operating system, sticking with dmcrypt just doesnt work.




    AMD does not have any hardware acceleration for encryption yet, so how should they support something which doesn't even exist in buyable processors ? But proposed something for their next generation, which for shure will be integrated in dmcrypt and truecrypt too.



    Do you have any benchmarks what actual gpus can achieve ?
    The point is that the GPU is perfectly suited for encryption/decryption. Even the WEAKEST GPU will outperform any intel junk that truecrypt is using.... which basically makes all your numbers worthless. What is needed isn't truecrypt+intel, its dmcrypt+OpenCL.

    Face it... truecrypt is NOT going to be integrated in any legit distro and will ALWAYS be a wall that the average computer user will NOT be able to climb.

  2. #12
    Join Date
    Aug 2010
    Posts
    2

    Default

    Quote Originally Posted by droidhacker View Post
    and.... you need to compile it manually from source.
    OR, you could just hit the "encrypt" button during the install of your favorite distro.... I'm sure that most of the big ones have an install time option to encrypt, I know Fedora does. And a gui to format flash sticks with encryption..... and a PROMPT that automatically appears when you insert an encrypted flash stick. It does NOT get any easier than native LUKS.
    Didn't know fedora offers it too, only knew debian and ubuntu[but only if you download the alternate-installer-cd]. Thought that would still be a not so often used future.

    What, under windows makes truecrypt nice, you can encrypt the system after installation too, and decrypt it too very easily.

    For example if you don't want it, feel your system ist to slow for it, ... or if you are running programms which don't run with it or even can render your system unbootable (some Adobe products copy-protection did that some time ago, they wrote on sector containing the headers, could even render raids unbootable).

    Do you know which gui-application is that which allows format/encrypt flash sticks and stuff ? Didnt find one under debian ? Only know the encryption-integration in ubuntu, but that uses EncFS if I am not wrong.

    The point is that the GPU is perfectly suited for encryption/decryption. Even the WEAKEST GPU will outperform any intel junk that truecrypt is using.... which basically makes all your numbers worthless. What is needed isn't truecrypt+intel, its dmcrypt+OpenCL.
    Sounds nice, but I believe it when I see it, I am using encryption since some time, i am using it currently and will use it in future. I especially bougth myself a dualcore cpu with aes-ni (there are no quadcores with aes-ni yet, only six-core xeons), because it can NOW deliver the performance I want, with dmcrypt, with truecrypt, with openssl, with everything which supports aes-ni, and that is getting more and more.
    If dmcrypt will be able to use the graphic-card as well in the future nice, if it is better than aes-ni, nice too. But for now, intel aes-ni ist probably the best cheap solution you can use for encryption if you don't want to waste to much cpu-power or have fast disks which would need more cpu-power or unless you want to invest in crypto-accelerator-cards.


    Face it... truecrypt is NOT going to be integrated in any legit distro and will ALWAYS be a wall that the average computer user will NOT be able to climb.
    I can live with that, but in my opinion, the average computer user in most cases uses windows, and doesn't care about encryption at all

    It's those people who want encryption, and they won't have a problem with downloading something and installing it, even compiling it from scratch if it offers them what they want.

    I truely prefer open and free software, if it offers me what i want, i currently don't care about some mb/s more or less, since both, dmcrypt and truecrypt are fast enough on my hardware to easily handle my internal 7200RPM-sata drive and my external sata-drive (connected through e-sata) and they both will be fast enough for my planed external raid via e-sata.
    The raid will probably be encrypted with dmcrypt, because it's in the kernel, because it will have a linux-fs, ... but it will be standing on my desk, and won't be moved like my other external drive and sometimes even be attached to windows or mac-systems.

    And that is where i can't use

  3. #13
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,286

    Default

    and a PROMPT that automatically appears when you insert an encrypted flash stick.
    Now this is just plain wrong. Attaching a header saying "this is encrypted" to the stick is an invitation to read it.
    Without such, assuming the cipher does not totally suck, an encrypted stick should be indistinguishable from an unformatted one.

  4. #14
    Join Date
    Oct 2009
    Posts
    2,138

    Default

    Quote Originally Posted by curaga View Post
    Now this is just plain wrong. Attaching a header saying "this is encrypted" to the stick is an invitation to read it.
    Without such, assuming the cipher does not totally suck, an encrypted stick should be indistinguishable from an unformatted one.
    That is absurd.
    First off, an UNFORMATTED disk can be easily distinguished from any encrypted disk since an encrypted disk will appear to have RANDOM data on it. Unformatted disk will either contain the remnants of a previous filesystem, or will have some kind of pattern, like all 0's. WHO writes random data onto their disks? RANDOMNESS is what REALLY begs to be read.

    SECOND, what is the PROBABILITY that someone is going to be carting around a disk with totally random data on it? Randomness isn't of any use, so if you FIND RANDOM DATA, then you can be pretty confident in guessing that it is, in fact, encrypted.

    ** the probability of finding truly random data ANYWHERE on a disk is so tiny that it isn't worth considering. If you find a disk that *appears* to have random data on it, even if other parts of the disk contain NON-RANDOM data, then that random data is something encrypted. Despite the claims by the truecrypt bunch, having a magical chunk of randomness on a disk DOES NOT hide it from scrutiny.

    Third, any encryption worth the CPU cycles it takes to perform can stand up to identification. If you depend on ignorance of they specific cypher in use for the protection of your data, then it might as well be plain text. Believe me -- any semi-competent cryptography expert CAN and WILL identify the cypher being used, which means that you DO, in fact, depend on the strength of the cypher.

    Quote Originally Posted by robo47 View Post
    Do you know which gui-application is that which allows format/encrypt flash sticks and stuff ? Didnt find one under debian ? Only know the encryption-integration in ubuntu, but that uses EncFS if I am not wrong.
    "Disk Utility" does it (applications --> System tools --> Disk utility).... when you select the "format" option, there is a checkbox to enable encryption. One could also use "gnome-luks-format", which is part of "luks-tools", but this package was at some point dropped from Fedora.

    What, under windows makes truecrypt nice, you can encrypt the system after installation too, and decrypt it too very easily.
    I think I read something about this in regards to luks.... can't remember any of it. Not that this is a particularly difficult thing to do without something purpose built....

    For example if you don't want it, feel your system ist to slow for it, ... or if you are running programms which don't run with it or even can render your system unbootable (some Adobe products copy-protection did that some time ago, they wrote on sector containing the headers, could even render raids unbootable).
    You DO know better than to compare problems with windeath to linux.... the program itself *CAN'T* know the difference between whether the underlying disk is encrypted or not. It certainly couldn't break things since the "adobe" lacks permission to break anything.

  5. #15
    Join Date
    Nov 2009
    Posts
    328

    Default

    Quote Originally Posted by curaga View Post
    Now this is just plain wrong. Attaching a header saying "this is encrypted" to the stick is an invitation to read it.
    Without such, assuming the cipher does not totally suck, an encrypted stick should be indistinguishable from an unformatted one.
    More important than others want to read it or not is that the target: your boss, job partner, friend, girlfriend, parent... could know that you have encrypted data, that you are hiding data. Avoiding this situation and using "unformatted partition" is desirable in many scenarios.

  6. #16
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,286

    Default

    There are different factory formattings, some with a partition table some without, some zeroed some not.

    It is completely legit to carry around an unformatted stick. Maybe it's new. Maybe it was recently wiped with shred.

    Any good cipher will not have statistically identifying properties. Whether any is that good yet I don't know, but they aim for that.


    The point is knowing for sure there's encrypted data, or it being only a possibility.

  7. #17
    Join Date
    Oct 2009
    Posts
    2,138

    Default

    Quote Originally Posted by curaga View Post
    There are different factory formattings, some with a partition table some without, some zeroed some not.

    It is completely legit to carry around an unformatted stick. Maybe it's new. Maybe it was recently wiped with shred.

    Any good cipher will not have statistically identifying properties. Whether any is that good yet I don't know, but they aim for that.


    The point is knowing for sure there's encrypted data, or it being only a possibility.
    And as I've already made clear, it MAKES NO DIFFERENCE. You STILL KNOW.

  8. #18
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    466

    Default

    Quote Originally Posted by droidhacker View Post
    The point is that the GPU is perfectly suited for encryption/decryption.
    GPUs are good for highly parallel pipelined operations which don't care about latency; they're not very good for anything that's serial or requires rapid results. Doesn't much matter if you can decrypt a block of data ten times as fast on a GPU if the CPU can decrypt the same data before it's even got into your GPU pipeline due to PCI-Express latency.

    Of course if you have some actual benchmarks to support your claim then feel free to post them.

  9. #19
    Join Date
    Nov 2009
    Posts
    328

    Default

    @droidhacker

    No, you are wrong exits methods that made impossible to differentiate between a partition formated with random data and a encrypted partition.

    http://en.wikipedia.org/wiki/Deniable_encryption

    http://www.truecrypt.org/docs/?s=plausible-deniability

  10. #20
    Join Date
    Nov 2009
    Posts
    328

    Default

    There are institutions, governments... where is obligatory to erase partitions / disk using a random data eraser, in fact some of them do more than 1 pass to assure no magnetic rest is left on the disk. So if you find random data on a disk, it is not an indication that the user has an encrypted data.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •