|
|||||||
| Dekart Private Disk products family The Forum is intended to encourage discussion on specific topics related to the Dekart Private Disk products family, focusing on virtual encrypted disk issues, encryption algorithms and ways your data is encrypted and decrypted. |
![]() |
|
|
Thread Tools | Search this Thread |
Rating:
|
Display Modes |
|
#1
|
|||
|
|||
|
Hi,
I just read the previous thread about the destroyed data. That leads me to the question, why are encrypted data so very very very very delicate???? I copied 10 000s of files from harddisk to flopy to usb-drive, to harddisk, to cd rom..... and never any one of my files was destroyed!!!??? If I copy a *.doc from A to B, then the *.doc file is there and I can read it, or it is NOT there and I can NOT read it. So, why should encrypted data be so very delicate? Is this the case with all kind of encrypted data, (encrypted files, directorys, drives...)??? If you know, the data is encrypted 256bit AES, shouldn´t you be able to open the data with any programm which can encrypt 256bit AES, if for some reason PD is not able to encrypt the data? Regarding the backups of a PD file: it is not very convenient, to make every day a backup copy, if you often add a file- this should go automatically! |
|
#2
|
||||
|
||||
|
Alfred, that's a very interesting topic you've just mentioned.
Actually, usual data is just as delicate as encrypted data. There is one difference: if a usual file is partially damaged, you can still recover parts of it, or even the entire document (that depends on the format of the file, how much redundancy there is, etc). You can still read the file and get the message. A spellchecker can fix that error for you automatically. If you have a graphic, then maybe you'll see a pixel of a different color. Many data formats include mechanisms that allow them to check whether the data is correct or not, then there are recovery techniques, parity bits, and so on. Encrypted data looks different. Moreover, Private Disk uses AES 256-bit in CBC mode, which means that the file is divided into blocks, and then the first encrypted block takes part in the process of the encryption of the second block, and so on. It means that the same data will look different when it is located in a different block. In other words, of in the first block the letter 'a' looks like '$', then in the second block, 'a' will look like 'b', and in the third block - a different character. See this entry about Cipher Block Chaining in Wikipedia. This is a great advantage because encrypted data looks absolutely random, there are no patterns in it (by the way, try to compress a Private Disk encrypted image, and you will see that the resulting archive is actually greater in size than the original file). So, if at least one bit in the encryption key is flipped, the entire file is gone for good. Why? Because the first block will be decrypted incorrectly, which leads to an incorrectly decrypted second block, and so on. The initial text will look like (just made this up) Code:
There is no recovery mechanism that can deal with that. So this is why encrypted data is considered delicate - if you have a 100 GB image, then all the gigabytes depend on a relatively small encryption key. If the key is incorrect - the 100 GB are useless. We are aware of that, and we provide a mechanism that allows you to avoid such trouble. All you have to do is make a backup of the encryption key. I made it big and green, hoping that people will actually read this part and make their conclusions. See the attached file to see how it works. Also, we plan to 'enforce' this in the next versions of Private Disk by automatically bringing up the 'make a backup of the encryption key' dialog when an image is created. Some people are not aware of this option and we'll try to make it more popular. Quote:
But if you backup the entire image - you make sure that no errors occur at all, provided that the copy was well-made. For more details, take a look at this guide - The importance of backups. Quote:
__________________
|
|
#3
|
||||
|
||||
|
And on a second note, in case you decide not to check out the article on Wikipedia, here is a visual representation of the difference between CBC and non-CBC modes of AES.
Note: the images are copyrighted, but according to the details, they can be freely used. The source ![]() The first image is the original file; the second one is a non-securely encrypted image - you can notice patterns in it. Even if the result is NOT the original, it still gives you a lot of info about what the actual content is, doesn't it? The output of AES in CBC-mode looks like the last example (this is what Private Disk does).
__________________
Last edited by Alex Railean : October 10th, 2008 at 12:28. |
|
#4
|
|||
|
|||
|
Thank you for your quick reply! It is very interesting!
In fact, I made a backup of the encryption key, and then I thought, why a backup of the encryptionkey AND a backup of the whole file- but now it is clear! I am a biochemist and I know about the genetic code and mutations, there are important informations and redundant informations, where a mutation is not bad at all- and there are mechanisms of repair.... so it seems DNA and electronically processed data do have many in comon! You just should make this kind of information more clear and on a more prominent place, so that people realy read it and can´t miss it. I did read most of the helpfile and the information on the homepage, but.... my english is not bad, but this cryptographic stuff is difficult to read in another language, so I read over it and perhaps missed something. Well, but that´s what this forum is for, isn´t it? I wish you a happy new year! |
|
#5
|
||||
|
||||
|
Here is some additional reading material on the topic: Encrypted data and disk defragmenters.
The article gives some details about the way in which disk defragmenters could have an impact on the files.
__________________
|
|
#6
|
|||
|
|||
|
Quote:
|
|
#7
|
|||
|
|||
|
Yes, that's what I thought when I read the above...I have been using this program for 4 years with 100s of Gigs of data and found it to be very resilient. I have had machines lock up hard with images open, drive to drive copy operations, etc. - and never had an image go bad yet. A testament to good error-checking operations.
|
|
#8
|
|||
|
|||
|
I don't understand this at all... maybe you can point me in the direction of more reading material because I'm not understanding.
I have my computer cloned on an external drive (obviously it's a large file) - I was thinking of encrypted it but am unsure - if encryption is more temperamental then maybe I should not and just use this program for smaller types of files... which is fine really, that is what I bought it for. From what I understand, I give my encrypted vault a password - the password unlocks the vault and there is my data (or clone of my computer if I decide to do it.) why do I need to make a copy of the encryption key? What is the encryption key - are you telling me you encrypt my password? and that you could "lose" a copy of my password??? Because I'm not liking how that sounds... Sorry, I have done a lot of reading but must be reading the wrong thing... Sandy |
|
#9
|
|||
|
|||
|
I did more reading - I get it now... but what I read on this fourm does not happen in my version (2.10.18 - OS Vista.) I don't know why...
|
|
#10
|
|||
|
|||
|
I know why... The make "Backup Copy of the Disks Encryption Key" feature does not work in Vista even if you select "Run as Adminstrator" (which has helped certain other features work.)
I know I can't use the program now... for doing without that feature would be stupid. I am disappointed as I paid for this program yesterday. |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|