Jump to content











Photo
- - - - -

ProxyCrypt

arsenal image mounter imdisk proxy encryption volume

  • This topic is locked This topic is locked
104 replies to this topic

#26 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 22 November 2014 - 09:58 PM

Version 1.7.2 now does the password hashing sequentially on machines with only 1 core and 1 thread.
This means that if you are using the first hash function (Whirlpool), it should be about twice faster.
As a side effect, on such a machine, the memory requirement is also divided by 2 (more or less).

There is also some small improvements about the error management.



#27 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 22 November 2014 - 10:46 PM

ty :) 10s with Whirlpool 16s with SHA-3 Have difference in security between Whirlpool or SHA-3? Why when i use -c 160m parameter proxycrypt again asks the size?

#28 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 22 November 2014 - 11:46 PM

If you are using SHA3, there is as much calculation than before. So, this means that we had 36% of CPU load just for executing 2 threads at the same time.
I was expecting a small improvement, even for SHA3, but not so much...

SHA3 is more recent than Whirlpool. In fact, SHA3 is not even yet standardized. It is supposed to avoid some potential future attacks on SHA2, but there is not yet much cryptanalysis.
For Whirlpool, there is an attack (like for most hashes or encryption algorithms), but very limited and not applicable on the current hardware and for a very long time.
So, hard to say what is the more secure.
Moreover, the hash algorithms are not used alone but with the scrypt key derivation function. So, even if there is a weakness in one of these algorithms, this weakness will not necessarily be usable.

About the size, the one entered in the command line is the size of the image file. The size which is asked later is the size of the encrypted volume: you may want for instance to encrypt only a part of the file. This is also the case for disk encryption.
And with the size of the encrypted data, you also can choose their location with the -o switch. By specifying an offset and the size of encrypted data, we can imagine an image file or a hard disk like this:

 

|<----offset----->|<------encrypted volume------->|-----|


  • friske likes this

#29 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 22 November 2014 - 11:56 PM

if i have -c 100m and answer 90m, the 10m not encrypted are usable?
do have sense to have -c 100m -o 100k and answer 100m?

#30 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 23 November 2014 - 12:15 AM

if i have -c 100m and answer 90m, the 10m not encrypted are usable?

 

Yes, they should be never written by ProxyCrypt.

 

 

do have sense to have -c 100m -o 100k and answer 100m?

 

Well, in this case, you are specifying more than maximal size (which should be 99.9 MB). Here, ProxyCrypt will keep only the maximal possible size, that is, 99.9 MB.
This is the same than giving 0 as the size of the encrypted volume because this value automatically selects the maximal size.

 

 

how "the scrypt key derivation function" is safer?

 

In fact, Whirlpool and SHA3 are only a part of the scrypt key derivation function.
This function does all the work: it takes a password, a "salt", and produces a specified number of bytes.
But it requires a PBKDF2 function, which requires a HMAC function, which requires a hash function such as Whirlpool or SHA3.
So, in fact, there is 4 layers, and this is why implementing scrypt is somewhat difficult...


  • friske likes this

#31 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 23 November 2014 - 12:24 AM

Yes, they should be never written by ProxyCrypt.

But it can be written by someone other than ProxyCrypt or have lost a space?
What is the purpose of this uncrypted space?
how "the scrypt key derivation function" is safer?
How do I become a your "fan Reboot" in the forum?

#32 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 23 November 2014 - 01:05 AM

But it can be written by someone other than ProxyCrypt or have lost a space?

 

Yes, another application can use the remaining space, but not at the same time, because once an image file is open, ProxyCrypt prevents other applications to write into the file.

 

What is the purpose of this uncrypted space?

 

You may want to put an encrypted volume into a legitimate file (audio, video, etc.). Depending on how you do that, this can be more discreet than an explicit image file. But I will not tell more than that. ;)

 

how "the scrypt key derivation function" is safer?

 

I edited my previous message.

 

How do I become a your "fan Reboot" in the forum?

 

You mean the "Reboot fan" we can find in some profiles? It depends on the number of "likes" you receive with the messages you post here. But this is rather subjective...


  • friske likes this

#33 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 23 November 2014 - 01:54 AM

&nbsp;

Yes, another application can use the remaining space, but not at the same time, because once an image file is open, ProxyCrypt prevents other applications to write into the file.

But how do I write in the non-encrypted? I have to mount the file with imDisk? no risk of ruining the party encrypted?

You may want to put an encrypted volume into a legitimate file (audio, video, etc.). Depending on how you do that, this can be more discreet than an explicit image file. But I will not tell more than that. ;)

I'm confused. I have to have before a video file for example and then create a part in it encrypted?

