# Tag Info

## Hot answers tagged file-encryption

18

(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" ...

11

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

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. ...

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 ...

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

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 ...

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 ...

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

"Efﬁcient, 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

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 ...

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 ...

3

eCryptfs information leakage can occur through various channels. The most serious and common leakage point has been the swap. As mentioned, Ubuntu now encrypts that, but I am told that hibernate is broken with that enabled. Other distros don't necessarily go out of their way to make sure swap is encrypted when eCryptfs is used. eCryptfs makes no special ...

3

I'm going to expand on Paŭlo's comment whilst I'm here: The complete file from the outside is just a stream of bytes. Your encryption program doesn't (shouldn't) care if this originally was a word file with text and images, a plain text file, a video file or something else. You just encrypt the bytes as they come. What you're not understanding, I think ...

3

My friend (Jerome Kelman (he wanted me to quote him as the author when I posted this)), wrote a program to crack it. (this is assuming the password is exactly 3 characters long though). Here is the code he wrote (it's in java): import java.util.Scanner; import java.io.*; import java.util.ArrayList; public class Test { /** * @param args * @throws ...

3

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 ...

3

The details are very sparse as to what they are actually doing. So, I'll speculate. Below are some claims and what I think they are doing. The master key (in its plain unencrypted form) will be literally nowhere in the cloud, yet completely usable for split-key encryption. Typically this is done using some sort of secret sharing, which doesn't ...

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

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 ...

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

I think what you are looking for is a Password-Based Key Derivation Function (PBKDF). You can take a moderately strong password, like 12-14 random letters and numbers (no dictionary words though!), and throw it into the PBKDF function together with some other parameters, e.g. salt, number of iterations and the desired key length. After that you have a ...

3

The two most popular ways I am aware of are Shamir secret sharing and additive secret sharing. I'll explain both. Additive Secret Sharing I'll start with additive as it is conceptually simpler (but also more limited). I'll also use bitwise addition modulo 2 as the addition operation (i.e., XOR), but know that that isn't the only option. You could use real, ...

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