AESCrypt - Very slow file encryption

[DinhoPereira]

Dear, I'm using AESCrypt to keep the encrypted music and videos in my Player.

I used the following function to encrypt all media directory

Code: Select all

public static void encryptMusic(){
		String args1[] = new String[4];
		args1[0] = "e"; // encrypt
		args1[1] = "pass";
		AESCrypt aes;
 
		File filecryptss = new File("/home/dinho/midiasOLD");
 
		File fList[] = filecryptss.listFiles();
 
		for ( int i = 0; i < fList.length; i++ ){
			args1[2] = "/home/dinho/midiasOLD/" + fList[i].getName();
			args1[3] = "/home/dinho/midias/" + fList[i].getName();;
			try {
				aes = new AESCrypt(false, args1[1]);
				aes.criptografar(args1);
			} catch (UnsupportedEncodingException e2) {
				// TODO Auto-generated catch block
				e2.printStackTrace();
			} catch (GeneralSecurityException e2) {
				// TODO Auto-generated catch block
				e2.printStackTrace();
			};
 
			System.out.println("Arquivo criptografado: " + fList[i].getName()); 
			System.out.println("Deletando arquivo: " + fList[i].getName() + "..."); 
			fList[i].delete(); // deleto o arquivo para não ocupar espaço
 
		}
 
		System.exit(0);
 
	}

At run time, do the decryption putting a new file as tmp just to run.

Code: Select all

String args1[] = new String[4];
args1[0] = "d"; // decrypt
args1[1] = "pass";
args1[2] = "/home/dinho/midias/video.avi";
args1[3] = "/home/dinho/midias/tmp_video.avi";
AESCrypt aes;
try {
aes = new AESCrypt(false, args1[1]);
aes.criptografar(args1);
} catch (UnsupportedEncodingException e2) {
// TODO Auto-generated catch block
e2.printStackTrace();
} catch (GeneralSecurityException e2) {
// TODO Auto-generated catch block
e2.printStackTrace();
};

After running the tmp file, it is removed from the directory.

The problem I face is that when selecting a video file, depending on size, can take up to one minute only to decrypt.

The question is:
Is there a way to decrypt without the need to create a new physical file?
I'm at least on the right track or is there a better way to do this whole process?

[paulej]

Why are you creating the temporary file? Why not just encrypt or decrypt the file directly? Creating a temporary file does seem like an unnecessary waste of time.

[DinhoPereira]

Hi paulej, thanks for your answer
I would like to use without creating a temporary file. Do you have an example?
Tks

[paulej]

Where is the code creating the temporary file?

[DinhoPereira]

This:

Code: Select all

    String args1[] = new String[4];
    args1[0] = "d"; // decrypt
    args1[1] = "pass";
    args1[2] = "/home/dinho/midias/video.avi";
    args1[3] = "/home/dinho/midias/tmp_video.avi";
    AESCrypt aes;
    try {
    aes = new AESCrypt(false, args1[1]);
    aes.criptografar(args1);
    } catch (UnsupportedEncodingException e2) {
    // TODO Auto-generated catch block
    e2.printStackTrace();
    } catch (GeneralSecurityException e2) {
    // TODO Auto-generated catch block
    e2.printStackTrace();
    };

[DinhoPereira]

After that, I use the VLCJ to run the file: / home / dinho / medias / tmp_video.avi

[paulej]

Oh! Sorry... now I understand.

The way AES Crypt is presently written, you must decrypt the entire file before you can do anything with it. So you are correct: if the file is huge, it will take a little while to decrypt before you could start video playback.

You could modify the code to make it work more like a streaming mode, though. If you look at the function that does the decryption, you will see it read 16 octets and decrypt those, write them to the new file, and then read the next 16 octets. If you were to interface with a streaming video application, you could read as many octets as you need using one thread and store those in a buffer and allow those bytes to be consumed by the video playback function. As the buffer starts to empty, your decrypting thread could continue to read more octets and decrypt them.

A ring buffer would work well for that kind of application. However, you do need to take care to ensure that you do not have buffer under-runs, otherwise video playback will be jerky. Careful management of the ring buffer is important. (Of course, you could use several techniques to do this, but I like ring buffers; they are dangerous if not handled correctly, though.)

The bigger challenge I see it interfacing with the video playback function. If it would read from STDIN, you could do something like this:

aescrypt -d -ppassword file.aes -o - | vlcj -

I do not know what vlcj is, but hopefully that gives you an idea of what I had in mind. Still, if the player operates faster than the decryption, you'll have a buffer under-run issue again. So, you do need to ensure that you always have enough video data ready to play. Given that just reading from STDIN like above presents a race condition, I would prefer to inferface with the playback buffers directly to ensure the player does not start until it has enough media (say, 10s or 20s or more) and then have a thread decrypting the AES file, filling the playback buffer so it never gets empty or too full.

Paul