63

Any encryption is vulnerable to brute force attack, for example AES-256 has 2^256 keys, and given enough hardware we can “easily” brute force it. The problem is that there’s not enough silicon on Earth to construct enough processors to do it before the heat death of the universe. The fact that encryption can be bruteforced doesn’t mean that this will happen ...


20

Didn't veracrypt creators know about this issue? (Not having brute-force protection) As Andrew Morozko notes in his answer, they have addressed this – as far as it is possible – by using a secure key-generation function (PBKDF2) and high iteration counts. This severely limits the ability to brute-force (assuming the password is long- and random-enough1)...


10

No, this won't provide any improvement for encryption with any decent cipher. If a cipher is so bad that a known-plaintext attack is capable of fatally breaking it, then the cipher is worthless. A known-plaintext attack is one where an attacker has knowledge of plaintext/ciphertext pairs and, from that knowledge, is able to either calculate the key or ...


8

Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and FileVault) encrypt disks at the level of disk sectors. This is an all-or-nothing approach, since the encryption drivers won’t necessarily have any idea what files those sectors represent. At the same time, FDE is popular — mainly because it’s extremely easy to implement. While this could be ...


6

This looks like a Data Loss Prevention (DLP) system in which DRM is applied to documents. While I haven't assessed Fasoo itself, I have assessed five or six different enterprise DLP solutions over the years so I can make some inferences about how it works and how secure it is. In my experience the answer to your question is "pretty much nothing stops you ...


5

If you are using ZipCrypto for encryption, then any password length is insecure. You are using the ZipCrypto cipher, rather than the more secure AES. ZipCrypto is extremely weak, as it is based internally on a non-cryptographic construction called a CRC. It is highly vulnerable to a known-plaintext attack, which in practice does not require knowing exactly ...


5

Yes, File-Based Encryption offers a good security and as everything it got also some advantages and disadvantages. But let's start at the beginning. What is the main difference between this two methods? File-Based Encryption At a File-Based Encryption only Files are encrypted with different keys. So say every file got his own "password". There are two ...


4

I won't say that it's overkill, but I will say that I think you need to get a better understanding of cryptography before attempting to secure your data for 100+ years. Encrypting in a cascade is actually difficult to do correctly. You need each algorithm to be truly cascaded such that it's impossible to determine if one has been successfully broken without ...


3

Is it too late to encrypt my drive even if files are on there already? You can "turn on" Bitlocker To-Go to encrypt the files/folders already on the USB drive. However, as the other post indicates, this may not remove all traces of the unencrypted data due to hardware specifics of memory controller/flash/etc, but it is better than nothing as an immediate ...


3

Yes, you can mix encrypted and unencrypted data in the same file. The real question is whether you really want to, or whether it's easier to just encrypt the whole file. In particular, regarding performance concerns, the general rule of thumb is that public-key encryption schemes like RSA are slow (especially with such a large modulus as you're using), ...


3

Systems that have been compromised cannot be trusted. You can hope the attacker made a mistake, or missed something while they were wiping down their tracks, but in general, no, these aren't directly detectable. First, identify your threat model. In the kinds of organizations typically involved in data breaches, attackers often won't take the time to ...


3

Unless the application encryption sticks "something" (header, a magic token, etc...) on the header in general it is not possible to know which was the application that makes the encryption.


3

Dropbox supports versioning, and the page about this says: If you have a Basic (free) or Plus account, you can restore a previous version of a file within 30 days of the change. If you have a Professional or Business account, you have 120 days. So create a Dropbox account with enough storage, let it sync all your files, and keep it syncing all the time. ...


3

How can someone effectively resolve this? You can't. If you store the symmetric key on the client, it will be read there. If you send it over to a server for decryption, the network traffic will be sniffed for the decrypted data. Also, you should not discount the RAM issue. Snatching data from RAM is complicated, but not prohibitively so if the reward is ...


3

If your data at any point is in plaintext on user’s machine – you can’t secure it. You can do many things to protect it, but this would only slow down a dedicated attacker: obfuscating source code, encrypting data at rest, rotating encryption keys on server, etc. This is the territory of DRM, and there are many companies that will sell you their solutions. ...


3

