Page 6 of 18 FirstFirst ... 234567891016 ... LastLast
Results 101 to 120 of 353

Thread: Truecrypt 5.0 Released (now with system partition encryption)

  1. #101
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nobody@aes256.cn (Anonymous) wrote in news:f0c6f944956a469714d047cbab689929
    @aes256.cn:

    > None of that has anything at all to do with what the guy was
    > talking about. Nobody is even suggesting the use of Truecrypt would
    > be hidden, he's talking about hardening Truecrypt's plausible
    > deniability by using hidden volumes to create two completely
    > separate encrypted OS installs, and using the password mechanism as
    > a sort of boot loader. Is such a thing possible?
    >
    > Please..... if you don't understand the question don't try and give
    > an answer.



    I understand the question very well.

    And my answer is twofold:

    1) I cannot currently be done with Truecrypt

    2) That it cannot be done is no loss since it's a silly idea in the first
    place.

    Regards,


  2. #102
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Anonymous <nobody@aes256.cn> wrote in
    news:874c4fbd4874eb652c39433b31131c8a@aes256.cn:

    > nemo_outis wrote:


    If you encrypt an entire HD (as Truecrypt allows you to do in "device"
    mode) then you cannot boot from that HD. If you do this with all your HDs
    then you cannot boot from any of them. You are reduced to using all your
    HDs as data drives. And so you must find something else (CD, USB, etc) to
    boot from. Or else stare at your completely non-functional computer, which
    will just sit there making exactly the same kind of humming noise that
    bricks don't.

    If this was all you wanted from life then you could have stuck with version
    4.3 of Truecrypt, and not bothered folks here with your whinging.

    Regards,



  3. #103
    Anonymous
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > George Orwell <nobody@mixmaster.it> wrote in
    > news:d7ac7fb60c39b076fbe85e54bf4ba496@mixmaster.it:
    >
    > Ah, the first of the whiners and cavillers has arrived. ...with
    > a farrago of nonsense. ...just as I predicted.
    >
    >
    > > nemo_outis wrote:
    > >
    > >> The entire disk IS encrypted, with the exception of the boot
    > >> stub on track 0.

    > >
    > > No, it's not. If you have two partitions and encrypt only the
    > > "system" partition the other isn't touched.

    >
    > Are you usually this thick? Yes, even though you have a
    > whole-disk encryption program you can choose not to encrypt some
    > partitions - or any of them for that matter. However, choosing
    > not to use the program's capability for whole-disk encryption
    > doesn't make it one whit less a whole-disk encryption program.
    >
    > As for a boot drive's partition table, some full HD OTFE programs
    > may encrypt it, while others may not - just as I said. For
    > instance, Bestcrypt Volume Encryption (one of the better
    > commercial full-HD OTFE programs) does NOT encrypt the partiton



    Excuse me *******, but.... Bestcrypt isn't wholedisk encryption
    either.

    Main Features

    1. Encrypting all types of volumes residing on fixed and removable disks:
    * Simple volume, i.e. volume consisting of one disk partition.
    * Mount point - volume mounted as a sub-folder on NTFS-formatted volume.
    * Multipartition volume, i.e. volume consisting of several disk partitions:
    1. Spanned volumes;
    2. Mirrored volumes;
    3. Striped volumes;
    4. RAID-5 volumes.

    If you're struggling with the meaning of "volume" and "residing
    on" let us know and we'll post some explanations using really
    small words. :)


    > table on a fully encrypted hard drive - I have just confirmed
    > this with a number of partition managers (using Hiren v9.3).
    >
    > Why? Because encrypted partition tables are just asking for
    > trouble from some program that doesn't recognize that the disk is


    What a crock. Do you have any clue at all how many wholedisk OTFE
    producte actually DO encrypt the partition table? Any clue at all?

    Wait, no you don't. You don't even know what wholedisk encryption
    products ARE.

    > not trashed (i.e., one that misinterprets an encrypted partition
    > table as a corrupted one).
    >
    > Just as I said.
    >
    > The benefit from encrypting the partition table? None!


    That's really funny coming from someone whose idea of "secure" is
    hiding something in a sock drawer.

    Yeah nimrod, your silly ass steganography is secure but hiding the
    fact that entire partitions exist with strong encryption is a waste
    of time.

    You're not just dim, you can't even pick a position and stick with
    it.

    What an idiot.


  4. #104
    Ari
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Thanks, nemo.


    On Sat, 09 Feb 2008 04:15:24 GMT, nemo_outis wrote:

    > Ari <arisilverstein@yahoo.com> wrote in
    > news:1f1ux0vajj9g7.1i6hv3ciyph87.dlg@40tude.net:
    >
    >> On Fri, 08 Feb 2008 17:40:22 GMT, nemo_outis wrote:
    >>
    >>> I'll be happy to post the method again if anyone cares.
    >>>
    >>> Regards,

    >>
    >> I do.
    >>
    >> I love you and you know that.

    >
    > Here (from 2004) is the method whereby a suitably configured OS (or
    > powerful system-level program, etc.) could leak the encryption key of a
    > full-HD OTFE program without changing the encryption algorithm in the
    > least. My old description is in terms of DCPP but the method generalizes
    > to all such programs, including Truecrypt. All that is required is that
    > the full-HD OTFE user have installed a particular OS which has, say,
    > already been modifed back at Microsoft by the NSA to have the
    > capabilities I describe.
    >
    > ********************************************
    > A malign OS can leak the encryption key even while fully and perfectly
    > adhering to the DCPP encryption scheme. And it can leak the key on the
    > ordinary data areas of the HD - no hidey-holes required. The scheme will
    > pass every validation test, because it fully adheres to the DCPP
    > encryption rules.
    >
    > AND YET THE KEY WILL HAVE BEEN LEAKED!
    > ********************************************
    >
    > Bear with me, for this is a little complicated to explain.
    >
    > I'm going to describe the unobfuscated way of doing this at first.
    > First of all, I take as given that the malign OS can harvest the key from
    > memory. So the OS knows the key (say 256-bit for the sake of
    > concreteness)
    >
    > Now, it is perfectly legitimate for the OS to write data for its own
    > purposes in a sequence of sectors (say as part of the swap file).
    > However, according to the DCPP encryption mechanism it must encrypt them
    > using the algorithm and key (and IV) that is prescribed by DCPP. So
    > here's what the malign OS does next.
    >
    > Let's say the first 3 bits of the key are 001
    >
    > For the first in a series of 256 consecutive sectors in the swap file
    > (and the OS can easily ensure these are also consecutive physical sectors
    > on the HD as well) the OS generates some random data. It then encrypts
    > it following the DCPP algorithm perfectly. If it encrypts to an odd 512-
    > byte number, the OS writes the sector. If it doesn't, it generates a new
    > random number and tries again. Very quickly it finds a value that will
    > encrypt to an odd 512-byte number. Satisfied, it writes the data to the
    > sector. Here's the crux: the OS has just written a sector that can be
    > interpreted as a binary zero (i.e., if the whole 512-byte encrypted
    > sector is odd). It has just leaked the first bit of the key!
    >
    > The OS repeats the process for the next sector until it again writes what
    > can be interpreted as a "zero" (i.e., the whole 512-byte encrypted sector
    > is odd). It has just leaked the second bit of the key!
    >
    > The OS repeats the process again for the third bit - except this time the
    > sector must encrypt to an even 512-byte number to signal a binary one.
    > The OS writes the sector, thus leaking the third bit of the key.
    >
    > And so on and so on until the OS has leaked the entire 256-bit key as a
    > sequence of 256 consecutive completely-properly-encrypted sectors, with
    > each sector interpreted as binary 0 or 1 according to whether its whole
    > 512-byte contents are even or odd!
    >
    > But how would someone looking at the disk know where the OS has leaked
    > the key? Answer: the OS uses (say) a ten-sector sequence of all evens
    > (say) to signal that the next 256 sectors should be interpreted as the
    > key!
    >
    > Result: the malign OS has fully conformed to the encryption rules. Every
    > sector is correctly encrypted according to the rules - no exceptions! No
    > data has been written to any hidey-hole. AND YET THE KEY HAS BEEN
    > LEAKED!
    >
    > Assuming you understand the above, you can now add obfuscation. For
    > instance, there is no need for the "key follows" signal to be ten 1's -
    > it could just as easily be 1001001101110111.
    >
    > Similarly, the malign OS needn't leak the key as "plaintext" - it can
    > encrypt/obscure the leaked key sequence using a prearranged scheme known
    > only to the NSA and Microsoft.
    >
    > As I said in a previous post: Covert channels are a bitch to plug!
    >
    > Regards,
    >
    > PS Needless to say, once the principle is grasped, zillions of
    > variants readily spring to mind.



    --
    An Explanation Of The Need To Be "Anonymous"
    http://www.penny-arcade.com/comic/2004/03/19

  5. #105
    Anonymous
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > > Tell you what, why don't you go right ahead and shrink your main
    > > bootable partition on your first hard drive and create another
    > > partition on that drive (if you don't have one there already) and then
    > > use Truecrypt to encrypt that entire drive as a single device so the
    > > entire disk IS encrypted. Let us know how that works out for you.
    > >
    > > Hope you have backups. ;)

    >
    > You really are a whining caviller. However, lest others be misled, I will
    > explain why I am 100% correct.


    "BestCrypt Volume Encryption software provides the following advanced
    functionality:

    1. Encrypting all types of volumes residing on fixed and removable
    disks:

    * I. Simple volume, i.e. volume consisting of one disk partition.
    * II. Mount point - volume mounted as a sub-folder on
    NTFS-formatted volume.
    * III. Multipartition volume, i.e. volume consisting of several
    disk partitions:"

    http://www.jetico.com/bcve_web_help/...n_features.htm

    What part of "volume" and "residing on" are you struggling with there
    sonny? :)


  6. #106
    Sebastian G.
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Anonymous wrote:


    >> However, I found a privilege escalation vulnerability from
    >> version 4.3a being carried over, so I heavily recommend to avoid
    >> using TrueCrypt until it's fixed.

    >
    > You didn't find ****. There's no such vulnerability that hasn't
    > been fixed, and all you're doing is spreading FUD to try and make
    > yourself look important.



    Since the TrueCrypt developers obviously don't care (haven't responded
    withing 48 hours), I can publish the vulnerability:

    ntdriver.c!ProcessVolumeDeviceControlIrp!IOCTL_MOUNTDEV_QUERY_SUGGESTED_LINK_NAME:
    if Irp->AssociatedIrp.SystemBuffer is smaller than
    sizeof(MOUNTDEV_SUGGESTED_LINK_NAME), this will lead to an unhandled invalid
    memory write access or kernel memory corruption. If the buffer address is
    larger than 0x100000000-sizeof(MOUNTDEV_SUGGESTED_LINK_NAME), an integer
    overflow occurs and allows to write into memory regions around 0x00000000 to
    (sizeof(MOUNTDEV_SUGGESTED_LINK_NAME)), where the process control block may
    reside

    ntdriver.c!ProcessVolumeDeviceControlIrp!IOCTL_DISK_VERIFY: if if
    Irp->AssociatedIrp.SystemBuffer is smaller than sizeof(VERIFY_INFORMATION),
    this will lead to an unhandled invalid memory read access or information
    disclosure

    Both can easily be triggered by creating a new volume or taking an existing
    one, mounting it with drive letter X: and the running dc2.exe (Driver Path
    Exerciser Tool for the Windows Driver Kit) against the volume object file:
    "dc2 /hct \Device\TrueCryptVolumeX". If you activate logging (switch '/lv'),
    then you'll see that the crash happens for the DeviceIoControl test at the
    IOCTLs 0x4d00c or 0x70014, which are the two mentioned above.

    > You've pulled that same crap before too,
    > and got spanked right out of a couple forums because of it.



    I only posted one vulnerability in the forums, which was a real
    vulnerability (the Makefile for the driver defined the macro NT_UP=1, which
    will trigger some optimization for single processor systems that don't hold
    on multi processor systems and lead to fatal consequences) and this got
    acknowledged quite well. Being "spanked right out" is something I don't know
    about, maybe you can elaborate?

    > Isn't that right, "Gobbleslop"? ;-)



    Hm? Should this name tell me anything?

  7. #107
    Sebastian G.
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > "Sebastian G." <seppi@seppig.de> wrote in
    > news:61496qF1smtekU1@mid.dfncis.de:
    >
    >> nemo_outis wrote:
    >>
    >>
    >>> If that "other media" is permanently attached to the system (i.e.,
    >>> "fixed") then plausible deniability is still shot. Since Microsoft
    >>> only supports booting normal Windows (not PE, not embedded) from
    >>> fixed media, what you want is unachievable with Windows as the OS
    >>> (without violating the licence).

    >
    >> Once again: You can modify an normal Windows installation CD to allow
    >> installation and booting from USB mass storage, FireWire Mass Storage
    >> and SD Cards. Without any license violation. With a text editor and
    >> cabarc (which is free to download from Microsoft).

    >
    >
    > No, Sebastian, such a modification of Windows is not authorized by
    > Microsoft.



    Such a modification is even explicitly intended by Microsoft, it's called an
    "unattended setup".

    > And BTW, Sebastian, it's still utterly implausible that someone has a
    > computer system with every HD completely filled with random junk.



    I already told you some counterexamples.

    > Remmember, Sebastian, it's not whether you find such patent nonsense



    OK, now you even call standard practices nonsense.

    > plausible but whether a judge and jury do.



    They should. After all, any special attended expert can tell them that such
    things are common practice.

  8. #108
    Sebastian G.
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:


    >> Additionally, if you do the pre-boot stuff, the MBR containing this
    >> code would also differ from random data. But TrueCrypt does not permit
    >> storing the MBR on another media and do some redirection.

    >
    > Yes, Truecrypt has not COMPLETELY redesigned Windows' boot process to
    > accomodate a kook like you.



    Two obvious things:

    - This is not a limitation of Windows' boot process. Why do you think it is?

    - storing the initial boot loader on another media to avoid running a
    potentially modified bootloader from the disk in neither unknown nor
    unusual, so it's no wonder that some products actually implement this

    But since you can hardly do anything but ranting, maybe you should stop
    discussing about such trivialities.

  9. #109
    Sebastian G.
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Anonymous wrote:

    > Sebastian G. wrote:
    >
    >> Cyberiade.it Anonymous Remailer wrote:
    >>
    >>
    >>>> Are you usually this thick? Yes, even though you have a
    >>>> whole-disk encryption program you can choose not to encrypt some
    >>>> partitions - or any of them for that matter. However, choosing
    >>>> not to use the program's capability for whole-disk encryption
    >>>> doesn't make it one whit less a whole-disk encryption program.
    >>> Problem is, with Truecrypt you don't have that choice.

    >>
    >> So then my fully encrypted harddisk with even an encrypted partition table
    >> is pure imagination?

    >
    > It sure as hell is if you think you have a usable operating system
    > installed on it.



    I don't think so, since I haven't. And never claimed so.


    Maybe you have a problem with statements? The I'll better summarize the
    current point:

    - TrueCrypt does support encrypting entire media including partition tables,
    so it's FDE.
    - TrueCrypt does support booting from encrypted partitions using pre-boot
    authentication.
    - But not oth things simultaneously on the same media.

    >> Who cares for installing an OS? This drive only contains data, the OS is on
    >> another media.

    >
    > Exactly. That's what tells us you're using partition/volume encryption
    > rather than whole disk encryption.



    I use partition encryption for the OS, and FDE volume encryption for the data.

    > I have no idea where you're getting your definitions and information
    > from, or whether you're just making **** up as you go, but even
    > Truecrypt doesn't claim to be whole disk encryption.



    It does claim so, supports it very well and I can easily verify on my system
    that it actually does.

    > Do you really think you're more knowledgeable about the product than the
    > people who write and maintain it?



    No. I just think that you're too stupid to read the documentation and/or try
    it yourself - before posting your spouted nonsense.

  10. #110
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Anonymous <nobody@aes256.cn> wrote in
    news:3d153c86fd7dcfae05dfaafa24ca4363@aes256.cn:

    You still don't understand that Bestcrypt Volume Encryption can provide
    OTFE protection for full HDs? Then go read the site documentation again -
    maybe this time even a moron like you will get it.

    Regards,

  11. #111
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nobody@aes256.cn (Anonymous) wrote in
    news:6820499054317f6d4743e40c24032cb3@aes256.cn:

    You still don't understand that Bestcrypt Volume Encryption can provide
    OTFE protection for full HDs? Then go read the site documentation again -
    maybe this time even a moron like you will get it.

    Regards,

  12. #112
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    "Sebastian G." <seppi@seppig.de> wrote in
    news:615b23F1sfp4gU2@mid.dfncis.de:

    > Such a modification is even explicitly intended by Microsoft, it's
    > called an "unattended setup".


    It's not the unintended setup that's unsupported ny Microsoft, but setup to
    a removable drive (e.g., USB)

    >> And BTW, Sebastian, it's still utterly implausible that someone has a
    >> computer system with every HD completely filled with random junk.


    > I already told you some counterexamples.


    Yes, blatantly implausible ones.

    >> Remmember, Sebastian, it's not whether you find such patent nonsense
    >> plausible but whether a judge and jury do.


    No, Sebastian, by far the most plausible reason for every drive on a
    computer being filled with random junk is that encryption is being used.

    Regards,

  13. #113
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    "Sebastian G." <seppi@seppig.de> wrote in
    news:615b7tF1sfp4gU3@mid.dfncis.de:

    > nemo_outis wrote:
    >
    >
    >>> Additionally, if you do the pre-boot stuff, the MBR containing this
    >>> code would also differ from random data. But TrueCrypt does not
    >>> permit storing the MBR on another media and do some redirection.

    >>
    >> Yes, Truecrypt has not COMPLETELY redesigned Windows' boot process to
    >> accomodate a kook like you.

    >
    >
    > Two obvious things:
    >
    > - This is not a limitation of Windows' boot process. Why do you think
    > it is?
    >
    > - storing the initial boot loader on another media to avoid running a
    > potentially modified bootloader from the disk in neither unknown nor
    > unusual, so it's no wonder that some products actually implement this


    How can you be this stupid, Sebastian? No matter how easy you think it
    is, no matter how badly you want it, the plain fact of the matter is that
    WINDOWS DOESN'T DO IT!

    Regards,


  14. #114
    Nomen Nescio
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > George Orwell <nobody@mixmaster.it> wrote in
    > news:bf6ea79edec361e1aad589185e7d1167@mixmaster.it:
    >
    > > nemo_outis wrote:

    > ...
    > >> As for an unencrypted partition table disclosing info, that
    > >> trivial info is useless for decrypting the contents of the
    > >> partitions or even inferring the nature of what is contained
    > >> in them.

    >
    > > I see. So now you believe you're smarter than all the encryption
    > > and cryptanalysis experts that ever lived, combined.

    >
    >
    > You see little and comprehend less.
    >
    > If you have some argument to show how an unencrypted partition
    > table would permit decrypting the contents of of an encrypted


    Nobody ever said anything at all like that you lying *******.
    You've already been clubbed over the head with a cite about why
    unencrypted partition tables are less secure than encrypted ones.
    You didn't even have the courage to reply to it, but it's out there
    none the less.

    > partition, then make it. If not, then, as I have repeatedly
    > suggested: Do be a good little moron and **** off.
    >
    > Regards,















  15. #115
    Nomen Nescio
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > >> Bestcrypt Volume Encryption for Windows is among the most advanced
    > >> full-HD OTFE encryption systems. Not only can it encrypt all HD
    > >> partitions on all HDs (including the boot/system one) it supports
    > >> complete encyption of spanned, mirrored, and striped volumes, as well
    > >> as RAID 5 volumes. It also supports physical tokens in addition to a
    > >> password/passphrase for additional security.
    > >>
    > >> http://www.jetico.com/bcve.htm

    > >
    > > That paragraph doesn't exist at all on that page. Or anywhere else on
    > > Jetico's site that I can find.

    >
    > Of course, you ****ing moron, that paragraph is mine, in my words - there
    > are no quotation marks, no "Jeticos says" in it. It's a simple
    > description and characterization of the program clearly provided by me,
    > the author of the post, the fellow with his name in the "From" header -
    > just as anyone who wasn't a moron like you would expect. You've just
    > failed to comprehend plain English - yet again.


    I almost feel sorry for you. Even you had to cringe when you made the
    decision to try and float such a whopper.

    *snicker*

    Nobody is going to buy it liar. If you're going to play that way you're
    going to at least play on some level above "imbecile". Come up with a
    credible lie. Maybe "Oh, they must have just changed that page when
    they released 5.0" or something. It wouldn't really help all that much
    because the link you provided says exactly the opposite of the lie you
    tried to tell, but at the bottom end of the evolutionary ladder you
    would, at least, stand out among your peers.

    > The cite was provided for convenience to allow readers to check for
    > themselves what Bestcrypt says about its product. And the cite was set
    > off in a completely separate paragraph specifically so as not to directly
    > link it to my words above.
    >
    > As for what Bestcrypt says about the term "volume," you would understand,
    > if you weren't such a colossal moron, that Bestcrypt uses the term in a
    > broader sense than Truecrypt to refer to "high-level storage entities"
    > that can, inter alia, extend across multiple hard drives (such as spanned
    > volumes or RAID 5). Jetico makes the distinction between "volume" and
    > "whole-disk" encryption because its product can support seamless
    > "volumes" which may be stored across several physical HDs.


    What they say, "moron", is that volume, partition, and FD/Wholedisk are
    three different things. Period. And that of those three possibilities,
    Bestcrypt is clearly of type "volume". Period. It's not ambiguous no
    matter how hard you try and wriggle out of you own imbecility by
    pretending it is. It's a clear statement of fact that proves you
    unequivocally wrong, made by the people you were "citing" in an attempt
    to prop up that imbecility.

    Sorry about your luck, sucks to be you, have a nice day.

    *snicker*

    > Now do be a good moron and **** off.


    Maybe after a bit. That crunching sound is just too attractive at the
    moment. Sorta like a little symphony, being backed up your your
    squealing and all.

    *snicker*

    Don't worry little one, I know how important it is for people like you
    to get the last word in. When I decide that time has come, I'll let you
    know. :)


  16. #116
    Anonymous
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Sebastian G. wrote:

    > Anonymous wrote:
    >
    >
    > > except maybe in caches, swap space, histories and logs, last
    > > modified fields, etc...........
    > >
    > > with whole disk nothing can ever be leaked to another partition
    > > or anywhere else that anyone can see without owning the keys.
    > > partition encryption can leak like a sieve.

    >
    >
    > Which is wrong again. For all those FDE products which use CBC
    > mode, the swap file is likely to contain an IV, which leaks the


    Which doesn't matter one ****ing bit because unless it's mounted,
    it's encrypted.

    What an idiot.


    > first block of data for every CBC block. For LRW, swapping out an
    > empty page with the LRW tweak key at the beginning or the end
    > will allow an attacker to retrieve the LRW tweak, and therefore
    > distinguishing the encrypted volume from random data. For ESSIV
    > it's the same.
    >
    > Lucky you that TrueCrypt 5.0 introduced XTS as the only mode for
    > creating new encrypted volumes.














  17. #117
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Nomen Nescio <nobody@dizum.com> wrote in
    news:9c560c5e4d435ab2734ae2e076739ea3@dizum.com:

    Back again with the same ********? You get the same answer as last time.

    If you have some argument to show how an unencrypted partition table would
    permit decrypting the contents of of an encrypted partition, then make it.
    If not, then, as I have repeatedly suggested: Do be a good little moron and
    **** off.

    Regards,

  18. #118
    nemo_outis
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    Nomen Nescio <nobody@dizum.com> wrote in
    news:82ea57176532ddf0881ca98427937d4a@dizum.com:

    You obviously still haven't enrolled in that remedial reading course.

    Regards,

  19. #119
    Cyberiade.it Anonymous Remailer
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > George Orwell <nobody@mixmaster.it> wrote in
    > news:cfba7ec8f8b207e0a1bd089fe3255024@mixmaster.it:
    >
    > > nemo_outis wrote:
    > >
    > >> There must - necessarily! - be a small amount of unencrypted code on
    > >> the boot/system volume. This is invariably located on track 0.

    > >
    > > Nope! I fact with *true* whole disk encryption there is absolutely no
    > > unencrypted information on a device at all.

    >
    > Uhh, doofus, Windows cannot boot from a completely encrypted disk because
    > there's nothing to decrypt those first bytes to even get the process


    Wrong!

    Windows can trivially boot from a completely, 100% end to end including
    sector 0, encrypted drive without modifying Windows at all, without
    using any external bootstrapping at all, and without using any stupid
    "boot sector copying" scheme.

    Your problem is your narrow little mind sonny. Ponder it a bit longer
    for my amusement and then I'll give you the facial. :)


  20. #120
    Anonymous
    Guest

    Re: Truecrypt 5.0 Released (now with system partition encryption)

    nemo_outis wrote:

    > nobody@aes256.cn (Anonymous) wrote in news:f0c6f944956a469714d047cbab689929
    > @aes256.cn:
    >
    > > None of that has anything at all to do with what the guy was
    > > talking about. Nobody is even suggesting the use of Truecrypt would
    > > be hidden, he's talking about hardening Truecrypt's plausible
    > > deniability by using hidden volumes to create two completely
    > > separate encrypted OS installs, and using the password mechanism as
    > > a sort of boot loader. Is such a thing possible?
    > >
    > > Please..... if you don't understand the question don't try and give
    > > an answer.

    >
    >
    > I understand the question very well.
    >
    > And my answer is twofold:
    >
    > 1) I cannot currently be done with Truecrypt
    >
    > 2) That it cannot be done is no loss since it's a silly idea in the first
    > place.


    So you're saying Truecrypt's hidden volumes are a silly idea?

    Fascinating.

    Oh wait, you're just being a vindictive little snipe because you got
    your ass handed to you over your Bestcrypt foible, and you mistakenly
    though you were striking back. You know full well the ability to create
    a "hidden system" volume would be near perfect plausible deniability
    because by the very definition of hidden volume as Truecrypt provides,
    it would be impossible to know if/where that volume existed, and not
    having the "host" volume mounted at all would mean nothing could leak
    to that copy of an OS across the encrypted boundrary. Additionally, the
    two password scheme used by normal hidden volumes would both protect
    the hidden volume, and provide a sort of "dead man" that could easily
    destroy the hidden evidence through normal use of the host volume.

    Pitty such a poetically secure isn't possible. Or is it? Did you
    actually try it, or is this just another nemo_outhouse crapper load of
    guesses and wishes?


Similar Threads

  1. Replies: 0
    Last Post: 03-15-07, 09:48 AM
  2. Were can I find what slot I have for vid card
    By agustintorre in forum Hardware & Overclocking
    Replies: 51
    Last Post: 02-10-07, 05:59 AM
  3. system partition full
    By zeffer111 in forum Software Forum
    Replies: 16
    Last Post: 12-27-05, 07:12 AM
  4. aČ System Editor PlugIn Released
    By hayc59 in forum Network Security
    Replies: 0
    Last Post: 01-15-05, 09:50 PM

Bookmarks

Posting Permissions

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