Decrypt files without AEScrypt?!?

[ioscrypt]

Hello,
I just bought the full version of AEScrypt and the first thing I tested, was to decrypt a file that I encrypted with AEScrypt.

The normal way to this, is OpenSSL.

In short, this does not work:

bad magic number

This is very bad

What can I do?

[paulej]

AES Crypt doesn't have any relationship to OpenSSL and you can't decrypt files encrypted with AES Crypt using that tool.

To decrypt the file, you need to use AES Crypt or software that supports that file format. You can download free versions for most platforms from aescrypt.com.

[ioscrypt]

Thanks for your fast reply.

But, to be honest, this makes it a bit difficult to use the app

I mean, there is no guarantee that AESCrypt will always exist or may be installable on whatever platform i use in 10 or 20 years.

Still, i surely would like to decrypt any file ...
I mean, it is AES - there is lots´s of software that can handle AES encryption.

Or to ask this in a different way:

Is there a way to modify the binary output, so that some other app can decrypt them?

I see this:
$ od -a test.jpg.aes | head -4
0000000 A E S stx nul nul em C R E A T E D _ B
0000020 Y nul a e s c r y p t sp 3 . 0 . 9
0000040 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul


On a OpenSSL file that:
$ od -a test.jpg.aes
0000000 S a l t e d _ _ $ % ~ nul Z fs c b

Some part of the file needs to be "pure AES", so that any other app should be able to decrypt ... i hope

[paulej]

Thanks for your fast reply.

But, to be honest, this makes it a bit difficult to use the app

Not sure how it is made somehow more difficult to use than the next one.

I mean, there is no guarantee that AESCrypt will always exist or may be installable on whatever platform i use in 10 or 20 years.

Sure there is: the source code is available. No matter if I'm dead, Packetizer is gone, etc. you will have the source in hand. Source is also posted to GitHub.

Still, i surely would like to decrypt any file ...
I mean, it is AES - there is lots´s of software that can handle AES encryption.

AES is a standard that defines how to encrypt a 16-octet block of plaintext. To produce a tool that encrypts a file, one needs more than just the cipher itself. For example, let's say you have a file with 96 octets of zeros on the front followed by 16 octets of non-zero values. If you run that through AES as-is, nobody can tell what the data is, but cryptonalysis on the file would likely suggest much of the file is the same. I could definitively tell you that the first 6 blocks are repeated values. I can't tell they're all zeros, but I can tell the blocks are identical. That's bad, so we need a block cipher mode that does not reveal such information. There are several from which to chose (we use CBC in AES Crypt).

Or to ask this in a different way:

Is there a way to modify the binary output, so that some other app can decrypt them?

I see this:
$ od -a test.jpg.aes | head -4
0000000 A E S stx nul nul em C R E A T E D _ B
0000020 Y nul a e s c r y p t sp 3 . 0 . 9
0000040 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000060 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

On a OpenSSL file that:
$ od -a test.jpg.aes
0000000 S a l t e d _ _ $ % ~ nul Z fs c b

Some part of the file needs to be "pure AES", so that any other app should be able to decrypt ... i hope

So you can see immediately that the OpenSSL and AES Crypt file formats are different. Neither are wrong, but each employs AES in a way to produce a secure output. I will assume you created that file by not using ECB mode with OpenSSL, because that would be horribly insecure. And if that doesn't make sense (and it doesn't to most people), that's why AES Crypt doesn't offer options: it does encryption in one of the most secure modes available, and with the strongest key possible for AES. The average user cannot and should not be expected to know or understand that. It should just work.

You cannot simply convert the file from one to the other. You could if you had the keys, of course, but that basically means you're just decrypting and re-encrypting. That's a bit pointless. There are many tools out there that encrypt using AES. There is no one standard way to do it. I wrote AES Crypt to tackle this very problem, even taking the step to document the file format so that anyone could use it. There have been a lot of third-party developers who have written AES Crypt compatible code in lots of languages and platforms, some of which are linked to from aescrypt.com.

[ioscrypt]

OK.

Thank you very much!

For the effort, for the work and for the support

I compared openssl with aes-256-cbc and AEScrypt on a 512 Byte file full of zeroes.

-rw-r--r-- 1 root root 512 Apr 25 20:44 512zeroes
-rw-r--r-- 1 root root 544 Apr 25 20:45 512zeroes_openssl.aes
-rw-r--r-- 1 root root 805 Apr 25 20:56 512zeroes.aes

openssl adds 32 bytes in the filesize.
Assuming that the first 32 bytes contain some "openssl" stuff, i parted the file in two:

-rw-r--r-- 1 root root 512 Apr 25 21:00 512zeroes_openssl.aes.data
-rw-r--r-- 1 root root 32 Apr 25 21:00 512zeroes_openssl.aes.head

Then i wanted to do something similar with the output from AEScrypt, buttttt this file was 805 bytes instead:

-rw-r--r-- 1 root root 805 Apr 25 20:56 512zeroes.aes

I read the page about the AES File Format, and it seems that i can only drop the last 33 bytes and then use the remaining 512 bytes as the encrypted text:

# dd if=512zeroes.aes of=512zeroes.aes_data ibs=1 obs=1 skip=$(( 805 - 512 - 33 )) count=$(( 512 + 33 ))
545+0 records in
545+0 records out
545 bytes (545 B) copied, 0.00189006 s, 288 kB/s

-rw-r--r-- 1 root root 545 Apr 25 21:15 512zeroes.aes_data

Then i tried to combine the openssl header with the AEScrypt data:

# cat 512zeroes_openssl.aes.head 512zeroes.aes_data > test.aes

And tried to decrypt with openssl:

# openssl enc -d -aes-256-cbc < test.aes > test
enter aes-256-cbc decryption password:
bad decrypt
17813:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:323:

Sad thing

Then again, i have Nooooo idea about the file format of openssl

[paulej]

In AES Crypt, there are two separate 256 bit IV and keys used. The message is also authenticated using HMAC-SHA256. There are actually two separate decryption steps due to the way the file is created. Most likely, OpenSSL doesn't do that. But, I'm not familiar with their file format, either.

I don't see the motivation for converting between the two, honestly. AES Crypt is free open source and available in nearly every platform. Where it's not, it could be easily ported.

[ioscrypt]

Now.
What to say.

When i can encrypt and decrypt on different platforms with different tools, i have more freedom and more security.

Also, i can see that things are compatible and, when the size of the files is close enough, i can be sure that neither software added some own keys to be able to decrypt my content!

I could possible check this myself, when compiling for Linux or Windows, but i cannot create my own version on an iOS app!
And even if, this is not the same version as from the App store.

So, the only way to be sure that everything is fine, is to compare encryption and decryption by different tools and compare the resulting size of files.

And no, there is no other way - for no other person, only if you are able to compile yourself and manually check the source.
But i cannot check the source of the binary from the App store.

So, i can never now, if some additional decryption method was added.

In seeing that the resulting files are much larger than those from OpenSSL, i just got more suspicious, to be honest.
I am still trying to understand the file-layout of AESCrypt output and seek ways to make sure that no other key was added - but so far, i was not able to extract the pure encrypted data and decrypt it with something else.


Please don´t take this personal!!!

[paulej]

When i can encrypt and decrypt on different platforms with different tools, i have more freedom and more security.

And you can do that with AES Crypt. There are tools written by several different people in a number of different languages. There is C code on Linux, C++ on Windows, Java code for several platforms, at least two PHP implementations, and at least one in python. That's certainly more freedom, but I don't understand the argument of more security. If one employs AES with a 256-bit key properly, the security is the same regardless of the tool.

Also, i can see that things are compatible and, when the size of the files is close enough, i can be sure that neither software added some own keys to be able to decrypt my content!

Given the AES Crypt file format is documented and the source is entirely open, you can also see that.

I could possible check this myself, when compiling for Linux or Windows, but i cannot create my own version on an iOS app!
And even if, this is not the same version as from the App store.

The fellow who wrote the iOS version created his. You could do the same. Not sure how this is an argument, either.

So, the only way to be sure that everything is fine, is to compare encryption and decryption by different tools and compare the resulting size of files.

I really don't understand the issue. You can encrypt with any one of the various AES Crypt-compatible tools and decrypt with the others to see that the file format is correct. Even without taking that step, even before you encrypt the file you can figure out exactly how large the file will be if size gives you any kind of comfort. But, that's definitely no way to measure security.

And no, there is no other way - for no other person, only if you are able to compile yourself and manually check the source.
But i cannot check the source of the binary from the App store.

Indeed, but that's because that version to which you refer is a commercial product. Because one person created commercial software that is compatible with AES Crypt, you are unhappy with AES Crypt? It is free open source software, after all. People can do whatever they wish with it, including creating commercial products.

So, i can never now, if some additional decryption method was added.

You can never what? I'm guessing you're concerned that when we update the file format (which I would like to do), the commercial versions will be not be updated, too. I would be reaching out to all those I know who have created AES Crypt-compatible versions to coordinate a major release. But, even if some didn't want to update, the Linux and Windows code will always maintain backward compatibility with any older file format. The Java version, for example, does not support version 0 of the file format. It would be easy to add, but it has apparently just not been important to users of that software. But, it does support the latest version.