You mean the "Reboot fan" we can find in some profiles? It depends on the number of "likes" you receive with the messages you post here. But this is rather subjective...

Now I understood and I became a your fan :)

#34 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 23 November 2014 - 10:03 AM

But how do I write in the non-encrypted? I have to mount the file with imDisk? no risk of ruining the party encrypted?

 

If you mount an encrypted image file directly with ImDisk, Windows will see a volume with random data and will prompt you to format it. And so, obviously, you will lose your data.

 

I'm confused. I have to have before a video file for example and then create a part in it encrypted?

 

Well, this is a possibility... If you don't have already an exact idea on where to put your data, the best option is likely to create a simple image file without any offset.



#35 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 23 November 2014 - 04:56 PM

How work partition crypt? The volume spanning the entire partition? Do it have a command line example? Ue 3 ciphers instead of 1 improve the safety of very in comparison to the performance drop? is more important 3 cipher? The security attack is not directed to hash rather than to cipher?

#36 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 23 November 2014 - 05:55 PM

Before trying to encrypt an entire partition, I strongly recommend to check the disk number and partition numbers with the -l switch.
Once you have a non-formatted partition and you know its number (e.g. 3 on drive 0), you can create your encrypted volume by specifying the disk and partition in place of the image file.
So, in this example: ProxyCrypt32.exe -d 0,3 -c
Of course, don't forget to remove the -c switch the next time.
Be careful if you are using Windows XP: the file systems in use are not protected against writes. If you don't select the correct partition, you can erase your system! That said, there is a risk only when you create the encrypted volume. Once it is created, when you attempt to mount the encrypted volume, ProxyCrypt writes nothing until the password is recognized, and obviously, it cannot be recognized if you select a wrong partition.

Like for image files, you can add an offset and/or use only a part of the partition. It works exactly the same way.

About cascaded ciphers, the security improvement is rather theoretical. If a weakness was found into a cipher, having another layer of encryption might protect the data because they would be still encrypted.
In my opinion, even for paranoids, 3 cascaded ciphers is not very useful...
That said, for now, there is no known usable attack against the 3 ciphers implemented. Serpent has the highest "security margin", so if it is fast enough to your taste, and if performances are an issue, I recommend it.

By the way, about performances, I am still interested by the results of the integrated benchmark on your machine... :) (ProxyCrypt32.exe -bm)

 

Attacks are usually done by either a "dictionary" or a "rainbow table". A dictionary can be used if your password can be found in it, so it's always crucial to choose a good password. You can use any special character, so don't hesitate.
A "rainbow table" should not be usable because a 512-bit "salt" is used.
Attacks against ciphers are very uncommon because it requires to test each possible key (2^256).



#37 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13585 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 November 2014 - 06:32 PM

Attacks are usually done by either a "dictionary" or a "rainbow table". A dictionary can be used if your password can be found in it, so it's always crucial to choose a good password. You can use any special character, so don't hesitate.

 

For NO apparent reason:

http://www.forensicf...wtopic/t=10675/

which includes references to two appropriate XKCD strips and the good ol' bear joke.

 

:duff:

Wonko



#38 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 23 November 2014 - 09:33 PM

By the way, about performances, I am still interested by the results of the integrated benchmark on your machine... :) (ProxyCrypt32.exe -bm)

Excuse me, I was focused on the performance of the hash generation and did not think to those of the cipher.

CIPHER ENCRYPT DECRYPT AVERAGE(MB/s)

AES-Serpent-Twofish 18 17 18
AES 52 52 52
Serpent 42 46 44
Twofish 66 58 62
AES-Serpent 24 23 23
AES-Twofish 27 28 27
Serpent-Twofish 26 26 26
  • v77 likes this

#39 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 23 November 2014 - 11:17 PM

Thanks. The low performance of Serpent, which uses the SSE2 instructions, confirms the poor implementation of these instructions that we see with the scrypt function used for password checking.
Unless to have the AES instructions, in all the benchmarks I have got, Serpent was always the faster one.

Anyway, I lack of ideas for further improving performances, as well for the ciphers than for scrypt, at least without breaking compatibility. So for now, I am afraid that you have to deal with it.



#40 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 28 November 2014 - 02:59 PM

I see that PC write the phisical also if virtual disk crypted is unchanged.
What do you write?

#41 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 28 November 2014 - 03:14 PM

I bet you tried the -v 2 switch... ;)
Except the volume header when it's required, ProxyCrypt writes nothing by itself.
However, the NTFS file system may need to update some data (such as access times). If you format the volume with a FAT file system, you should not see write requests to the volume unless you copy or change a file.



#42 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 05 December 2014 - 12:48 PM

Do is possible to apply this malware protection with imDisk and ProxyCrypt?



