If you're seeing this message, it means we're having trouble loading external resources on our website.

If you're behind a web filter, please make sure that the domains *.kastatic.org and *.kasandbox.org are unblocked.

### Course: Finance and capital markets>Unit 8

Lesson 8: Bitcoin

# Bitcoin: Digital signatures

A high-level explanation of digital signature schemes, which are a fundamental building block in many cryptographic protocols. Created by Zulfikar Ramzan.

## Want to join the conversation?

• How is the verification actually made? How can we know that Alice actually has the correct private key and how can we tell when someone tries to forge it? It would be very interesting with a minimal example of what that mathematical relationship could look like, even if the example has none of the necessary security measures.
• If you go to the applied math section on the Khanacademy site and look under the modern cryptography section, Brit Cruise does a very detailed explanation of the algorithm for RSA encryption. It takes him numerous videos to explain it fully though.
• At about it is said that the Public Verification Key basically outputs a "yes" or "no" for accepting a signature. How does this work ?
(1 vote)
• The check function has an output, which may be the signature, for example. I may want to tell you my garage key code 47913 and note, so you can be sure it's me, ER (Exponentially Radical). If we see E as 14 (i.e. E may be 14, in hexadecimal or something) and R as 27 (i.e. R is the 18th letter of the alphabet, add 9 to avoid mixing letters with numbers). My message 47913 ER would be read, by the checking program, as 4-7-9-1-3 and 14-27. The checker may add the digits in the first part of the message 4+7+1+9+3=24 and multiply the digits, in the second part 14*27=378. Since the checkers like to limit digits to say 2 digits, this checker may add the numbers 3+7+8 to get 18. The check function may be designed, to subtract the smaller part, from the bigger part 24-18=6. But 6 is just one digit. To maintain a two-digit digest, the program may consistently append an A So I'd send:
47913
E R
6A
and you'd be able to verify that 47913 ER really makes 6A so you have the correct garage code (perhaps, to deliver me chocolates, while I'm away), you'd know it was from E R, and you'd know it would have been impractically difficult to forge. If 47913 ER doesn't make 6A, the message is a fake!

If you were to change the message, from ER, my initials, to EB, your initials, the signature becomes 14, which is very different, from 6A. The changed message is clearly a forgery. As long as the checker function is much more complex than the one I described or its operations remain secret, then covertly forging messages will stay practically impossible.
• Does it mean that every signature would be different for each message? And would Alice have any say how the signature will look like or is it just randomly generated combination of letters and numbers? And what happens if Alice forgets her signature or does she have to remember it at all?
• That's correct. If you have two distinct messages, then with overwhelming likelihood, their signatures will be different. Note that the number of signatures is finite for typical digital signature schemes since the output length for them is fixed. However, the number of possible messages is infinite. So it is theoretically possible that two different messages will have the same signature. However, for a well designed digital signature scheme, it should be infeasible to find two such messages that have the same signature. (By infeasible, I mean that it would require an astronomical amount of computation and would not be remotely practical.) Also, typical digital signature schemes have some randomness incorporated in them. This way even two instances of a signature by the same person on the same message will look different. The "Digital Signature Standard" (DSS), which is what bitcoin uses, has this property that a random sequence of numbers is generated whenever a message is to be signed. This sequence of numbers is incorporated into the signature to help ensure that it looks different each time. I hope this helps answer your question.
• What exactly links the verification key to Alice? What would prevent me from taking her public key and claiming it is mine (as such, messages signed by her would be claimed to be signed by me)? I guess what I am asking is: how can you verify that a public verification key belongs to a certain identity?
• Alice will have to do her best to keep her private/signing key safe and secure (also, most key algorithms allow encrypting the key itself with a password). In a non-bitcoin use of this crypto, you and Alice would probably meet and exchange keys, therefor guaranteeing its source. In bitcoin-land you don't actually care if the key belongs to Alice or not, although Alice will have to keep her private key private, or otherwise people could spend her money.
• Why is it important to create a short hash for your message rather than just using the original value? How exactly do you create a hash for your message?
(1 vote)
• You need to hash together your message and your private key in order to create a digital signature. The entire message is hashed into the digital signature for two reasons: first, so that you have a different digital signature every time, and second, so that no one can change the message along the way.

This second reason is worth elaborating on. When you broadcast a transaction to all the nodes, what you are really doing is broadcasting a transaction to eight nodes, and then expecting the eight of them to relate that transaction to seven more nodes each, and expecting all of those to relate that transaction to seven more nodes, and so on. So, if one of the earlier nodes decided to change the transaction, you would have two competing transactions, one of which is fake. So, we have you hash the entire message along with your private key to create a digital signature, so that if someone does try to change the transaction, the digital signature would be invalid.
• Checking my understanding of collision resistance:

If you have a message that says 2+2 you can never have another message that says 3+1. Am I right?

Also, If I just want to use Bitcoin, do I need to know this stuff? Is it this hard to use? I ask because I'm finding it really hard to find videos online of how to actually use Bitcoin that actually display its use and describe it in a way that avoids jargon. This is despite the fact that the community calls for new users to carefully research things like how to be secure in ones use of Bitcoin.

With new technology like this I would normally just dive in and try it out, but I'm really apprehensive about approaching it in this way. The tendency for the community to talk in this kind of jargon is a huge barrier to the uptake of the tech.
• You actually don't need to know anything about the specifics. You can just create a wallet and start using bitcoin. But these things are helpful to understand the technology behind bitcoin and why it works.
• Let me get this straight. For signature verification, both the message, and it's signed hash are sent over plain, and then are verified by "unsigning" the hash, and comparing that to the hash of the received message?
• The original message and the signature are both sent over. The receiver uses the public key (aka verification key in the video) to verify that the signature is in fact of the message.
Signatures are not use to encrypt - they are used to verify that nothing has changed during transit.
(1 vote)
• At , Alice generates the signing key and the verification key. Is this analogous to a user deciding a on a secret password, then transforming it through a function to produce a public key? Does this mean that there is a chance that more than one person can come up with the same signing key through random chance alone? I guess it is also possible for people with the same name to have the same physical signatures... But for digital signatures, is there a way to distinguish people with the same signing keys?
(1 vote)
• Yes. The way it works is your computer will randomly generate a private key and then use that to figure out the public key. And while it is possible that two people can have the same key, it is incredibly unlikely. There are 2^160 public keys, or 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976. That large number is enough to prevent any collisions.
• How is the verification key delivered to safely to the recipient? Is it sent with the message or is somewhere online?
(1 vote)
• The verification key is sent to all the nodes online.