In seeing that the resulting files are much larger than those from OpenSSL, i just got more suspicious, to be honest.
I am still trying to understand the file-layout of AESCrypt output and seek ways to make sure that no other key was added - but so far, i was not able to extract the pure encrypted data and decrypt it with something else.

The Linux version and Windows versions produce a file that is exactly 292 octets larger than the original file. If the original file is 2 octets, yes that would be "much larger." However, when encrypting a 600K file, for example, that footprint is insignificant. As for what is in those 292 octets, that is all specified here: https://www.aescrypt.com/aes_file_format.html.

For the latest file format (unchanged for several years):

• Three octets at the start of the file contain the letters 'AES'
• One octet to indicate the file version
• There is then one octet with the value 0x00
• Two octets to indicate tag/value extensions added in the header. This is optional, though a length of 0x0000 would need to be indicated. The Linux version of AES creates one tag that indicates the release version used to create the file. Then there is a 128 octet 0x00 "empty" extension that allows one to add of change these extension values without re-creating the whole file. This is non-secure metadata that has not impact on the contents of the file and is intended for use by file browsers, storage systems that want to identify files in some way, etc. In total, current AES Crypt on Linux is consuming 156 octets for these (including the length octets)
• 16 octets for an initialization vector (used for CBC operation) used to protect the encryption key
• 48 octets for a second initialization vector and key that is encrypted with AES and used to encrypt the balance of the file (this exists so that no two files, or even the same file encrypted twice) uses the same IV and key. This is a security feature.
• 32 octets for an HMAC to authenticate the encrypted IV and key to ensure if was not altered
• Then there is the encrypted file (with the length depending on how many octets there are to encrypt; can be zero)
• One modulo octet that indicates how many octets in the last cipher block is plaintext
• 32 octets for the HMAC to verify that the encrypted contents were not altered

So, total of all the octets (except for the actual encrypted file itself) is 292 octets. If you encrypt a zero-length file on Linux, that is the length of the output (from the current release). If you encrypt a file that is 1 octet in length, you'll see the file is 308 octets. The reason is that all encryption is done in 16-octets blocks. Thus whether you encrypt a file length of 1, 2, 3, .. 16 octets, the file sizes are all the same. If it's 17 octets, that will require putting data into a second 16-octet block, so you'll see the output 16 octets larger than a 16-octet file. (This is a product of using AES with the CBC mode.)

Please don´t take this personal!!!

I don't take it personal. However, I am truly baffled how you can be worried about the security of AES Crypt merely due to the fact you cannot understand why the file size varies. Hopefully the above extended explanation helps a bit. I also don't have a solution to the fact that the iOS and Android versions are both closed source. I've interacted with both developers and they both seem like very honest people. And it's not hard to see that they're producing correct products, because you can take the output those versions produce and decrypt them on Linux or Windows. And, you could modify that software to inspect things like the inner-encryption IV and key, look at the tags, etc. You'd have to modify the code to do that, but it's certainly something one can do since the file format and code are all open source.

[ioscrypt]

I think, i did not clearly state my concern and my situation.

I know AEScrypt soley from iOS.
And only the iOS version is my concern.
Originally, i did even think that there is ONLY the iOS version of this software!

Also, i did not realy understand that the iOS version is from "some" person, i thought YOU are this person!

I seek a way to make sure, that i can trust the iOS binary, as this is what i have and need to use.

As i cannot build an iOS version myself, now i understood that i could check the integrity of the iOS binary in such a way:

Compile any other version myself, checking the source closely and make sure that it only does what it should do.
This may very well mean to check the file format as well.

And then, when i am sure that i can trust this version, i can run some simple tests of encrypting and decrypting things between this and the iOS version, comparing the output.

After that, i could start to trust the iOS version.

Right?
Any other idea?

And sorry for the stress

[paulej]

Yeah, most packages are written by different people. I wrote the first version in C++ for Windows. I had a heavy hand in the Linux version. Somebody else did the iOS, another did Android, another C#, another (two different people) did PHP versions, another did Java, and yet another did Python. It has been a pretty successful, though disjoint activity over the years. Most authors put their names, business name, and/or contact info in their code or web site. You can see it here for the iOS version:
https://itunes.apple.com/us/app/aescrypt/id791675640

If you really want to test that the files are right, then just encrypt a bunch and use any other version of the software on any platform to verify they decrypt properly. I'm pretty sure you'll find they do. I've never had anyone report an interoperability issue.

BTW, the iOS author hangs out on these forums. His user ID is jasonf.