Safety through open source

I have received a number of concerns from users about the safety of the AttachéCase when making it open source.

While there is no such thing as "absolute safety", I believe that it is safer to open up for the following reasons.

To begin with, the encryption algorithm is open.

To begin with, the specification of AES ( Rijndael ), the cryptographic algorithm used in the AttachéCase, is open and is widely used all over the world.

In short, a cryptographic algorithm is nothing more than a procedure for encrypting data with a secret key. Therefore, if the private key is well managed and the procedure is used correctly, the encryption is safe.

The important thing here is to handle the "key (password)" for the encryption. As long as the password is in your possession, you are safe.

Of course, in the future, vulnerabilities may be discovered in AES, just as they were in other cryptographic algorithms. This is when a security hole is discovered that allows any password to be reversed by exploiting the vulnerability and using a machine with huge computing power to do the reverse calculation.

However, it still has the advantage of being open to the whole world, which will be allowed for immediate disclosure of information and immediate action.

More transparency

Because the source is exposed to everyone's eyes, there is a greater chance that potential vulnerabilities outside of the encryption algorithm, or memory leaks that could affect the operation of the entire PC, will be discovered and fixed.

Several memory leaks and other problems have already been discovered, and improvements and fixes are being made with each version upgrade.

Concerns that a backdoor may have been installed

By becoming open source, you are free from concerns about backdoors and malicious scripts.

Even now that it's open-sourced, I still build the AttachéCase on my own PC and finish the installer before releasing and distributing it.

I develop my software with the users in mind, and I swear to you that I do not install viruses, backdoors, or intentional bugs in my software (of course, it would be a crime to do so).

However, there are some people who think that even that is a bit unbelievable. This is especially true for government agencies that handle sensitive information, major corporations. And development companies that want to incorporate it into their systems.

In that case, since it is open source, you can ultimately download the source to your own hands, check for such malicious parts, and then build it yourself. As long as you have a development environment, you should be able to build the same thing.

Conclusion

Therefore, I believe that making the "AttachéCase" open source will go in the direction of increasing transparency and safety, rather than making it less safe.

Cryptographic algorithms

The "AttachéCase" uses AES (Rjindael) as the encryption algorithm.

Rijndael is a new cryptographic algorithm developed by Belgian mathematicians Joan Daemen and Vincent Rijmen, and selected by the U.S. Government's National Institute of Standards and Technology (NIST) in October 2000 as the next-generation Advanced Encryption Standard (AES). It was open to the public, and other finalists include "Twofish", "RC6", "MARS", and "Serpent".

Until then, a cryptographic algorithm called DES, developed by IBM, was widely used, but with the remarkable improvement in computer performance and the progress in the analysis of the algorithm, its strength became unreliable. It became necessary to adopt a new cryptographic algorithm. This is where AES (Rijndael) came in.

One of the features of "Rijndael" is that the key and block length can be specified in 128, 192, or 256 bits, respectively, and can be further extended. In AES, only the block length is fixed at 128 bits.

In addition, instead of using the "Feistel network" for bit conversion during encryption, which is a common algorithm used in other finalist encryption algorithms, it uses three different proprietary conversions, such as the "SPN" structure, to achieve strong encryption.

AES is based on the principle that the specification is open to the public. As a result, it is not only free for anyone to use and freely incorporate into their sources, but also has a proven cryptographic strength, as it is constantly verified by researchers around the world (even if vulnerability is found, the information is immediately available).

In addition, AES is designed to run on a wide variety of platforms, making it a very fast and powerful algorithm.

It has been more than 20 years since it was officially adopted in 2000, and I hear that in the U.S., there has been a significant shift from DES to AES. In Japan as well, AES is increasingly being incorporated into software and other applications, and its track record is being proven.

Information about AES (Rijndael) can be obtained at the following sites:

Advanced Encryption Standard (AES) - NIST
https://www.nist.gov/publications/advanced-encryption-standard-aes

BrianGladman/aes: AES code - GitHub
https://github.com/BrianGladman/aes

The source code to run on various other platforms can be found below, if you are interested.

AES implementations - Wikipedia
https://en.wikipedia.org/wiki/AES_implementations

