Suppose, given an agent belonging to a company, having its own pair of public / private keys, that you want to certify with confidence that it was really that agent belonging to that company to have written through a particular transaction the data on the blockchain. In Ethereum, you could publish your address on the company website while, in Sawtooth, how could I do? Is it possible to use public key or is this not good for security reasons? Is this a suitable use case for Sawtooth?
The public key is for public good and there is no reason not to widely publish it and make it available.
The usual problem with public-private keypairs is people leak the private key or do not secure the private key properly and have it lost or stolen.
Related
I am trying to implement direct Integraion of Google pay into our website and in docs, it is mentioned that merchants have to anually rotate the keys in case of direct integration and old private key should be supported upto 8 days after removing of public key. My question is can I always use old private key during decryption even after rotation of public key? I can update the new public key anually but I would like to use the same old private key. Will it work forever during decryption or is there any time period which it gets invalidated?
I have seen that in the released projects (like Supply Chain) an off-chain database is used to save the user's information and state data. Is it possible to avoid using this database to save user information or is an implicit pattern of Sawtooth applications?
Private keys must be stored securely. At a minimum that means making the private key file unreadable to everyone but the owner (uw+o or 0600 permission). It is also a good idea to restrict access to the machine storing the private keys, if possible.
Better yet, use a software or hardware keystore (such as a hardware HSM).
Sawtooth does not store private keys in the global state or any database.
Public keys, which are not used for signing (just verification) are present in transactions and the blockchain.
I need to know how this bitcoin exhanges generate the unique address for the new user on their exchanges
For all intents and purposes the addresses are generally generated using a cryptographically secure random number generator.
Some exchanges may resort to a BIP32-style private key derivation in which private keys for user accounts are generated from a single secret, using hardened derivation for each user's key group. But from outside these are indistinguishable from randomly generated private keys, let alone the public keys.
I'm new to the world of Bitcoin, and I am having a hard time trying to understand the basics of wallet implementation for a basic bitcoin service.
Basically, I'd like that:
Users have a personal wallet ("in-site" wallet, keeping track of their balance)
Users are able to deposit/withdraw into/from that address/wallet
The web service is able to make transactions on behalf of the user
(to other addresses)
I know there are plenty of ways to go about this, and there are many APIs that can help, so I will narrow this problem down to using BlockCypher's API, which I believe has many similarities with other APIs.
I'd just like to know the general steps one should take to implement this, since I'm pretty much lost. How do I start?
I was thinking that the steps I should take are:
With the API, generate an address (server side?) and store the private and public keys in a database. Use the same address for the same user all the time.
Use the transactions API to do the rest and keep track of Bitcoin balance.
However, this put me off a bit (coming from BlockCypher's API, on address generation):
The private key returned is immediately discarded by our servers, but
we advise that these keys should not be used for any high-value—or
long-term storage—addresses.
The wallets I intend to use would be considered "long-term" storage, I guess, so what other way I could go about implementing such a system?
I'm sorry if this is a very basic question, or if I'm misunderstanding. It'd be great to have some guidance on the right direction; of course I don't expect full-code examples, just an explanation of the concepts. Thanks.
The Bitcoin private key is essential to using the wallet. Bitcoin is based on the PGP idea - one private key corresponds to one public key.
The API that you are using immediately discards the private key, otherwise they would be able to spend the money in every wallet they generate. They would do this by creating transactions and signing them with the private keys that they had.
So they generate these private keys in memory, send them to you via the API, and then discard them. BlockCypher's discarding the private keys does not impact your receipt of these keys. You still get the keys via the API and will have them in memory on your server.
You need to store these private keys in persistent storage, such as a database. Once you do that, then you can transact on behalf of users.
In regards to the long-term storage aspect, they are referring to the strength of the private key used to generate the wallet. Given this, they are likely not extremely strong (it does not mean they are weak!). You want a strong private key so it is not easily hacked or guessed. For long-term storage, especially of high dollar amounts, those wallets are available on the blockchain and are a hacking target. For long-term storage, you're better off with a Trezor or reading up on encryption (which is best done at security.stackexchange.com.
Access for all files by default is private. But I want to share (time limited) URLs with clients. eg.
http://bucket-test.s3.amazonaws.com/stockphotopro_75275855PCL_no_title.jpg?AWSAccessKeyId=XXXXXXXXXX&Expires=1300947912&Signature=YYYYYYYYYYYYYYYYYYYYYYY%3D
Is it safe to share AWSAccessKeyId (public key) ?
Can someone guess private key (using brute force) ?
The AWS access key ID is not secret - it's effectively your username for authenticating with Amazon services. Think of it like an email address, or your username on this site: I still need your password (secret key, in Amazon's case) to log in.
It would be very difficult to brute force the private key (I don't want to say impossible, but as close as you can get to that). I imagine Amazon would implement some kind of rate limiting and IP blocking should you repeatedly attempt to authenticate with an incorrect secret key.
I am not sure I would necessarily make your access key publicly known, but from a risk perspective having your access key publicly known would have little to no impact. If you google "AWSAccessKeyID=" you'll find a number of well known sites who put their public keys in their URLs.
Just don't go around handing out your private key!