Hot answers tagged

24

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


24

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


15

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


10

You really don't want to use ChaCha20 alone in (nearly) any situation. What ChaCha20 does for you is to prevent attackers from (passively) reading your data, which is good. But ChaCha is a so-called stream cipher which works by XOR'ing a pseudorandom pad with the message (your file at rest). However it is for this very way of working that ChaCha doesn't ...


8

None of Twofish, Serpent and AES are currently known as broken, so as far as security is concerned, you can use any of them. AES has a slight advantage because it's very widely used, so if it gets broken you're more likely to hear about it and get relevant software updates quickly. The Snowden postings haven't changed much as far as cryptography usage is ...


7

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


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


7

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


7

Yes, AES-128 is intended to be the standard block cipher for building a secure and efficient symmetric cryptosystem using some block cipher operating mode, like CTR for encryption or GCM for authenticated encryption; efficiency can be particularly good when there is hardware support for AES and GCM. There might be better choices in the case at hand, like ...


7

Either could be implemented securely, but if you encrypt first and split afterwards, you can use standard tools and get everything right more easily. If you used the opposite order, you would have several pitfalls to deal with: With password-based encryption you would either have to derive the key many times (spending resources that would be better used on ...


6

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


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

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


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


6

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


6

CAST5 seems to be a solid 64-bit block cipher with 128-bit key. As far as I can tell after a short literature search, it's definition is sound and unbroken, despite nearly two decades of exposure (more for the round function). CAST5 is also known as CAST-128, defined in RFC 2144 (1997), and endorsed by ISO/IEC 18033-3:2010 (current). It is a 16-round ...


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

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


5

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


5

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


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

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

The catch how ever is that if a small part of the file is given along with the location of that bytes from the beginning of the file we should be able to decrypt just that piece. Normal CTR mode encryption allows one to decrypt any block of the file independent of the rest, so no need to invent your own mode. With AES the block size is always 128 bits, so ...


5

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


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.


5

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


5

Yes it's secure if: the password contains (i.e. is chosen using) sufficient entropy to resist attack. In practice this means it must be generated by a physical process (like rolling fair dice or flipping fair coins) or a good computer program (usually not the C library rand() function for example) not chosen by a human. Humans are very bad at choosing "...


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



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