We use RSA 2048 public key on our server for user identifier, but now I have a doubt about unique of this identifier.
Could I use RSA public key as unique user identifier on server or RSA does not guarantee this?
As per Wikipedia, you are allocated a number (usually a prime number) in the range of 0 to:
RSA-2048 = 2519590847565789349402718324004839857142928212620403202777713783604366202070
7595556264018525880784406918290641249515082189298559149176184502808489120072
8449926873928072877767359714183472702618963750149718246911650776133798590957
0009733045974880842840179742910064245869181719511874612151517265463228221686
9987549182422433637259085141865462043576798423387184774447920739934236584823
8242811981638150106748104516603773060562016196762561338441436038339044149526
3443219011465754445417842402092461651572335077870774981712577246796292638635
6373289912154831438167899885040445364023527381951378636564391212010397122822
120720357
This number is huge. This number scales to that larger than the number of particles in the universe.
Statistically it will never clash with another number, nor will anyone have the computing power to brute force what it is. By the time they do, the message will be meaningless
(..and most of the universe would have imploded)
No you cannot, but the probability that it is there twice is very, very low. In fact, if two users would have the same public key, they would know the private key, too. That would be a security issue and both users should create new keys.
Related
I noticed that libsodiums secret signing keys contain a copy of the public key?
What is the reason for this?
Does it have to do with how the ecdsa algorithm works or is it just for convenience?
Computing a signature requires the public key in addition to the secret key.
So, having it precomputed instead of recomputing it every time a new message has to be signed is faster.
But there is another reason. Using the wrong public key when signing may have catastrophic security implications. So, keeping both encoded together prevents misuse.
I need to recompute the hash of private data to proof the integrity of the data. When private data collections are used the private data are stored in SideDBs and the hash of the data on the ledger according to the documentation. Basically the question splits up into two subquestions:
How to access the hash of the private data?
Which method to use to recompute the hash that is saved on the ledger?
Thanks in advance.
I use Hyperledger Fabric v1.4.2 with private data. I followed marbles example.
I expect to be able to calculate the private data hash and verify that it corresponds to the hash saved in the ledger.
to get the SHA256 hash (using Fabric 1.4.x contract API) use:
let pdHashBytes = await ctx.stub.getPrivateDataHash(collectionA, readKey);
let actual_hash = pdHashBytes.toString('hex');
You can calculate the private data written on Ubuntu like shown below.
echo -n "{\"name\":\"Joe\",\"quantity\":999}" |shasum -a 256
and verify they match. So that's the mechanics of using private data method and verify patterns. Now lets add information about salting mechanics, as mentioned elsewhere in this post.
For most uses of private data, you'll most likely use a random salt so the private data cannot be brute force attacked in the permissioned blockchain network (between agreed parties). The salt is passed along in the same transient field as the private data. And (later on), it will need to be included with the private data itself, when recalculating the private data hash. See https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#protecting-private-data-content
Don't use it, private data is security hole.
It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.
The logic behind Privated data is simple, it puts data in a local embedded data store and puts a hash of that data on Blockchain.
The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm (which is also very standardized) will always get the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.
However, this also means anyone can “decrypt” the data behind the hash by using dictionary attack.
Hashing is cheap, the cost of each hash on a normal laptop CPU core is about 3 microseconds, basically I can create 1 billion candidate hashes within one hour on a single laptop CPU core, and compare them to the hashes on Hyperledger Fabric DLT.
And I am just talking about using a single core on my laptop, not even 50% power of my laptop
Why is it dangerous? Because if an attacker is connected to a Blockchain system, the attacker knows the range of the data being hashed (etc, trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash out.
How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.
To their defense, Hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value because attackers would see it, so you have to create another P2P connection with counter party. If you need to create connection with all the counter parties, what’s the point of using Blockchain in the first place?
It’s just scary that so many people are using this security whole.
i want to know performance wise which is better to provide message authenticity, ECDSA signatures or hash based signatures, although i have read the comparisons of ECDSA with RSA, but not found with hash based signatures. Can ECDSA signatures replaced with Hash based signatures improves the message authenticity or not.
ECDSA is a hash based signature, in that the data gets hashed, then ECDSA is performed on the hash (not the whole data)
When it comes to data verification there are three main approaches:
Straight hash (e.g. SHA-2-256)
The fastest option to verify
If you are only protecting against line corruption this is a valid choice.
Otherwise, requires that the hash/digest value be sent over a secure (from tamper) channel, because the tampered can easily transmit the digest along with the tampered document
Provides no proof of origin
HMAC (e.g. HMACSHA256)
Requires that both the sender and receiver share the secret key
Either the sender or receiver having the key stolen puts both sides at risk
Secret key needs to come from key agreement algorithms (ECDH) or be transmitted in secret (encrypted)
Proves the document came from someone with the shared secret.
Digital Signature (e.g. ECDSA, RSA signature)
The sender is the only entity with the private key, receiver needs public key (non-secret)
Public key can be embedded in an X.509 certificate to provide a notarized association of public key to the signer
Or the public key can be transmitted raw over a secure (from tamper) channel.
Provides strong assurances about the document origin, since they shouldn't share their private key.
All three options use a hash algorithm to reduce the original data, the rest of the algorithms are what do you do with that data. There's not really a standard definition of "secure", you have to say "secure against (something)". ECDSA provides more assurances than HMAC as long as the private key isn't shared. But if HMAC provides enough assurance it is probably faster on average (specialty hardware aside).
Scenario
A SOAP web service provides an interface for retrieving documents and data. Security is paramount.
WS-Security is used and both the client and server encrypt and sign the entire SOAP envelope.
Questions
Should the private key used for signing be compiled into the application and stored on the device or should it provided by the server using a key exchange protocol (perhaps after authentication of the user)?
Should the private key for decryption be stored on the device or provided by the server?
Is it realistic to have a unique key for each file that is to be decrypted by the server (if uploading from client) or decrypted by the client (if downloading from server)?
Just a couple suggestions:
-You should consider symmetric keys embedded into anything outside your server as public due to reverse engineering (i.e. don't bother even encrypting if the key is out in the wild).
-You should use a per-session symmetric key generated by a secure RNG on the client, and transmitted to the server encrypted with the global asymmetric public key. Private keys have a shelf-life.
-You can use the session key for all files/streams transferred in that session, but you should use a unique nonce to salt the symmetric-key encryption for each file. Depending on the encryption mode, using the same key/nonce with more than one stream can leave you vulnerable to XOR'ing the two streams and recovering a mashed-together but unencrypted result.
The entire concept of a private key is defeated if it has to be transmitted from one device to another. Each end of the communication channel must generate their own private keys. Note, that this doesn't mean compiling private keys into an executable, because then everyone with the executable shares a private key, which is obviously not what you want. Each individual device has to use a cryptographically secure source of random numbers to generate it's own public/private key pair. Then public keys can be exchanged in the clear, you can use them to exchange session keys (which can be unique for each and every file), private keys can sign, and everybody is happy.
But remember: Never, ever hard code private keys, and never, ever share them with anybody.
I'm working on a Single Sign On solution to allow my company to integrate with other vendors.
As I'm doing my research, one thing is constantly confusing me.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key. So far so good.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing). To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
Encryption and signature are two different systems. In some ways, they work in opposite directions.
With public-key encryption, anybody can encrypt data with the public key. Only the owner of the private key can decrypt encrypted messages to recover the data.
With signatures, only the owner of the private key can sign messages. Anybody can use the public key to verify the signature of a message.
My understanding of Public/Private key is that data is always encrypted with the vendor's public key and they decrypt using their private key.
That's correct. But it only covers public-key encryption, not other uses of public-key cryptography such as signatures.
However, to validate that the message is really coming from me, I will compute the hash of the message and encrypt the hash with my private key (this process is also known as signing).
Actually, this process should only be known as signing. Calling it “encrypting with my private key” is very misleading: that's not the way it actually works. There is one popular type of keys (RSA) which can be used for both signature and encryption, but even with RSA, the signature and decryption mechanisms are different.
To verify that the message is coming from me, the vendor will use my public key to decrypt the Hash and compare it with the unencrypted hash. If they match, the vendor can be confident that it came from me.
That's not quite correct. Many signature algorithms are not deterministic. Verifying a signature is not done by reversing the signature process, but by making some slightly different calculations involving the signature, the message and the key.
So how come my private key is used to encrypt the message..and how can public key decrypt the message? I thought Asymmetric keys doesn't allow that..! i.e Public Key always encrypts and private key always decrypts. Any explanations will be greatly appreciated..!
The private key is used to sign the message, not to encrypt it. The public key is used to verify the signed message, not to decrypt it.
i found this link very helpful :
http://www.nusphere.com/products/library/ssl.htm
Wayback Machine archive from 2007 of the above nusphere link.
HTH
Ohad
EDIT
after 2.5 years, I see that the link is broken. So this one is good as well.
And in case it will be broken again in 2.5 years from today, here is the summary:
The Public Key is what its name suggests - Public. It is made
available to everyone via a publicly accessible repository or
directory. On the other hand, the Private Key must remain confidential
to its respective owner.
Because the key pair is mathematically related, whatever is encrypted
with a Public Key may only be decrypted by its corresponding Private
Key and vice versa.
Public Key Cryptography can therefore achieve Confidentiality. However
another important aspect of Public Key Cryptography is its ability to
create a Digital Signature.
The difference between symmetric and asymmetric encryption is only the existence of private and public keys.
Nevertheless in the common algorithms you can use the private key to encrypt messages which can be decrypted with the public key and you can also decrypt messages which are encrypted with the public key. So it is possible in both directions.