104 replies to this topic

[v77]

Last version.

 

This does not tell me if the issue is related to the last version or not. Did you check the same image on the same system with the previous version?

 

 

I have used same image in win7 from xp.

"Windows has checked the file system and found no problems"

 

And this does not tell me if the new image file is identical to the original. A non-reported error could maybe occur while the file is copied (I already seen that with some USB sticks).
Did you use a file checker to check that before mounting the image?

[friske]

I have formatted and solved.

[v77]

Version 1.9.0
- Arsenal Image Mounter: replaced .NET ArsenalImageMounterControl.exe by Win32 aimapi.dll

 

This new version only affects users of Arsenal Image Mounter.
It no longer uses ArsenalImageMounterControl.exe but instead takes advantage of a new Win32-based API, which removes the .NET requirement. See description page for the links and required files.

[bilou_gateux]

Latest version of Arsenal Image Mounter drivers and command line tools as described:

 

 

If you need to create encrypted spaces which can be partitioned like an ordinary hard drive, ProxyCrypt is also compatible with Arsenal Image Mounter. The driver, aimapi.dll and imdisk.cpl that are packed here, are required.

 

OS version: [Windows XP Professional with SP3]

 

ProxyCrypt32.exe -f 32M -c 32M

Size:

0m

encryptikon Algorithm

1: AES

Password hash

1: Whirlpool

Password

******

******

 

ProxyCrypt32.exe has encountered a problem and needs to close. We are sorry for the inconvenience.

 

 

command line output
 

Creating master keys...

Hashing password...

Volume created successfully.

Encrypted volume of 33 550 336 bytes at offset 4 096.

 

[v77]

Thanks for your report. I reproduced the bug and did a few other tests. The bug affects only ProxyCrypt32, no matter the system and its bitness. But I don't know yet whether it comes from my code or the one of the .dll. Will check that right away.

[v77]

The version 1.9.1 fixes the crash with ProxyCrypt32 and the new API of Arsenal Image Mounter. It was caused by an incorrect call to the API functions.
There is no change for the 64-bit version.
Note that Olof also has updated aimapi.dll.

[StopSpazzing]

 

 

Hi StopSpazzing,

A new version of ProxyCrypt was released, this is one of the best options for secure disk encryption available. Especially now that TrueCrypt is compromised.

Check it out: http://reboot.pro/fi...412-proxycrypt/

-- Nuno

 

Sorry @Nuno but you are completely incorrect. The original devs for TrueCrypt for reasons unknown left the project and claimed it was insecure. Recently, if you have kept up with the news, a 3rd Party has verified that there is no exploits/issues other than bugs with the project, so stating that TrueCrypt is compromised is false. I wouldn't use TrueCrypt anymore personally since I have moved on and because it is no longer being updated.

 

The REAL alternative to TrueCrypt is VeraCrypt. Supports All versions of OS's unlike this program listed here named ProxyCrypt which sounds like a VPN/Proxy tool, which it is not. I have nothing against this author or this program but a real replacement for any security tool that supported ALL OS's is one that supports ALL OS's.

 

https://veracrypt.codeplex.com/

Edited by StopSpazzing, 29 September 2015 - 12:58 AM.

[v77]

ProxyCrypt which sounds like a VPN/Proxy tool, which it is not.

 

Yes, it's a very bad name that brings confusion about the purpose of this software. This is exactly why I don't want to change it.

Besides, I wonder from where comes the recent rise of downloads of ProxyCrypt...

[Wonko the Sane]

Some loosely related news:

http://www.itworld.c...compromise.html

 

Two vulnerabilities were found in Truecrypt (but relax they were already patched in Veracrypt).

 

Whether the original Authors knew about these vulnerabilities or if they knew of some other ones, the real issue here seems to me that the "independent audit" gave a false sense of security.

 

Wonko

[friske]

i launch proxycrypt at win7 x64 boot.

Since I replaced the CPU, not always, but sometimes it does not just launch proxycrypt.exe the system restarts automatically.  What can be?

[v77]

i launch proxycrypt at win7 x64 boot.

Since I replaced the CPU, not always, but sometimes it does not just launch proxycrypt.exe the system restarts automatically.  What can be?

 

AFAIK, there is nothing in the code of ProxyCrypt that can shutdown or restart the system. So, even with a bug, that would be surprising.
Can you find something about the cause of the restart in the event log?

I suspect either a driver issue (when it is loaded) or an instability of your CPU. OCCT can be good to find something about the CPU.

[friske]

If i use:

%ComSpec% /C "ProxyCrypt64.exe"

is sure as:

ProxyCrypt64.exe

?

[v77]

If i use:

%ComSpec% /C "ProxyCrypt64.exe"

is sure as:

ProxyCrypt64.exe

?

 

There should not be any problem. ProxyCrypt uses the console that the system assigns to it, no matter the way it was created, and can also work if the console is closed (once the volume is mounted).

[friske]

What happens if I do not unmount the crypted driver before that hibernation?

Data and password are accesible from hacher?

The hiberfil.sys is every write in the same disk sectors or it chance at any rewrite?

[v77]

What happens if I do not unmount the crypted driver before that hibernation?

Data and password are accesible from hacher?

 

Password and master keys are wiped as soon as the volume is mounted. But it remains the precomputed keys that are directly used by each encryption algorithm.
So, yes, an attacker could use these precomputed keys, which are written into hiberfil.sys, to decrypt your data.

That said, access to this file is completely forbidden. So, the only way, from a running system, to access these data would be to open the C: volume itself, locate hiberfil.sys, and then locate the keys in this file. But opening a volume requires administrative privileges.