#43 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 05 December 2014 - 01:26 PM

Do is possible to apply this malware protection with imDisk and ProxyCrypt?

 

I'm not sure to understand what he's trying to do. Using an encrypted image file mounted as a bootable ramdisk?
Anyway, he seems to rely on the system encryption feature of TrueCrypt, and ProxyCrypt cannot do that. As ProxyCrypt is a user-mode process that relies on a driver (ImDisk or Arsenal Image Mounter), such a feature is definitely not planned.



#44 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 19 January 2015 - 02:57 PM

1.7.3 work fine but i get: Checking password...Warning: cannot lock large buffer into physical memory. Do it is important? Do it is possible to solve it? Do it have a option to use virtual memory instead of physical?

#45 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 19 January 2015 - 10:37 PM

1.7.3 work fine but i get: Checking password...Warning: cannot lock large buffer into physical memory. Do it is important? Do it is possible to solve it? Do it have a option to use virtual memory instead of physical?

 

Thanks for the report. I was not expecting such an issue on Windows XP...

This was the main improvement of the version 1.7.3: in case you dont have enough physical memory, Windows can put on the disk, through the swap file, some parts of the memory used by the softwares, and this includes the large buffers used by ProxyCrypt: a buffer used for the data of the scrypt key derivation function, another one for writing encrypted data on the disk, and another one for the exchanges of data with the imdisk driver (which can contain unencrypted data).
To avoid that, it is possible to lock in physical memory some parts of a process. This was already done in previous versions for critical data such as the master keys, because there is only a few KB to lock. For larger amount of data, we need to do something more, and this is done in the version 1.7.3.

If ProxyCrypt cannot lock one of those large buffers, you get a warning. But in fact, it simply means that it works like before...
Like all the security features of this kind of software, it's merely designed to prevent a possible attack. But as long as you can trust your machine, you should not worry too much about that.



#46 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 19 January 2015 - 11:01 PM

I have 4gb ram and not use swap file.
Where ProxyCrypt save data for virtual memory when "cannot lock large buffer into physical memory"?
I have AWEAlloc disabled.
Do it need to allocate physical memory pro ProxyCrypt and RamDyn?

#47 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 19 January 2015 - 11:39 PM

I have 4gb ram and not use swap file.

 
In this case, you are not concerned by this warning.
 

Where ProxyCrypt save data for virtual memory when "cannot lock large buffer into physical memory"?

I have AWEAlloc disabled.
Do it need to allocate physical memory pro ProxyCrypt and RamDyn?

 
As in previous versions, allocated memory is still "virtual", there is no change about that. Now, the only difference is that this memory can be "locked": in fact, it's merely an extra function (VirtualLock) that tells Windows to not write to the swap file an area of memory.
 

By the way, I just found what does not work with Windows XP: the buffer used for data exchanges with imdisk cannot be locked. This buffer is in fact a "memory-mapped file", so this not very surprising, and it seems there is nothing to do about that.
So, I will just remove this warning for this lock attempt on Windows XP in the next version.

 

 

Edit:

Finally, I was wrong. In short, the issue is that the "minimum working set size" was not increased enough. There is a similar issue with Vista.
Now, everything is working well and a new version will come shortly with some other fixes.


Edited by v77, 22 January 2015 - 01:01 PM.


#48 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 28 January 2015 - 04:12 PM

I have my mp3 in a crypted driver.
When have cpu or hard disk high utilization i I feel a small stutter in audio.
I do not remember this problem with TrueCrypt.
Do it is can to be ProxyCrypt problem?
Do you have tryed this problem?



#49 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 28 January 2015 - 09:03 PM

On my Core i7 2600k, this would be surprising... :)
If there is some data to read, we have first to read the hard drive, then decrypt the data, and finally tell the driver that the data are ready.
In fact, reading the hard drive and decrypting the data are more or less parallelized, but this is still more things to do than just reading the hard drive, and therefore, this can introduce some latencies.
I don't know why you don't have experienced that with TrueCrypt, but as a workaround, you can try, if your software has such an option, to increase the file buffering (preload of data).



#50 zaxie

zaxie
  • Members
  • 2 posts
  •  
    Sweden

Posted 17 February 2015 - 04:17 PM

Hi v77,
I have been playing around with this tool and investing if it is possible to have ProxyCrypt working with dynamic disks as ImDisk Toolkit is working with dynamic memory for ramdisks?

 

What do you think? Is it possible?

My plan is to exchange the software Folderlock from www.newsoftwares.net with ImDisk and make it portable.

But the last piece is that folderlock has the ability for encrypted dynamic storage.

 

Thanks in advance.







Also tagged with one or more of these keywords: arsenal image mounter, imdisk, proxy, encryption, volume

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users