Also, today is in this age of the broadband, but exporting encryption algorithms (or software containing them) to foreign countries may violate international treaties.

Although the regulations have eased considerably compared to the past, there is still a possibility of being legally punished for exporting goods for military purposes, etc. to terrorist supporting countries recognized by the U.S. and other countries. This is probably only the case if you do it on your own with a clear intention, but just in case, please be careful...

By the way, "State Sponsors of Terrorism" as of 2021 is...

The four countries are "Iran", "Syria", "Cuba", and "North Korea".

Cryptographic mode

In the older version (ver.1.*), AttachéCases were encrypted using a method called "ECB (Electronic CodeBook) mode". This method simply encrypts each block and writes it directly to the encrypted file. The diagram is as follows.

The same file and the same password will generate an encrypted file with exactly the same contents. So, this method is easy to decrypt block by block by its encryption characteristic.

However, it cannot be denied that there is a weakness in "ease of verification" to some extent. Therefore, from ver.2 later, we decided to encrypt using a method called "CBC (Cipher Block Chaining) mode". The simple diagram is as follows.

The first step is to generate a block of data using random numbers, called the "Initialization Vector".

This is written to the encrypted file after an exclusive logical OR (XOR) with the data block.

In other words, based on the initial random data, the encrypted data is generated as if the data is being chained together and rolled up. As a result, even if the same file is encrypted with the same password, the contents will not be the same each time, because a random value is given at the beginning. This eliminates the "ease of verification" weakness by the encryption characteristic.

So how can we decrypt it by giving it a random number first? It is as shown in the following figure.

The first block of data, which is a random number, is also written to a file, so it can be decypted.

So, even if the file contains a block of data with that random number, won't it be used as a clue for analysis?

No, you can't. This is because even if the random data is visible, it will not be useful for any analysis unless the encrypted block data is first analyzed and decrypted. The random number data cannot be used as a starting point to unravel and analyze the chain.

Key derivation according to RFC2898

Starting from Version 3 or later of the AttachéCase, the specification has been changed to derive the password key of the data and the initialization vector (IV) by key derivation based on RFC2898.

For example, you can specify a password string of up to 16 characters, but if you use only one character, "a", you will leave 15 characters empty.

Therefore, it is more secure to generate a random string of characters from the input password and encrypt it with a proper 16-byte fill.

Specifically, based on "PKCS #5: Password-Based Cryptography Specification Version 2.0", it outputs, in order, the derivation, key, and initialization vector after 1,000 iterations of password-based key derivation with a random Salt mixed in.

However, even with this countermeasure, you will still be helpless against brute force password attacks. It is recommended that the password string be as long as possible.

SHA-1 to SHA-256

"SHA" stands for "Secure Hash Algorithm", which is a message digest algorithm. It is an algorithm for collapsing large data into small data of fixed length.

It is used to check the validity of a file, or to compare passwords by storing their message digests instead of storing them as they are, for example, since the same data will always be the same condensed data.

If you edit the file even slightly (even by changing one byte), you will get a completely different message digest. It's like a "fingerprint" of the file, generating a unique value.

Of course, any large file (data) will be collapsed into smaller data, so it is not entirely possible to deny that different data will have the same result, but the possibility of this happening is so small that it is not considered a practical problem.

In the AttachéCase, SHA-1 hashes have been used only for Password files. Recently however, the vulnerability of SHA-1 has recently been pointed out, and although some say that the impact of the vulnerability is insignificant. And it is not a problem in an AttachéCase use case, there has been a recent shift to more secure SHA-256 and SHA-3. Therefore, we have decided to use SHA-256 as the hash used in the Password file for AttachéCase.

Therefore, files that were encrypted with Password files in the past cannot be decrypted from ver.3. Please decrypt the past files with the older version and then encrypt them again with ver.3 or later.

Compression algorithms

AttachéCase uses the zlib library. NET Framework 4.5, which uses "DeflateStream" for compression, so it seems that zlib is selected internally.

zlib is a library of compression algorithms used in zip and gzip, and is available for free. It has a high compression ratio (said to be higher than lzh, but it depends on the contents of the data) and is fast. The most important advantage is that you do not need archiver DLLs and can prepare your own compression functions.

Incidentally, zlib compression is also used in the graphic data format "PNG".