We're currently encrypting our objects before sending to GCS, but considering offloading the encryption to GCS although we would continue to manage the keys, i.e. customer-supplied keys. In addition to the keys, is it possible for us to manage the initialization vectors and send that in the API?
The documentation includes headers for the encryption algorithm, encryption key, and hash of the encryption key. Nothing for the initialization vector.
In addition to the keys, is it possible for us to manage the
initialization vectors and send that in the API?
No, you cannot provide the IV (initialization vector) along with the encryption keys nor should you.
The encryption key is used for many operations. The IV (initialization vector) is usually unique (random number) for each encryption operation and is stored with the ciphertext (prepended). The encryption key is a secret. The IV is not a secret.
If you could specify the IV with the encryption key, meaning the same IV for all encrypt operations, you would have significantly less secure encryption (Semantic security).
Related
We know that there are three options
1.(default) Google-managed encryption keys
2. Customer-supplied encryption keys
3. Customer-managed encryption keys
For a particular customer data, how we can restrict the access so that the data remains unreadable even if it is downloadable.
You cannot download encrypted data from GCP/BQ/etc without the encryption key or access to the encryption key.
The exception is if you upload self-encrypted data as normal data.
A pair of Amazon Lambdas will symmetrically encrypt and decrypt a small piece of application data. I want to use Amazon KMS to facilitate this, because it solves the problems of secret storage and key rotation, and then some.
The Amazon KMS Developer Guide indicates:
These operations are designed to encrypt and decrypt data keys. They use an AWS KMS customer master key (CMK) in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. Although you might use them to encrypt small amounts of data, such as a password or RSA key, they are not designed to encrypt application data.
It goes on to recommend using AWS Encryption SDK or the Amazon S3 encryption client for encrypting application data.
While the listed advantages of the AWS Encryption SDK are clear as day, and very attractive, especially to a developer who is not a cryptographer, let's assume for the purpose of this question that circumstances are not favorable to those alternatives.
If my application data is sure never to exceed 4k, why specifically shouldn't I simply use Amazon KMS to encrypt and decrypt this data?
Use case
My team is implementing a new authentication layer to be used across the services and APIs at our company. We're implementing a JWT specification, but whereas we intend to steer clear of the widely documented cryptographic grievances beleaguering JWE / JWS compliant token signing, we're symmetrically encrypting the payload. Thus, we keep the advantage of standard library implementations of non-cryptographic token validation operations (expiry and the rest,) and we leave behind the cryptographic "foot-gun."
I suspect it's about performance: scaling and and latency.
KMS encrypt/decrypt has a limit of 5500 reqs/s per account, which is shared with some other KMS operations.
"Why?" Is also discussed a bit more thoroughly in the FAQ.
Why use envelope encryption? Why not just send data to AWS KMS to encrypt directly?
While AWS KMS does support sending data less than 4 KB to be encrypted, envelope encryption can offer significant performance benefits. When you encrypt data directly with KMS it must be transferred over the network. Envelope encryption reduces the network load for your application or AWS cloud service. Only the request and fulfillment of the data key through KMS must go over the network. Since the data key is always stored in encrypted form, it is easy and safe to distribute that key where you need it to go without worrying about it being exposed. Encrypted data keys are sent to AWS KMS and decrypted under master keys to ultimately allow you to decrypt your data. The data key is available directly in your application without having to send the entire block of data to AWS KMS and suffer network latency.
https://aws.amazon.com/kms/faqs/
I am going through this issue with AWS support right now. There is the throttling limit mentioned in the accepted answer. Also, if you reuse and cache data keys as allowed by the SDK, you can save money at the expense of lowered security (one data key can decrypt multiple objects).
However, if neither of those are relevant to you, direct CMK encryption is appealing. The security is excellent because the data key cannot be leaked, every decryption requires a API call to KMS and can be audited. In the KMS Best Practices whitepaper, it states that encryption of credit card numbers in this way is PCI compliant.
I am using encryptByKey() for SSN and Account Number encryption in Yii2. The problem is that it generates different encrypted data for the same Account Number when I try to re-generate it.
I can't match it in the database like the following:
Customers::findOne(['account_number'=> Yii::$app->getSecurity()->encryptByKey($account_number, "someKeyHere")]);
Is there any encryption method available to generate same encrypted data every time I encrypt it?
Thanks,
Generally, that's the way encryption is supposed to work. It is sometimes called "ciphertext indistinguishability." Yielding the same ciphertext every time a given plaintext is encrypted undermines security by allowing attackers to analyze collections of ciphertext for patterns.
In this case, it looks like you only store one instance of the encrypted account number; you could argue that because the "message" is never repeated, cipher text indistinguishability is moot. That could lead you to justify the use of ECB mode (if your API offered it) or a HMAC (message authentication code, offered by the hashData() method) to compute a lookup key. If an attacker gets access to your database, there will only be one instance of each key, and nothing is revealed.
However, this is still insecure if an attacker can provide account numbers that your system encrypts. For example, an attacker could pose a legitimate user and provide a SSN during registration. If they choose a duplicate number, and then look in the database, their maliciously chosen encrypted value will match a legitimate record. Or, if the system rejects their account number because it is a duplicate, the attacker will know that it is a number in use by a legitimate user. This is called an oracle attack.
If you use an HMAC (or ECB mode encryption), you would have to design your application very carefully to prevent chosen plaintext and oracle attacks. And, candidly, if you are now encountering these ideas for the first time, there are probably many other gaps in your knowledge that will lead to easily exploited vulnerabilities in your application.
Option 1: If we use an AWS KMS-managed customer master key (CMK), does that provide end-to-end encryption?
Option 2: Or, would we have to use a client-side master key, so that only the client can decrypt their data?
Update: KMS is not asymmetric, though you can use Envelope Encryption to generate a data key from the CMK. The key is generated on a physical HSM making it not accessible externally. You will only have to worry about the access to the CMK which you can achieve using IAM access control.
For a detailed explanation how the mechanism works, check the Envelope Encryption section on the KMS Cryptographic Details white paper.
So if you only worried about eavesdropping can be a good solution. If you are looking for strictly end-to-end encryption you might have to use asymmetric keys on which KMS can help you with too.
Aws kms does not store any data it provide you two keys
1 plain key : with the help of it you encrypt the data and delete it(key)(no need to save anywhere).
2.encrypted data key :- you need to save this key to decrypt the data( to decrypt the data first you got plain key from aws using encrypted data key) and with the help of plain key you decrypt the data.
So encryption is done at client side.
I am developing a web based application that will be employed by numerous third party organisations
in numerous countries around the world.
The browser based client will feed sensitive data into a shared back end database.
All organisations in all countries will Read/Write data into the same database.
I wish to encrypt the data entered within the browser so that its safe while in transit
to the back end database. e.g. client side encryption.
I also wish to encrypt the data while at rest in my database.
This application will be developed using Java, Javascript (REACT.js), and Scala.
The backend database will be MongoDB.
I cannot find a good Key Management example/description e.g. how a key is properly generated,
distributed, stored, replaced, deleted, and recovered during its life time.
I have the following choices/decisions to make:-
Flavour of encryption, e.g TripleDES, RSA, Blowfish, Twofish, AES etc..
Key(s) Symmetric/Asymmetric and its/thier length
How should I securely distribute the keys to my clients.
How to keep my keys safe on my back end servers.
If keys should have a lifecycle of generated, distributed, stored, replaced, deleted.
How do I decrypt data that was encrypted with Key0 when I am now using Key1, or Key2?
How should I store my multiple keys for my multiple clients to enable me to encrypt/decrypt
each clients data.
Use HTTPS with certificate pinning to secure the data in transit.
Use AES for encryption. Do not use TripleDES, RSA, Blowfish or Twofish in new work.
Use an HSM.
Encrypt the data with a long-life key that is not distributed, encrypt that key with short life keys that can be changed as needed.
Considering the scope of the project get a cryptographic domain expert to design the security and vet the code.