I understand that Bitcoin protocol is based on an asymmetric cryptography.
Regarding digitally signed transaction, I understand the Verification Process of bitcoin transaction which is explained in Bitcoin Wiki. (https://en.bitcoin.it/wiki/Transaction#Verification)
By the way, I've read some article about 'bitcoin transaction verification' by chance.
-> https://medium.com/#aalim.khan/bitcoin-transactions-scripts-and-digital-signatures-506688e1630a
While reading the article, questions arose about the following image.
https://miro.medium.com/max/700/1*zJ_GgIr2YEZGs74BTfyB_A.png
The image depict that some kind of verification process.
But, I couldn't find a comparing process of the image in bitcoin wiki or source code.
The image describes these below 2 transactions are equal, then the signature can be verified.
- Transaction Hash that is decrypted by public key
- Transaction Hash that is double hashed of requested transaction
Is there anybody who can explain? Is above process really working in bitcoin?
I've found bitcoin source code of validating that the transaction is not tampered.
See below link:
https://github.com/bitcoin/bitcoin/blob/v0.16.2/src/script/interpreter.cpp#L1264
Related
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.
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.
I'm trying to compute digital signature RSASSA-PSS with sha256 for my IdentityIdentificationData (ASN1).
Directory file address 0x3D00
Aplication ID A000000061123A22738F4421
Private key folder 0x2F01
My ASN1 encoded hex data after sha256 encoded:
860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b0
I'm sending this command after SAM pin verified
MSE:SET
002241B606800191840110
SW1SW2:9000
Select File
00A40800043D002F0100
SW1SW2:9000
PSO: Compute Digital Signature
002A9E9A20860c30a5f2b254ee92cbd3ec5c4282a940853aaef5f36d50ca20050637aaf4b000
SW1SW2:6982
I'm a bit new on smart cards. How can i solve this problem. What is wrong or missing.
My SAM don't want to algorithm identifier for RSASSA-PSS.
6982 means: Security condition not satisfied
You should probably send the VERIFY PIN command directly before the PSO: Compute Digital Signature. Signature generation generally has very high requirements with regards to PIN, because the user has give consent for each and every signature. Hence the PIN may be invalidated by each command, especially if that command is an MSE:SET command. Selecting a DF by name may also influence the security environment.
So try the following order:
SELECT by Name (AID)
MSE:SET (for digital signature)
VERIFY PIN
PSO:COMPUTE DIGITAL SIGNATURE
The signature may also be depending on other security related objects such as an authentication key, for instance one used to setup secure messaging.
Can you check the access condition of RSA_Sign key ? If the access condition is NEVER then you wont be able to sign with this key. So in such case, SW 6982 make sense.
002241b606800191840181 mse:set is worked on me.
Having trouble with the PURCHASE_CANCELED error in Wallet for Digital.
A. I can successfully round-trip JWTs between
https://sandbox.google.com/checkout/customer/gadget/inapp/demo.html
and
https://developers.google.com/commerce/wallet/digital/docs/jwtdecoder
...of course I can, they're both Google tools.
B. I can successfully pass from PyJWT to the decoder, seems no info changes.
C. I can successfully pass from the demo to PyJWT, seems no info changes.
D. The request in the .buy() failure callback is correct.
This is extremely frustrating, to have no feedback from Google Wallet when it does PURCHASE_CANCELED.
I cannot make identical JWTs between PyJWT and the demo encoder. Even with exactly similar data in exactly the same order, the result varies at the end of the long string. Does this matter?
Is there any way of independently generating the signature (encoded) to verify against?
Does the order of keys in the object to encode matter?
Edit:
In the Order History, Wallet says "Google has sent the customer an order confirmation email." No emails arrive to my test buyer.
Also in the Order History, Wallet says "The customer's credit card was authorized for $3.00, and passed all risk checks". Looks promising.
I remember reading that, in the Sandbox, no banking or tax info is necessary. However, Google Books held me up for months on "selling" a $0 (free) book in Google Play due to lack of banking/tax information; without it, the book never made it through the approval process, no other explanation given. Does the Sandbox need even fake/placeholder information to allow .buy() transactions to proceed?
Flow is now working, postbacks are appearing at the server.
Estimated delay was 5-6 hours between sandbox setup and start of postback activity.
No changes made within sandbox tax/banking info.
Last summer, I was working on an application that tested the suitability of a prospective customer's computer for integrating our hardware. One of the notions suggested was to use the HTML report generated by the tool as justification for a refund in certain situations.
My immediate reaction was, "well we have to sign these reports to verify their authenticity." The solution I envisioned involved creating a signature for the report, then embedding it in a meta tag. Unfortunately, this scenario would require the application to sign the report, which means it would need a private key. Once the application is storing the private key, we're back at square one with no guarantee of authenticity.
My next idea was to phone home and have a server sign the report, but then the user needs an internet connection just to test hardware compatibility. Plus, the application would need to authenticate with the server, and an interested party could figure out what credentials it was using to do that.
So my question is this. Is there any way, outside of obfuscation, to verify that the application did indeed generate a given report?
As Eugene has rightly pointed that my initial answer was to authenticate the receiver. Let me propose an alternative approach for authenticating the sender
authenticate the sender:
When your application is deployed at your client end, you generate and deploy a self signed PFX certificate which holds the private key.
The details of your client and passphrase for the PFX is set by your client and may be you can get it printed and signed by your client in paper to hold them accountable for the keys which they have just generated..
Now you have a private key which can sign and when exporting the HTML report, you can export the certificate along with the report.
This is a low cost solution and is not as secure as having your private keys in a cryptotoken, as indicated by Eugene, in the previous post.
authenticate the receiver:
Have a RSA 2048 key pair at your receiving end. Export your public key to your senders.
When the sender has generated the report, let the report be encrypted by a symmetric key say AES 256. Let the symmetric key itself be encrypted/wrapped by your public key.
When you receive the encrypted report,use your private key to unwrap/decrypt the symmetric key and in turn decrypt the encrypted report with the symmetric key.
This way, you make sure that only the intended receiver alone can view the report.
I'd say that you need to re-evaluate possible risks and most likely you will find them to be not as important as you could think. The reason is that the report has value for you but less likely for a customer. So it's more or less a business task, not a programming one.
To answer your concrete question, there's no simple way to protect the private key used for signing from being stolen (if one really wants to). For more complex solutions employing a cryptotoken with private key stored inside would work, but cryptotoken is itself a hardware and in your scenario it would unnecessarily complicate the scheme.