How do bitcoin exhanges generate the Unique public address for the new user in their exhange? - bitcoin

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.

Related

Verify physical item with pgp key online by decrypting the private key

I want to sell some of my collectable items that I have been collecting over the years. But I don't want to just sell it, I want to add a QR code to the item (back of the painting, on the deck of cards etc.) and have that link to a website that can verify the item is the real thing.
I was thinking of using pgp-keys (public/private) to verify the item.
Is there already a way to do this or would I have to write something to decrypt the private key for validation? What language would be able to do this, can I do it in python?
This depends on what you are actually seeking to do.
You could embed a message that you sign with your private key, which can then be verified to be authentic with your public key.
If you want the message to be encrypted, you will need to pass a private key to the buyer and encrypt the message with the corresponding public key.
Generally, you don't need the private key unless you are doing encryption or signing. There are libraries for PGP in essentially all programming languages, python has python-gnupg for this.

Human readable way to represent PGP keys (Decentralized client authentication)

I'm working on a distributed application, and we need a way to authorize clients. Every client has a PGP keypair associated with them, and we require them to enter their private key (which is not stored) through which their pubkey is derived and used to identify clients and modify their fields on the distributed database.
Now, considering user experience, entering a private key on a website whenever you need to do something is troublesome. But we also cannot maintain a central database for username/password based authentication as that creates a single failure point (not what the distributed application is meant to do)
I am hoping there is some way to get an easier to remember human readable descriptor of the private key which can be used to authenticate if something like that exists. Any other ideas are appreciated too.
I'll throw a bunch of ideas to clarify the question:
Are you certain that PGP is suited for your needs?
I feel like you should provide some more details to be sure:
- How are the private and public keys used exactly? I understand the following : user inputs its private key, information is decrypted and modified, public key is deduced from private and used to encrypt the updated information.
- How is this different from using a regular password and being able to authenticate the user and encrypt data?
- You seems to send private keys on the network, and they should remain private.
How you could use a regular password:
User has a password, your application uses a function (e.g sha256, KDF,...) to make it usable by classical encryption algorithms (e.g AES). With the same (not stored) key, you can then encrypt and decrypt datas. You just have to make sure that decryption is valid, by adding a known value at the beginning of the data (e.g a part of the key).
Quick example:
password: "WeakPassword"
key: sha256("WeakPassword"+"MySalt") = 493e3ae...b2eec8ef
Decrypt(data,key)
clearData = "493e3ae{123;456}" //valid, because you can check the beginning
Encrypt(clearData,key)
Advantages: usable passwords, faster symmetric encryption
Use a QR code
If you stick to PGP and have a camera available it is pretty handy.
You could also use hexadecimal, base64, ... but for a 2048 bits RSA key, that still gets you hundreds of characters.

Is it a good idea to keep Sawtooth public key "public" like an Ethereum address?

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.

Do public keys HAVE to be used used to encrypt?

My question is: Does the public key in a asymmetric key have to be used to encrypt data or can it go either way (be used to decrypt)?
In RSA the public and private key technically fulfill the same role, one can decrypt what the other encrypted. The only difference is that one is made available to all parties.
Public keys can only be used to encrypt data, and private keys can only be used to decrypt data.
If you could decrypt data using a public key, that defeats the purpose of encryption.
Imagine you put your public key on your Facebook profile so that people can encrypt emails to you if they wish. If public keys could decrypt, then anyone that viewed your profile would have the key to all your emails (that were encrypted using that key pair).

Authentication/Decryption using a subset of Key

Is there a cryptographic system where a user(s) can be authenticated (or they can unlock a document) only if they present a subset, of more than one, the of valid keys?
Thanks in advance.
Non-anonymous authentication
If you don't require the users contributing to the successful authentication to remain anonymous, it's easy: The server generates a random nonce and sends it to the subset of users. Each user signs the nonce with his/her private signature key and sends the signature to the server. The server verifies each signature and if enough of them are present then the subset has successfully authenticated.
(Anonymous) Decryption
Someone else here might know of an RFC or a library for that purpose, but If there is none, I would design it like this: Split the secret into n parts where k of them are necessary to recreate the secret using Shamir's Secret Sharing. For each of the n users encrypt a different part of the split up secret with his/her public encryption key. When k of them decrypt their part of the split up secret, they can recreate the secret.
If the public key encryption is deterministic you can even make it anonymous in the sense that if you can get to the secret you can check that each other subset of k users would also be able to get the secret: In preparation of the protocol run you also have to designate a fixed x-coordinate for each user in addition to the public encryption key. When a subset of users successfully recreated the secret and thus the polynomial, they can evaluate it at each of the users x-coordinate and encrypt it with their public key. If the result is identical to those generated by the server, every subset of k users can decrypt the secret.
(Note that deterministic encryption has some caveats. For example, if the plaintext space is small, an attacker can just encrypt each plaintext and compare the result to the given ciphertext.)
Corollary: Anonymous authentication
Using the anonymous decryption you can create an anonymous authentication protocol by having the server encrypt a random nonce for k out of n people in the way described above and send it to the subset of users. They decrypt the nonce, check that each subset of k users would also be able to decrypt it and send the nonce back to the server.