Is there a way existing for Fabric to calculate/recalculate signatures/hashs in using the SDK?
It would be extremely difficult for an SDK or REcalculate. Without the help of the SHA3 SHAKE256 algorithm, SHA or MD5 cannot be decrypted (encryption is still possible using class hashing - just don't use MD5 hashing to save passwords since it is not secure) The SDK will have to know all the raw data to REcalculate the previous hash.
But the procedure to calculate the previous hash in hyperledger fabric would be:
Serialize the Block message to bytes using something similar to the protocol buffer library in hyperledger fabric.
Hash this serialized block message to 512 bits of output using something similar to the SHA3 SHAKE256 algorithm in hyperledger fabric.
Some websites do allow to decrypt the data but that is only because they have a database of all the public hash: example website
Using the above link, you can encrypt the data and store them on the website (or maybe create your database yourself) and then call the details using an API - but this can be done only if you already know the data corresponding to the hash.
Hope it was helpful.
Related
I am thinking about storing secret in blockchain. Although there is some specific blockchain dealing with it, I would like to see the feasibility in ethereum.
The idea is to store the secret as a state variable in encrypted format and the accessibility of this variable value is restricted to someone only. My question is, since blockchain is open and everyone, if someone is really skillful then he/she could read the value of the every variable. Do you think, or what is needed to do further, to make the value of the state variable secured enough?
People who own the machine running an EVM full node will have access to that variable. That accessibility limit is pointless in regards of keeping the data secret.
You could store encrypted data on-chain. But you need to keep the decryptor off-chain. E.g. you AES-encrypt a piece of data and post it on-chain, but you keep hold to the private key.
I should point out that an ethereum wallet, aka a secp256k1 keypair is capable of data en/decryption. You can encrypt data using public key, post it on-chain, and later fetch then decrypt with your private key, which is of course off-chain. Read more here.
I want to know if there is a library for encrypting data on the chaincode for node.js, and if there is, how do i use it? or is there somewhere that explains the functions?
I've seen the chaincode encryption section in the Chaincode for Developers page, the problem is that it only explains the libraries about the Go languange (maybe I misinterpreted it).
I hade the same question before. Below is that I figured out.
Here is the library in node for the chaincode encryption section that you read in Chaincode for Developer.
This library is under development, so there is no documentation, but you can take a look at the code and some test they made. Basically, if you don't want to write to the world state with the raw value, rather an encrypted one. The chaincode invoke function takes encrypt key from transaction proposal's transient field and do the encryption. Similarly for decryption, sign/verify.
The difference between this lib and other libs (e.g: node-crypto if you write chaincode in nodejs) is that it takes keys from transaction proposal transient field. If you could manage to get the public/private key somehow, then node-crypt is enough. Just make sure to use the version that fabric supports (prerequisites).
Hope this helps.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are using Firebase Database Rules to secure our database. We also would like to add additional security by encrypting sensitive user information. Right now our encryption approach is:
Encrypting user data client side with a public key before the user writes it to the database
Decrypting with the private key on the server before delivering the data to the user through a GET request
Our private key is a string hardcoded in the server code. We want to secure the private key using KMS’s encrypt/decrypt methods, and store only the encrypted private key in the code.
An encrypted private key will be stored in the server code, and it will be decrypted using KMS on runtime, this way the developers won’t have access to the private key.
However, we wasn’t sure if there could be a better approach using Cloud KMS. Can KMS be used for client side encryption and server side decryption together? Or what is the best practice to use KMS to enhance database encryption?
Your question is a good example of why you should not implement encryption and data security unless you know what you are doing. Your implementation is severely flawed. Asking is a good first start, but there is a lot to cover.
Normally, you do not use Private/Public key pairs to encrypt data. Public-key cryptography is used to securely negotiate a symmetric encryption key. Public-key cryptography is also very expensive in CPU time compared to symmetric encryption.
Example. Why bother to encrypt the data at the user side, if you are going to decrypt it on the server before sending to the client?
Hardcoding the private key in the server code is a horrible practice. This almost guarantees that your key pair will be leaked.
Yes, using Cloud KMS will be a huge improvement for you. This will make security easier to implement and remove some of the management headaches for encryption. However, you will need to understand KMS and encryption best practices. Poorly designed security is very easy to break. Poorly designed security is very easy to lose track of rending data inaccessible.
In simple terms, you will want the following at a minimum:
Encryption Key Management
Key Rotation
Encryption at Rest
Encryption in Transit
Separation of responsibilities (admins cannot decrypt data)
Unless there is a good design reason or compliance requirement, you should not be encrypting data at the client - the client should not be managing keys. The data should be transferred securely using an encrypted transport protocol. Your server should be controlling and managing encryption for the database. The database should be encrypting data at rest also.
I could go on and on and this is why there are large books written on this topic.
I think your plan sounds like a decent one. Yes, you can improve security by wrapping your private key with Cloud KMS; then, you could put the wrapped key into your source code or your application's configuration files, then when it starts up, unwrap to get the private key. This would let you mitigate the risk of having the key which can decrypt the database handled by your developers.
Another approach would be to not use local crypto: instead, you could call KMS to encrypt and decrypt data every time a row is written or retrieved. This might give you some benefits (the key isn't even known by your binary; you get rotation, etc., as a part of the KMS solution; and you can get logs of every key use), but would have some costs (you now depend on the KMS service for every request; latency of KMS requests may decrease performance; the request-per-access costs more money than just unwrapping on startup; and you depend on channel encryption to protect the user data as its sent to your service, since you'd now be encrypting service-side).
KMS now also has asymmetric crypto support (docs here) so you could combine the two: do public key encryption client-side then use the asymmetric KMS key to do decryption for each request. Pros & cons are similar to above, except that you can keep the same data exposure and client-side encryption that you currently have.
I agree with another answer that the security benefit of doing client-side encryption here isn't entirely clear since the service has the authority to decrypt; it's not clear that having it do the encryption as well would result in increased risk. But using public key as you describe doesn't clearly lead to increased risk (presuming you do it well and correctly, not a trivial matter).
Thanks for your question and for using Cloud KMS; please let us know if you have any further questions we can help with!
I want to create and manage user sessions with AES256 encrypted tokens.
I am using node's crypto library and followed this stackoverflow question.
I am using this to create session token that will be sent to frontend and stored in the backend for verification purpose and the data is stringified JSON.
Here I see two things one is password and other is iv.
so two questions,
Is the iv is safe to sent to frontend (iv + "." + encData)?
How should the password be generated? How about a SHA256 of (e.g. user's password that I store in db at signup)
This way I will be using a different password for each user. Is this approach correct?
P.S. Both of the answers below helped a lot, If you are here, do read all the comments and attached So question and the linked articles.
Let's keep to the question at hand:
Is the iv is safe to sent to frontend (iv + "." + encData)?
Well, yes. The IV may be public knowledge; as long as it is unique and - in the case of CBC mode encryption - random then this is fine. Of course, the IV and encData should be suitably encoded, for instance using hex (as in the linked answer) or base 64. This is not often done as the IV is always 16 bytes for AES, so it is easy to simply prefix the binary IV to the encData instead.
Beware of hackers changing the input; if the dot or colon is removed then you may have just an array of one element and accessing the ciphertext may result in an error or the decryption of empty data.
How should the password be generated? How about a SHA256 of (e.g. user's password that I store in db at signup)
No, you should use a password hash for that; SHA-256 is a cryptographically secure hash but not a password hash such as PBKDF2, bcrypt, scrypt or Argon2. And if you want to store something in the DB, then please do not let that be the AES secret key generated from the password.
This does not in any way invalidate any of the concerns in the answer of TheGreatContini. This is not security advice, just the cryptography related advice you asked for.
You may want AES encryption, but encryption is not what you need! For the security of your application, message integrity is more important than encryption.
Encryption does not generally provide message integrity (see section 7 of Top 10 Developer Crypto Mistakes) unless you specifically use a mode of operation that provides it (such as GCM mode). Therefore, the solution you are designing in inherently wrong. More info in footnote (!) below.
Understand what you need -- message integrity + encryption, or message integrity only. If it is message integrity only, then use HMAC.
Another thing you need to understand is that functions like AES and HMAC do not use passwords, instead they use cryptographic keys. See section 6 of Top 10 Developer Crypto Mistakes.
It is not clear whether your question on IV matters, given that your approach is wrong, but to answer it anyway, the IV does not need to be secret. See section 2 of Top 10 Developer Crypto Mistakes.
I generally agree with the comments above: use JWT the way it was meant to be used rather than trying to build your own solution. JWT has a claim reserved for expiration, so there is no reason not to.
footnote (!): If you want to see how confusion between message integrity and encryption gets abused, you can try this exercise from Pentester Labs (unfortunately it requires a subscription, but it is cheap). Granted that this is for ECB mode, a similar concept can work for CBC mode.
Assuming I have a ASP.NET MVC 3 application that runs in a web farm where each web server belongs to a workgroup (as appose to a domain with shared accounts). The web farm is also auto scalable, meaning that the number of instances are dependent on the load. Sensitive data is encrypted and decrypted when stored/retrieved from the database. The symmetric and asymmetric keys are stored on each machine and protected with ACL and encrypted using DAPI (using the machine key).
For compliance and security reasons it is required that keys be rotated on a regular interval. How would you design/modify the system to automatically rotate keys at a regular interval without bringing the system offline? Assume that there are an arbitrary number of tables each with an arbitrary number of columns that are encrypted using the keys.
Many Q&A are related to which algorithms to use and how to secure the keys, however few actually address how to design and implement an application that would allow those keys were to be rotated, especially in a dynamic environment (autoscaling environment) sharing a database.
Having multiple keys in your system
When having multiple encodings (or encryption schemes, keys) what you usually want to do first is introduce some kind of versioning scheme as you need to know which key has been used for this particular piece of data. You have several choices for this:
Timestamps: Save the timestamp the data has been encrypted with the data. Then divide time into intervals of some length where the same key is used.
Version numbers: You can also simply assign increasing version numbers.
Key fingerprint: Store they key's fingerprint with the data
In every case, you need to store all keys that are currently in use to be able to decrypt data. When reading data, just look up the key matching your version identifier and decrypt. When writing, use the currently active key and store the encrypted data + your version identifier. You can retire (aka delete) a key when you are sure there is no data encrypted with this key in your database.
Deploying new keys
Whenever you roll over to a new key, this key has to be generated and deployed. You can do this in a central fashion or use some distributed key agreement protocol.
Re-encrypt data
If you need to re-encrypt data, you can do it in two ways:
Background process: Having a background process that just retrieves N data items with an old versioning identifier, decrypts and re-encrypts it and stores the result. Sleep a bit between runs to not overload your system.
Update on access: Whenever you read data and you notice that it has an old versioning identifier, re-encrypt with the current key and store the result. This might not re-encrypt everything depending on your data-access pattern, so an additional background process might be necessary.
Asymmetric crypto
If you are using asymmetric crypto (I guess for example for storing credit card numbers, webservers only having the public key to encrypt and the payment processor having the private key to decrypt) it gets a bit tricky, since only the machines with the private keys can re-encrypt data. All other aspects are the same.
Google's Keyczar provides such a framework, but there ins't a .Net version.
Maybe you could wrap the C++ version in a .Net wrapper ?