All NT-based versions of Windows since 2000 have a feature called Encrypting File System (EFS), although "Home" and similarly low-end editions can't use it. You can look up more information about this feature from Microsoft as well, but here are some relevant ones: Encryption and decryption is transparent; keys are managed by the OS and used automatically ...


2

If it is never modified, and is always at rest, then the confidentiality of the contents will be as strong as the encryption key. In other words, an attacker would need to know the encryption key (or the password it is derived from) in order to decrypt the contents. However, know that VeraCrypt uses XTS mode, which is not authenticated. An unauthenticated ...


2

You are reinventing the wheel by trying to solve your problem at a low level. You are trying to combine RSA and AES encryption primitives to create something that will asymmetrically encrypt a file. What you should be doing is looking for a solution that can asymetrically encrypt a file. For example, NaCl crypto box GPG


2

GCM mode combines CTR (counter) mode with MAC called GHASH. You can use virtually any standard block mode if you combine a MAC with it. For example, you can use AES in CBC or CTR mode if you also use HMAC, a MAC that uses cryptographic hashes for authentication. It is always better to encrypt first and then apply the HMAC over the ciphertext, a construction ...


2

The scenario you describe is a "common download secenario". The "first party" simply has to publish the hash of the file on the same server where the "second party" can download the file. The second party can then calculate the hash of the file and verify it with the published hash on the server. If your assumption of an "secure server" implied that ...


2

The old zip format contains a check byte (or sometimes even 2) for each archive entry to quickly verify if the password is right or wrong. This check byte is verified against the last byte of the decrypted 'decryption header'. From PkWare's APPNOTE.TXT: After the header is decrypted, the last 1 or 2 bytes in Buffer SHOULD be the high-order word/byte ...


2

This is correct and to some extent applyes even if the container is not leaked yet. If there is any way the attacker may be able to get to the old version of the container (or just its header) for example if you have backups or ssd with wear leveling, it is better to reencrypt.


2

Assuming this is a solid state USB stick and not an external USB hard drive, wear leveling, over-provisioning, and other traits of solid state media makes it difficult to securely overwrite existing data. While any new data written to the drive will be encrypted, it's likely that portions of your previous, unencrypted filesystem will remain on the device for ...


2

Look Into the world of honeypots. You can generate fake machines, printers, network traffic ect. The goal is to direct the intruder to the fake network which is usually on a DMZ, different subnet or separate firewall while the IDS kicks into action. You also download a script based random text generator and then apply whichever encryption method like MD5 ...


2

TL;DR Don't do it. Just use authentication and 404s. How Fake encrypted data is just random data, from a CSPRNG or TRNG. You don't need to actually run any encryption. To keep attackers from requesting twice and dismissing any file that changes as fake, seed the algorithm with something based on the URL. For example, the SHA-256 hash of the URL. You ...


2

A slightly radical approach, but if you really want to ensure that no (unencrypted) information from those text files ends up on non-volatile memory drives, I recommend you to use a Live CD (such as Knoppix), and only from there, mount the hard disk, copy the encrypted files to a ramdisk (everywhere else will be in-memory), decrypt and edit as needed. The ...


1

How is this in the case of hardware-encrypted pendrives? E.g. this one. Does one always require installation of drivers / software for such a device? Yep, generally devices like that require special drivers. The drivers will be included in the device, on a read-only but unencrypted partition. You'll note that the device you linked only works with pretty ...


1

The device may come with its read-only software that can run only from USB. This can protect from virus etc. As usual (this is a guess since there is no doc around), a random key is generated for disk encryption and the key is encrypted with your password with a password-based key derivation function. The password is entered by the keyboard, therefore, it ...


1

You need a Consensus Protocol for that. Keep the file saved on 3 (or 5, or more) distinct servers, and every time the file is modified, send the new version for those servers. The servers, in turn, verify if the file is a new version with the incremented counter, and if so, they can store the hash of the file on the ledger after the majority of the servers ...


1

You say someone has "sent you files". There is nothing in a file that says what its creation or modification date is. You now possess a copy of a file. That's all. Is the copy they sent you the same as what is on their hard disk? There's no way for you to know by looking at the copy they sent you. What you're talking about is what we in the industry call ...


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