Tag Info

Hot answers tagged

20

(Disclosure: I'm the author of the functionality that you're asking about (good question!).) Ubuntu's Encrypted Home Directory feature uses eCryptfs as the filesystem encryption technology. eCryptfs is a layered filesystem built directly into the Linux kernel. It mounts one directory on top of another. The top directory is really just a "virtual" ...


13

According to 7-Zip, Use ZipCrypto, if you want to get archive compatible with most of the ZIP archivers. AES-256 provides stronger encryption, but now AES-256 is supported only by 7-Zip, WinZip and some other ZIP archivers. So really there is some balance to be played with. Do you require better security at the sacrifice of compatibility or more ...


11

By using the file's hash as IV, you also divulge the file's hash. This allows an attacker to make an exhaustive search on the file contents. It is not difficult to imagine situations where there are only a few millions or billions of possible file contents (e.g. the file contents are an encrypted SAN or password), in which case showing the data hash is an ...


7

You are right to be confused, because you could just as well have asked "How can I encrypt a file using a CPU that supports xor, shifts and rotates?" The answer is that of course you can, but there is obviously a lot more to it, if you are going to do it right. AES is just a standard block cipher primitive. The only thing this standard tells you, is how to ...


7

This is essentially a Vigenère cipher; it's been known for centuries. As for how secure it is, well, it is actually fairly easy to break (unless the key is both as long as the ciphertext, and randomly chosen; however, at that point, if you could remember the key, you could have well just remembered the plaintext). As for your colleague, he's right, and ...


6

You obviously lose semantic security when you use deterministic encryption. This means an attacker can tell if two files are identical. publishing the unencrypted hash also leaks which file you encrypted, if the attacker knows the hash from elsewhere. You end up with something similar to convergent encryption, which has a few issues. Check the question Is ...


6

