... I would love to hear what others suggest.
Looks like at least Microsoft does not trust the internal encryption in SSD anymore. It switched to software based encryption for BitLocker by default:
BitLocker, Windows' built-in encryption tool, no longer trusts your SSD's hardware protection
After reports of widespread flaws in hardware-based SSD ...
It depends on your threat model. CBC is more malleable, but XTS leaks more information.
CBC-ESSIV (and plain CBC, which is additionally vulnerable to the watermarking attacks that ESSIV prevents) is vulnerable to malleability attacks where an attacker can change the ciphertext in a way that modifies resulting plaintext predictably, even if they don't have ...
No, it's not useless.
Transport encryption may hide details about the application protocol being used. For example, if a TLS handshake between Alice and Bob is being recorded, and then some data is being transfered, then the attacker can really not see what kind of data is being transferred.1
On the contrary, if an application-specific protocol, such as ...
Am I correct in guessing....
Would there be a point in encrypting a password before an https post request,
No point. It's already encrypted. But you do need to think about what you are going to compare it with serverside to validate it - the stored password should encrypted using a suitable password hash/
If your developers need to work with the data it doesn't make sense to encrypt them, because they will need that data to test the functionality.
If you would AES256 encrypt an address field
it would become binary data which you could base64 encode or store as is. That data would be unusable for the developer, because it doesn't reveal the context.
If you have information that is encrypted, you can not search inside of it without decrypting it first.
If the information that you're using to search for something is not sensitive, such as a user ID, message ID, or otherwise only tangentially related to your sensitive information, then use that information as an index for your encrypted data. A popular ...
It's usually a bad idea to encrypt user data with a key based on their password. What if they forget their password?
If you really want to, the "KDF" in "PBKDF2" stands for Key Derivation Function. So you could use that again to derive a key for the database. Remember to implement a mechanism to change the password as well. Depending on your setup, this ...
This is one of the promises of quantum communication - in theory, since observation fundamentally alters quantum states, it would be possible to create a "read once" communication protocol.
Of course, practical problems like "user can still take a picture of their screen with their phone" still remain.
we run a vulnerability scan against our servers. It flagged a few
certs we use are using 3DES symmetric encryption method, which is a
weak encryption algorithm. It is unclear how this was determined, so I
am hoping to be able to see if there is a way to determine this my own
without having to run a scan every time to find out
Is TLS, the server has ...
openssl is often used to create keys and CSR's for SSL/TLS certificates. To use openssl to generate a CSR, the process is as follows:
First create the private key. For a 4096 bit RSA key, the command is:
openssl genrsa -out yourdomain.key 4096
To answer your question, 'where is the private key stored?', the file
yourdomain.key contains the private ...
While essentially, SSL and SSH can use the same algorithms and keys, your life will be a lot simpler if you create your CSR with a tool designed for the job (and you should never use re-use keys for different purposes).
On MS Windows you can do this with certreq, or the MMC snap-in for certificates, but I find the tool bundled with IIS easiest to use. For ...
Generally, a Good IdeaTM
According to the S/MIME Version 4 standard, there is no technical reason why any email client needs to have a certificate or to sign or to have reversible encryption of the messages, too.
But for any general usability, it is standard that all email clients require a sender certificate for:
signing for sender verification: it is ...
Thunderbird (as well as any other email client) needs your own certificate to encrypt the email for yourself, too.
Why is that so?
When you send an email, the email is not just sent, but a copy of it is kept in your sent folder. As a consequence, when you send an encrypted email, the email needs to be encrypted not only for the recipient, but also for ...
Proprietary in this context refers to a self-made algorithm as opposed to an already established and proven algorithm.
It is not used in the sense of closed source, which refers to the implementation and not the algorithm. There are also open source implementations for Telegram's MTProto algorithm.
Note that MTProto has been published by Telegram and that ...
Short answer: you don't. At best, you can use the OTP to secure access to a key stored somewhere.
OTPs are for authentication, not encryption. You can write software that checks a user's OTP before granting access to data. This is just standard authentication, such as the way that Github (for example) checks your OTP at login before granting access to your ...
OTP is not made for that. OTP is used as a second factor authentication to avoid a leaked password compromising the whole account, and is usually rate-limited, and usually locks itself during a small interval if mismatched (I've seen one minute lock after 3 errors). That is the main usage for OTP.
Encrypting with OTP does not make sense. As the token you ...
When a sender uses Thunderbird to send an S/MIME encrypted message to a recipient, Thunderbird requires the sender's certificate in addition to the recipient's certificate, so that Thunderbird can send the sender's certificate along with the message to the recipient. This is done for two reasons:
1) So that the recipient can verify the sender's digital ...
From a purely theoretical sense - it is only possible if you can make sure that after the first decrypt there are no copies in existence of both
the decrypted data, and
either the encrypted data or the key(s) needed to decrypt it.
In principle, you can only do this with the cooperation (willing or coerced) of the parties that handle these pieces of ...
It is not in any way practical, and fundamentally impossible (in a reliable way), but it may be possible to some extent.
The obvious hindrance which makes the endeavour fundamentally impossible is that whatever it is you decrypt, once you've read it, it's inside your head. So, to be sure the secret stays secret, there would have to be a poison pill ...
The Cipher-Block-Chaining Mode becomes problematic if your threat model includes an attacker who actively manipulates the encrypted data. This allows an attacker to flip specific bits in the cipher to flip the same bits in the resulting plaintext - a property called malleability. If not paired with a MAC to ensure integrity, CBC is not very secure.
If a network is available, you could offload the decryption procedure (and the private key) to a service running on a secure server. You could then enforce whatever rules you want on the server.
The client would submit the opaque text to the service and ask it to decrypt it and return the plaintext content, and the server could decide whether the client ...
As you already hinted at, such a thing is only possible in hardware. A software or encrypted data solution would always suffer from the option of making a copy before decryption.
In hardware, the scheme would be to destroy information on decryption. A naive approach would be to simply read a block into memory, destroy it on storage and then decrypt it.
Logging in requires looking up the email address, which isn't scalable if they're hashed properly – with 10k users in your system, you'll have to hash a user's email on average 5k times on every login, due to salts.
May I question your premise?
"I figured the user needs the email to login obviously"
Why not issue them (or let them select) a username ...
Looking at the Kevo by Kwikset locks that you link to, the sophisticated attacks possible via bluetooth probably won't come into play - most of those locks appeared to have a standard key mechanism included.
The problem with that is that I'm pretty sure Kwikset and their competition aren't putting in high-security cylinders - I'd bet they are the same ones ...
There is no way to do this - this is a subset of what DRM schemes attempt to do.
If an end user can decrypt something once to see it, they can see it again. Any of the following may be possible:
first take a copy and decrypt that
copy the screen
edit the application
The only way you could get close would be to have total control over the hardware and ...
An alternative to existing answers: put the emails on a separate machine & application and store only the hashes in your main application DB.
Use the hash for verifying the emails.
When you need to send an email your application will communicate with this other service passing on the hash + email message and the other application will send the email.
There is no widespread certification procedure for Bluetooth locks' digital security at the moment.
This means using one is putting your security and privacy at the mercy of the lock's developer.
As Bluetooth locks are an innovative product, they follow the usual innovation model: release new features to market ASAP, fix reported bugs later, and plan to ...
There are several possible attacks on Bitlocker, and apparently a software is available to the police that supports recovery of the password (but requires sniffing the RAM while the device is mounted and unencrypted).
The primary weakness is the recovery key stored in both AD and the TPM chip - but if your attacker has only the USB stick, those don't apply.
If you only need to verify the email when the user provides it, then hash it, like vidarlo suggests, in the same way you would hash a password. No need for encryption here. The flip side with this approach is that you can never recover the email, even if you really need it (e.g. to contact your users in case of a compromies, as suggested in comments).
Do you really need the users e-mail address?
If you store e-mail address as hash(e-mail + salt):salt you can trivially verify the e-mail address supplied by the user. If the user requests a password reset, simply verify that the e-mail address matches, and send the e-mail to the user supplied e-mail.
If you want to allow lookups in the database based on e-...
A cold boot attack is impossible on an offline device. The only way an attacker could use a cold boot attack on your portable storage device is if they also had physical access to your computer as it was plugged in the disk unlocked.
A cold boot attack relies on encryption keys being stored in RAM, and the persistence of that RAM once the computer is hard ...
Doing 'the inverse' seems like the more secure solution.
the backup function is the only function that the backup server
all incoming connections to the backup server are blocked
all outgoing connections (except the connection to the server being
backed-up) are blocked
the only process that the backup server performs is the backup process
As per PCI DSS you can not store cvv on disk. It is allowed to reside in RAM during online transaction and should be erased as soon as transaction finishes.
It is not required to encrypt CVV(itself being encrypted value) in switching from acquirer to issuer.
Refer to storage allowed and protection required fields below. for CVV storage not allowed and ...
If your employer has set up your work computer to create a security hole in the network you are connected to (like installing a remote access trojan or other reverse shell backdoor) then your work computer could allow your employer to access the work computer as if they are sitting at it. Once they have access, they can attempt to traverse the network that ...
How exactly VPN providers encrypt data from client to their server?
There's numerous algorithms, or cipher suites. Which ones that can be used are dependent on the exact protocol used. You want to avoid using broken ones so using the latest versions and good configurations of your software is needed. One you want to avoid for sure is anything DES.
You are probably mistaking encrypting for signing!
Being able to decrypt something does not imply that the encrypted data comes from a trusted source, which is what you likely want from a licensing software.
Rather, what you should do is to sign the license key, and allow the client to verify the license. This can be done using public-key cryptography. ...
To ignore it, just ignore it the way you ignore anything, by not looking at it or paying attention to it. I will consider that you want to suppress it, so it isn't there to be ignored.
On Unix and Windows (which is most of the places OpenSSL is run, though not all) use 2>/dev/null or 2>NUL: respectively to discard all error messages.
As it says, use -...
I may do this in a security audit if something smells fishy, and I have done so for both reasons you mentioned:
Denial of Service: I've seen systems that, after too many requests, just bugged out by having too many file handles open. I guess a session system would be even more vulnerable, since it might have on-disk files that it's keeping open. Or just ...
On the security side, you can protect yourself with:
Rate limiting tools like fail2ban to block DDoS and other automated noise
Recaptcha to block brute force attempts
A stateful firewall, intrusion detection, or intrusion prevent appliance to block known attack methods
(This site forbids product recommendations, but there are packaged/supported paid ...
Simply put, YES
Smart cards already do this.
Many off the shelf embedded CPUs have this feature built in.
Or, you can cook your own in an FPGA (Field programmable gate array)
Free IP hardware IP in the form of HDL (hardware description language) is available from OpenCores.
It depends what kind of encryption/format you have. Currently, there are many formats which cryptsetup support. Basically, the most popular are LUKS1 and LUKS2. You can check what kind of format you have with following command:
cryptsetup luksDump <device>
John the Ripper only supports CPU cracking with LUKS1 and specific combination of encryption/...
They claim that the key for decrypting the message is stored in the URL that is generated. [This is similar to how Firefox Send works]. However I did a test, and I noticed that the key in the URL that it generated seem to be very short. In my test, I received the following URL:
It appears that the key is encoded using just 5 base-64 ...
-c Encrypt with a symmetric cipher using a passphrase. The default sym-
metric cipher used is AES-128, but may be chosen with the --cipher-algo
option. This command may be combined with --sign (for a signed and sym-
metrically encrypted message), --encrypt (for a message that may be
There seems to be a flaw in the design of this system.
If you want to guarantee (to a reasonable extent) that the only person who reads the message is the user who enters their e-mail address, then the user must provide their public key and your server should encrypt the message using that key. It will be responsibility of users to decrypt the messages.
From RFC 8446, Section 5 (TLS 1.3, Record Protocol):
The TLS record protocol takes messages to be transmitted, fragments
the data into manageable blocks, protects the records, and transmits
the result. Received data is verified, decrypted, reassembled, and
then delivered to higher-level clients.
The cipher for encrypting fragments at the Record ...
An encryption key is generated and used to encrypt the secret message you want to store. The secret message is then stored encrypted on their server and they distribute you an URL which contains the decryption key and the id of the secret message. They do not store the decryption key anywhere on their server and thus have no knowledge of the message content.
Xavier59's answer is correct, in that protonmail uses SRP. Therefore (under normal circumstances) your password is never sent to protonmail's server.
You are wrong in your assumption that protonmail stores the password used for the encryption of your private key.
Protonmail uses the Secure Remote Password Protocol (SRP on wikipedia - Protonmail blog post about SRP) and so they only store a verifier that is irreversibility related to your password.
When entering your password on the login form of ...
Is FeliCa encryption safe? Yes, but also no.
Yes, insofar as there doesn't appear to be any published cryptanalysis attacks against the cryptography employed by FeliCa.
No, because it isn't an open standard. This makes it difficult for cryptographers from all over the world to review and audit the function. Instead, Sony is relying on a small pool of ...