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.