The capacity of AES in terms of file encryption is practically unlimited for the time being, especially in OFB or CTR mode. An 8 GB file comprises short of $2^{29}$ 128-bit AES blocks. If one uses CBC or OFB CFB mode, odds of a collision (that is, the same block appearing in ciphertext, which reveals 128 bit worth of potentially usable information about the ...


6

If you mean how much data can safely be encrypted by AES with a single key (and IV), AES is designed to encrypt up to $2^{64}$ blocks of data before becoming susceptible to certain statistical attacks (in particular distinguishing the encrypted file from truly random data), because of its 128-bit block size. 8GB (= $2^{36}$ bits = $2^{29}$ blocks) is quite ...


6

The encryption scheme seems to be: re-use an existing 128-bit secret, originally used to unlock a read-prevention mechanism, as the 128-bit key; split the plaintext (data to protect from prying eyes) into 128-bit blocks; XOR each block with that 128-bit key. That approach is flawed. Two cardinal mistakes are made: Use XOR with a keystream that repeats. ...


5

You don't need to worry. There is no known weakness in CBC mode or AES which would mean that encrypting identical files (with different initialization vectors) makes it easier to retrieve the key, or decrypt the data. The different initialization vector for CBC makes it sure that even the same file results in different input to the block cipher, and thus ...


5

The more I think about this, the more I think it'd be better to not do this. I couldn't think of a single file format that would be simple enough for this - they all have atleast some structure that is hard to replicate via shell-scripts and the like. Also, security considerations for the file format crop up very easily, especially if taking passwords in to ...


5

Pretty much all modern encryption systems (including AES, in any standard mode) are data-agnostic: they are designed to encrypt any byte (or bit) stream regardless of its content, and their performance does not depend in any way on what the stream contains. Indeed, if this were not the case, that would open the encryption scheme to timing attacks — if ...


5

The question is subjective in nature, and this comment is also subjective. It was too long to leave as an actual comment so I'm posting it as an answer, although it isn't really an answer, it's a comment. This is for posterity, I guess -- this thread is already high in Google searches. NaCl is probably the most widely respected library. It's authored by ...


5

Yes, there are secure alternatives to support random-access based encryption. I did not come up with a way to break the proposed combination. Still, instead of inventing a new mode, I would recommend to take consider existing modes for this kind of operation, such as XTS mode. The existing modes are more studied, and (in some ways) more efficient. XTS mode ...


5

Yes, you encrypt the file with a symmetric key, then encrypt that symmetric key with each of the recipients public keys. gpg can do this by adding multiple --recipient options.


4

"Efficient, Compromise Resilient and Append-only Cryptographic Schemes for Secure Audit Logging" (PDF) gives a publicly verifiable approach that allows fine-grained verification, but it is in the Random Oracle Model. The Simple Method: The verifier and logger start with a seed for a forward-secure pseudo-random number generator. To denote a valid ending ...


4

Step 1: good job, this is the right way. You can also use bcrypt or scrypt for extra resistance. Make sure you have chosen sufficiently strong parameters, that is, 64-bit salt and 10000 rounds absolute minimum. Step 2: no! once you have a strong derived master key, you don't need to apply PBKDF2 on any keys derived from this master key. You are just wasting ...


4

I see a few issues with this approach: First, since you're signing the ciphertext and sending the signature in plain, anyone who has your public key can verify that you did, in fact, sign that message, even if they won't be able to actually decrypt it. This may or may not be something you want. More importantly, anyone who intercepts the message can strip ...


4

The question still lacks detail, so this answer will be equally vague and hand-waving. Any modern cipher exceeds consumer disk/network IO speeds by a significant margin, you can pair any modern block cipher (AES is probably the best choice here) with a streaming mode of operation such that the file size is left intact, such as CTR or CFB. However, you still ...


4

Yes, the IV (not "IV vector" because IV = "initialization vector" :p) is public and is only used to introduce randomness in the encryption process to prevent it being fully deterministic, while still preserving entropy in the key material. You normally send the IV along with the ciphertext (yes, it is safe if you do it right), and how it is generated ...


4

There are several reasons to use a scheme like this: As several other answers have pointed out, it allows changing the password without re-encrypting the entire file. Also, it allows re-encrypting the file without changing the password, should this be desired. In particular, a careful implementation can allow incremental re-encryption, so that the file ...


4

Your problem is that if you encrypt two messages which start the same (and change at some point later on) the beginning of the ciphertext will be the same in CBC mode when using the same IV. Normally you should change the IV every time you encrypt a new message. This is precisely what the IV is meant for - achieving IND-CPA (semantic) security which ...


4

You can use the ecryptfs-add-passphrase command to add a passphrase to your kernel keyring, which will also print the signatures (hashes) to standard out. Once you've added a passphrase to the keyring, you might want to clear it, using the keyctl command. eCryptfs uses a PBKDF2-like, key strengthening algorithm of 65536 rounds of SHA512. (Disclosure: I am ...


4

What Stephen says in the comment is correct. It is safe to not use authenticated encryption whenever your adversary model assumes that the attacker does not have the ability to manipulate ciphertexts. I assumed hard drive volume encryption or per file encryption that is not transmitted over an insecure network should be considered safe to do without a ...


4

You basically want a full disk encryption mode for a block cipher; XTS mode seems to be the current standard. In your case each "disk block" is actually a file offset. Note that using a stream cipher or counter mode is NOT secure if the data is ever modified in the file, as it would violate the cardinal sin of using the same key and initialization vector to ...


4

If you need security against quantum attacks, there aren't that many options. I would go for a lattice-based encryption like NTRU or something based on ring learning with errors. There are no "magic numbers" involved and the assumptions they are based on have been scrutinized by the academic community. NTRU has been around for a decade and has pretty good ...


4

This exists. It is called Broadcast Encryption http://en.wikipedia.org/wiki/Broadcast_encryption . Latest research even allows for Traitor tracing http://en.wikipedia.org/wiki/Traitor_tracing , meaning that even if two people give a part of their secret keys to form a "pirate decryptor", there is an algorithm which will find one of the users that colluded. ...


3

It seems your major requirement is that the file size not increase. This is possible, but at the sacrifice of some security (namely integrity and authentication), so it seems you will only be able to provide confidentiality. If the file size can increase slightly (say no more than 300 bits) you should encrypt with an authenticating mode such as GCM. As ...


3

It depends on the mode of operation. With counter mode, predictable IV's are fine. Of course, a collision in file hashes would result in easy plain-text recovery. It's probably better to fill the high order 64-bits with the number of microseconds since the unix epoc, pad the rest of the 64-bits with random numbers and the use the low order 64-bits as the ...


3

First off, you are still missing some information. What encryption mode will you be using? What key are you using for the HMAC? That said, my answer is no. This isn't a good way. The reason being is that unless you are a professional cryptographer, you shouldn't design your own cryptographic protocols/methods. There are too many ways to introduce ...



Only top voted, non community-wiki answers of a minimum length are eligible