Search Results

Encryption at rest and access control systems which prevent a customer from logging into the machine is good enough in most cases. …

Depends on your customer. Most devices aim for FIPS compliance https://csrc.nist.gov/publications/detail/fips/140/2/final

I don't know if there's a right answer to this, here's an idea: Files named with sensitive names (passwords.db for example) with completely random data. Completely random data is indistinguishable fr …

Sure. Okay. The acceptance of both these points relies on me choking on the gut reaction to write "We don't encrypt with asymmetric keys directly." I don't really understand this one. The client is …

There is nothing materially wrong with this idea, I guess the term for it would be sign-then-encrypt. A mitigation should be included for replay attacks. Just because someone signed a message at one …

There is some notion that given enough cipher text an attacker may gain knowledge of the underlying key material and/or the underlying plaintext. Not sure of an active attack against well used AES b …

One such mechanism would be to encrypt the key locally and send it to be stored on the server. For example: Use PBKDF2 with a user chosen recovery password to generate a key. Use the key that pops ou …

Properly implemented AES-256 encryption is, at this time, unbreakable. File password protection seems to be built on this and should be fine. … If one is unsure of the security of encryption features in a program, putting a file in an encrypted zip is always an option. …

Key rotation (of encryption/decryption key if it is ever exposed) would require every user to log in and update their encrypted store of the key. …

Does end-to-end encryption make sense? Sure How should I share the private key and should it be shared? … If one cares about end to end encryption this is exactly what one should want. And is there a way to prevent this situation? …

I don't have enough time in my day to read up on how signal approaches this but the first issue off the bat with this scheme is a lack of forward secrecy. A compromise of Bob's private key at any tim …

Each message should have a distinct IV and start from zero in the encryption process, no matter the mode. ECB's issue arises from a lack of IV, not the lack of chaining. …

Two issues: Encryption must be reversible While erasing random bits is obfuscating, it is not encryption. Think of a magazine page where someone cut a few letters out of it. … Second, output of encryption should be statistically random. …

It could increase security posture if there was an attacker that had access to the running RDS but not the ability to read/use the service where the key is stored (KMS, HSM, etc). This would depend h …

Another answer has the rule so how about some intuition: ChaCha permutes a block of data into an unpredictable block of data and XORs it with your plaintext. Because XOR is reversible, the same unpre …