All this is not specific to ProxyCrypt. You should never use the hibernation if you use an encryption tool.

 

The hiberfil.sys is every write in the same disk sectors or it chance at any rewrite?

 

If the file is never deleted nor resized, you can only expect that Windows will overwrite sensitive data at the next hibernation or shutdown/fast startup. But here, there is nothing guaranteed.

So, if you have mistakenly used the hibernation, your best option is to remove hiberfil.sys by disabling the hibernation (powercfg -h off in an elevated command prompt), and then wipe the empty space of C: with another tool, such as the dedicated tool of CCleaner, or Eraser.

[friske]

If i change password with -cp parameter to a new and again i change to old password the "precomputed keys" change every or return to old value?

It Have correspondence between "precomputed keys" and password?

[v77]

If i change password with -cp parameter to a new and again i change to old password the "precomputed keys" change every or return to old value?

It Have correspondence between "precomputed keys" and password?

No, precomputed keys are derived from the master keys, which are stored in the volume header and cannot be changed.
Changing the password only encrypts the header with the new password, but it does not change its content (except the salt).

Some times ago, I received a request for an option that would allow to change the master keys. But such a feature implies to re-encrypt the whole volume in place, which is very risky in case of something stops the process.

So, for now, if you want new precomputed keys (or master keys), you need to create a new volume (which can have the same password).

[friske]

Other that password, the content of crypted driver is only saved in the file or in the hibernation mantain in memory?

[v77]

Other that password, the content of crypted driver is only saved in the file or in the hibernation mantain in memory?

"crypted driver"? Do you mean "crypted drive"?
Encrypted data should not be an issue, since they are already encrypted.

About unencrypted data, well, the first question would be to known whether Windows writes its file cache into hiberfil.sys. If yes, you can have plenty of unencrypted data written in this file.
If no, it remains a 1MB buffer used by ProxyCrypt to communicate with the imdisk driver. This buffer can contain up to 1MB of unencrypted data. Of course, it is wiped when the volume is dismounted, but in the case of an hibernation, it can be written into hiberfil.sys.

[v77]

ProxyCrypt is now compiled with MinGW 5.3.0 (instead of 4.7.4). Performances are globally slightly better (with a few slowdowns though), depending on the version (32 or 64-bit), the algorithm and the hardware.
Thanks to this new compiler, security is also improved on the 64-bit version with a better use of ASLR (--high-entropy-va).

This release might be one of the last 1.x versions. I am planning to create a 2.x version which will break the compatibility with the volumes created with the 1.x version.
The reason is that I think to replace scrypt by another key derivation function, Argon2. Argon2 is the winner of the Password Hashing Competition and seems to be currently the best possible choice for a key derivation function.
Of course, in this case, the last 1.x version will remain permanently available for download. It will simply be no longer supported.

Scrypt is still very secure, especially in the way it is used in ProxyCrypt, but its efficiency can be reduced in some ways, and it is not protected against timing attacks (but such attacks are very unlikely).
One of the guidelines of ProxyCrypt is the smallest possible size of executable. If I choose to keep a legacy algorithm, the executable will be much bigger and this policy will be broken.

Of course, I also could simply keep a "good enough" algorithm (scrypt), but I want the best possible algorithms.
I can also use this opportunity for doing something about the time required for hashing the password, which can currently be rather long on some machines.

The only remaining point is the choice of the hash algorithm. Argon2 is provided with Blake2, which is an improved version of Blake, which was one of the finalists of the NIST hash function competition. But according to the paper, Argon2 can be used with other hash functions.
If I had to choose one, I would keep Whirlpool, because unlike Blake, it is not related to the NIST. However, Blake2 is a modified version of Blake, and therefore no longer related to the NIST. So, even in a political point of view, using SHA3 would be valid.

[friske]

Do it have risk if i use fast shutdown hibryd?

[v77]

Do it have risk if i use fast shutdown hibryd?

No. Like with a full shutdown, the hybrid shutdown closes the user session by sending the WM_ENDSESSION message to all top-level windows. ProxyCrypt processes this message by using an invisible window, and uses it to dismount the volume.
Moreover, the hybrid shutdown only writes onto hyberfil.sys the kernel data, but ProxyCrypt is a user mode process. Therefore, none of its data should be written to the hard drive.

[friske]

Password and master keys are wiped as soon as the volume is mounted. But it remains the precomputed keys that are directly used by each encryption algorithm.
So, yes, an attacker could use these precomputed keys, which are written into hiberfil.sys, to decrypt your data.

Do it is difficult to locate and use the precomputed keys do decrypt a drive without password?

Do it have a an actual example?

[Wonko the Sane]

Do it is difficult to locate and use the precomputed keys do decrypt a drive without password?

Do it have a an actual example?

1) define "difficult"

2) no, security through obscurity is sometimes a good thing, if an example was given than the answer to #1 would become: Nahhh, just follow the example.

 

Wonko

[v77]

Do it is difficult to locate and use the precomputed keys do decrypt a drive without password?
Do it have a an actual example?

Inside hiberfil.sys? Well, it would require several things:
- To access this file, which is possible only with a direct access to the C: volume for locating and copying this file, or by copying the whole C: volume elsewhere, mounting this volume and then accessing hiberfil.sys. Anyhow, this requires administrative privileges.
- To know how Windows writes its data into hiberfil.sys, or find a way to locate the data of ProxyCrypt.
As I never tried this kind of thing, I cannot say more than that.

An example of a practical use of hiberfil.sys to do this kind of attack? I have never read that someone would have tried, so I can only say that it's possible.