I am using bouncy castle FIPS key store(BCFKS) and I am wrapping my DEK using the another AES key so it will give me a block of Encrypted DEK.
now I am able to store the encrypted DEK block of bytes into BCFKS but when I have to get it I am getting the key and there is no method which will return encrypted DEK block of byte so how can I get it or how can I store my wrapped key so that I am able to get it from the BCFKS?
By Taking Another AES Key Will perform encryption we take our DEK as data and pass it to the another AES method then it will give us encrypted key and will do some encoding and String manipulation to convert it in bytes and pass to the encryption function.
Related
I need to implement an api endpoint that just takes a id in query param, then sends its encrypted value back. For that I was looking into the crypto module in node, and I found it a bit complex. One thing that I donot get is how am I suppose to use the iv? I plan to store the encryption key in the env such that every id can be decrypted using that same key. So, should I also store the iv in the env? Is that a good practice?
I have seen some apis actually randomly generates iv for each request, and return it alongside the encrypted text, such that the user can send them both later for decryption. But for my usecase, I cannot send two separate data back to the user. I can concat iv in the encrypted text, but for some values, the encrypted text in itself is too long for my use case. Any suggestion on what might be the best approach for my case?
Initialisation vectors are important to prevent attackers using brute force methods to decrypt data after a breach has occurred, i.e. in the event the DB has been copied/stolen.
In summary, if you encrypted the same password twice, with the same key, but without an IV, you will get the same encrypted string output. By adding an IV you will get a different output with the same password, but you have to store the IV along with the encrypted data, see Cipher Block Chaining. This makes it much harder to decrypt breached password databases as the attacker cannot use dictionaries of common passwords to test keys for a match within the data. In relational databases an IV is typically called a 'salt', in Postgres for example, you should generate a new salt when storing each password, like so:
UPDATE user SET password = crypt('new password', gen_salt('md5'));
For your use case I'm not certain if you need an IV, it depends on how the encrypted data is supposed to be used and/or stored. If you decide you don't need one, you can just omit it either of these ways:
1: Pass null instead of an IV:
const cipher = createCipheriv('aes-192-ccm', key, null);
2: (Deprecated since Node 10) Use the createCipher function:
const cipher = crypto.createCipher('aes-192-ccm', key);
I am required to use AES 256 CBC to encrypt some strings before I store them in a relational database. I prepend the ciphertext with the IV that was used. The plaintext is a unique string (what I call the "key") that has a one to one relationship with users in my application.
The problem is that when a user does something, they send the plaintext key and I have to go retrieve any metadata associated with it (such as the user's ID, permissions, etc.). But I've encrypted the key in the database, so I can't just filter like where encrypted_key = :plain_key. I want to be able to do this retrieval with only the plaintext key and not require that other data are sent with the plaintext key. (It may be necessary that I do use more information in my query; I'm just seeing if there's some clever way around it).
I could just retrieve ALL encrypted keys in the database, and then iterate over all ciphertexts and parse out the IV, re-encrypt the plaintext key I received from the user with the IV, and see if I find a match. I don't want to have to retrieve all ciphertexts though. If the IV were predictable somehow I could do it, but I don't want to use any part of the plaintext key or associated metadata as the IV.
In Postgres, I am using:
encrypt('text', 'mykey', 'aes')
https://www.postgresql.org/docs/8.3/pgcrypto.html - F.20.4. Raw encryption functions
I assume this is done using the defaults of AES-128 algorithm, CBC mode.
It appears to be stored as BINARY (16 bytes) in the database and comes back as a base64? encoded string when I request the column on the server with my ORM.
In Node.js, assuming I have 'mykey', how do I convert this value back to its plaintext using crypto or crypto-js libraries?
Could you use PostgreSQL's Pgp_sym_encrypt() instead, and then use it with https://www.npmjs.com/package/openpgp to decode? PostgreSQL's raw encryption functions are not really suitable for compatible use with external systems (and really, not suitable for use at all)
So we're doing a project about an attendance system ,the idea that we have an encrypted data in a qrcode that will be sent to a server to be extracted and then decrypted using a key stored in a database on the server.what would be the best encryption technique while maintaining a reasonable key size in the DB keeping in mind that our data will only consist of 8 characters
Good day!
I have thought of a security schema for a project and I am curious whether if it is very, very secure.
I have stored in the database a RNGCryptoServiceProvider() base64 string of the GetNonZeroBytes(byte[16] object) method which I use as a Salt.
Next, I use the Salt to generate a Scrypt encryption of the password (just like bCrypt, just that it allows me to chose the quantity of RAM and other stuff like that - in this scenario, I use 8mb of RAM to encrypt the password). I use the output and the Salt from before to initialise a Rfc2898DeriveBytes(encrypted output, Salt, 10000) instance.
public static string GetBase64StringSafeString(string SaltSource, string StringToEncrypt, int memoryCost)
{
byte[] Salt = Encoding.ASCII.GetBytes(SaltSource);
byte[] derivedBytes = new byte[64];
SCrypt.ComputeKey(Encoding.ASCII.GetBytes(StringToEncrypt), (new Rfc2898DeriveBytes(SaltSource, Salt, 10000)).GetBytes(25), (memoryCost != 0 ? memoryCost : 8192), 8, 1, null, derivedBytes);
return Convert.ToBase64String(derivedBytes);
}
This I use to generate the key and IV for a RijndaelManaged algorithm with a Blocksize of 256. This is what I use to encrypt data into the database and thus to this algorithm, I don't have to store the password anywhere: all I have to do is check whether the password written by the user is good in order to decrypt the data. If it is, the user is authentificated.
Because the main aim of the hacker is to get the data, he needs the password. If he has the password he could either log in and get the data or decrypt the data in the DB. For him to get the password, he would have to run that version of bCrypt with Salt until he finds a match and to decrypt the data from the DB he would have to do that and run the RijndaelManaged with that Rfc2898DerivedBytes.
The only way I see doing this even more secure is by finding a way to store the Salt other than in Plaintext.
What do you think?