CSC School: Cryptography#4

Jumping to the blockchain is not good for first step. Entering in it needs knowledge about cryptography. in this lecture we will look at cryptography that we need in blockchain ( specially CSC ) and its concept.

Cryptography

Cryptography, or cryptology, is the practice and study of techniques for secure communication in the presence of adversarial behavior. More generally, cryptography is about constructing and analyzing protocols that prevent third parties or the public from reading private messages.

Don’t know when to buy and sell, Try Copy trading.

Cryptographic signatures are a key part of the blockchain. They are used to prove ownership of an address without exposing its private key. This is primarily used for signing transactions but can also be used to sign arbitrary messages. In this article you will find a technical explanation of how these signatures work, in the context of CSC.

Public & Private Keys

We wanted to start this part with wallets and since they are software we need to install and set them up, so I thought that keys are part of the things that a crypto wallet manages for you, so let’s go first. keys.

The first thing to know about cryptography is that you should never lose your private key or initial phrase And please never forget this .

The rule is that you must type your private key into a secure crypto wallet program , And never save it as a text file on your personal computer or mobile phone , And it is too long to be remembered in the human mind , So write it down on paper to be sure ,For this reason, anyone who has access to your personal computer or mobile phone cannot read it .

In some countries, you have the fear that the government might be looking for your keys, but there is a greater risk of house burning or water damage, so make sure you have copies in different safe places.

If you don’t need a private key for development and testing, code it in a source file , Make sure you don’t use this development key for your daily trading , It’s not too bad when your key is placed in GitHub etc .

The same applies to your seed statement , which is a way to write a private key as a list of short words , As a developer, you work directly with the private key , But finally, users use their private key as an initial expression when they move between cryptographic and paper wallets.

You should also know that you should not share your address and public keys with people for no reason, so that no one can directly steal your tokens without your private key . The attacker can send you tokens as phishing , These can lead you to programs on the web that try to trick you into using your private key to do silly things.

What are Keys?

A private or public key is just a data type , In the particular case of ECC these two keys are very large numbers , so big that they store them as string or bigInteger.

Private Key

A private key for ECC is a randomly generated integer , which can be something like this hexadecimal :

In many blockchain networks, this key must be smaller than a certain prime number .

This is the big number in hexadecimal‌:

The reason for using this prime number is beyond the scope of this course , But the limit set by that prime number is important. Not every random integer is a valid private key , And if you want to create your own key, it must be smaller than the first number .

let privateKey  
do {
privateKey = generateRandomInteger()
} while(privateKey > 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2fn)

Public Key

A public key for ECC is two integers concatenated And that both of these numbers can have the length of the private key, but they are not random. These two numbers are calculated from the private key .

A public key is shown in the figure below :

A function to calculate the public key from the private key , It is based on a specific algorithm and some predetermined parameters , All systems that interact with the CSC network must use the same algorithm and parameters to achieve the same results.

let privateKey
do {
privateKey = generateRandomInteger()
} while(privateKey > 0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2fn)
const publicKey = generatePublicKey(privateKey)

Seed Phrase

The seed phrase is also known as the secret recovery phrase , A list of 12 to 24 short random words that is used to generate one or more private keys and eventually public keys and addresses.

A seed statement can be like the following example :

While you can directly generate a private key , Many crypto wallet programs use a key phrase to generate them for you , Many people use multiple addresses .

The idea of a seed expression is that it is a random list of words , But the algorithm of creating several private keys from that expression is definitive and this allows you to generate several keys from one expression , Retrieve all these keys from a seed statement, otherwise you must write down each private key separately .

The negative point is that if your seed phrase is stolen, all the generated private keys will also be stolen from it , This means that whatever is true for your private key is tenfold true for your initial expression because it is the same as multiple private keys.

Never write your initial phrase outside of a crypto wallet app on your PC or smartphone, never store it in an S3 bucket or GitHub, etc. To recover your keys if your smartphone or laptop is lost or broken, you can write the seed phrase on a piece of paper and keep it in a safe place.

What are the keys used for?

Well, up to this point in the story, you know what the keys are and how you should work with them, but what exactly are they used for?

Private and public keys are used for different tasks. Their usefulness comes from the fact that everyone can have your public keys and no one should have your private keys.

Signing Messages with the Private Key

They use private keys to sign data , Signing means that you attach a signature to the data. A signature is created with a signature algorithm that uses your private key and the data to be signed.

The point is that the signature data cannot be generated without having the private key .

A signature can look like this in Base64 version:

The public key is used to verify the signature, if you sign something with a private key, the associated public key in combination with the signature algorithm, the signature, and the signed data will either result in yes or no, this signature from the private key is correct.

When you are the only one with your private keys, you are the only one who can create these signatures , If your keys are ever stolen, other people can claim that they are the original owner , If you lose your private keys, you will no longer be able to create signatures, and your public key systems will not believe that you are who you say you are.

In Figure 2, you can see how the three parts interact with each other.

Enctypting Messages with the Public Key

You learned that you can use public keys to verify signatures , But that’s not the only thing you can do with public keys , The public key has the ability to encrypt a message that only the corresponding private key can open .

If you want to use asymmetric encryption for private communication , You must exchange public keys , Anyone who has your public key can send you messages that only you can read .

The figure below shows the simplified process. For performance reasons, the message in that image is usually not the actual data you want to send, but a symmetric encryption key that is exchanged with the private key holder and then used to encrypt/decrypt all current messages between the two parties.

ECDSA

The Elliptic Curve Digital Signature Algorithm (ECDSA) is a Digital Signature Algorithm (DSA) which uses keys derived from elliptic curve cryptography (ECC). It is a particularly efficient equation based on public key cryptography (PKC).

ECDSA is used across many security systems, is popular for use in secure messaging apps, and it is the basis of Bitcoin security (with Bitcoin “addresses” serving as public keys).

ECDSA is also used for Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), by encrypting connections between web browsers and a web application. The encrypted connection of an HTTPS website, illustrated by an image of a physical padlock shown in the browser, is made through signed certificates using ECDSA.

A main feature of ECDSA versus another popular algorithm, RSA, is that ECDSA provides a higher degree of security with shorter key lengths. This increases its ROI further as ECDSA uses less computer power than RSAm a less secure competing equation.

Using elliptic curve point manipulation, we can derive a value from the private key, which is not reversible. This way we can create signatures that are safe and tamperproof. The functions that derive the values are called trapdoor functions.

Signing and verifying using ECDSA

ECDSA signatures consist of two numbers (integers): r and s. CSC also uses an additional v (recovery identifier) variable. The signature can be notated as {r, s, v}.

To create a signature you need the message to sign and the private key (dₐ) to sign it with. The “simplified” signing process looks something like this:

1. Calculate a hash (e) from the message to sign.
2. Generate a secure random value for k.
3. Calculate point (x₁, y₁) on the elliptic curve by multiplying k with the G constant of the elliptic curve.
4. Calculate r = x₁ mod n. If r equals zero, go back to step 2.
5. Calculate s = k⁻¹(e + rdₐ) mod n. If s equals zero, go back to step 2.

In CSC, the hash is usually calculated with Keccak256("\x19CSC Signed Message:\n32" + Keccak256(message)). This ensures that the signature cannot be used for purposes outside of CSC.

Because we use a random value for k, the signature we get is different every time. When k is not sufficiently random, or when the value is not secret, it’s possible to calculate the private key using two different signatures (“fault attack”). However, when you sign a message in MyCrypto, the output is the same every time, so how can this be secure? These deterministic signatures use the RFC 6979 standard, which describes how you can generate a secure value for k based on the private key and message (or hash).

The {r, s, v} signature can be combined into one 65-byte-long sequence: 32 bytes for r, 32 bytes for s, and one byte for v. If we encode that as a hexadecimal string, we end up with a 130-character-long string, which is used by most wallets and interfaces. For example, a full signature in MyCrypto looks like this:

We can use this on the “Verify Message” page on MyCrypto, and it will tell us that 0x76e01859d6cf4a8637350bdb81e3cef71e29b7c2 signed this message.

You may be asking: Why include all the extra information, like address, msg, and version? Can’t you just verify the signature itself? Well, not really. That would be like signing a contract, then getting rid of any information in the contract, and keeping just the signature. Unlike transaction signatures (we’ll go more in-depth in those), a message signature is just that: a signature.

In order to verify a message, we need the original message, the address of the private key it was signed with, and the signature {r, s, v} itself. The version number is just an arbitrary version number used by MyCrypto. Really old versions of MyCrypto used to add the current date and time to the message, create a hash of that, and sign that using the steps as described above. This was later changed to match the behaviour of the JSON-RPC method personal_sign, so version “2” was introduced.

The (again “simplified”) process for recovering the public key looks like this:

• Calculate the hash (e) for the message to recover.
• Calculate point R = (x₁, y₁) on the elliptic curve, where x₁ is r for v = 27, or r + n for v = 28.
• Calculate u₁ = -zr⁻¹ mod n and u₂ = sr⁻¹ mod n.
• Calculate point Qₐ = (xₐ, yₐ) = u₁ × G + u₂ × R.

Qₐ is the point of the public key for the private key that the address was signed with. We can derive an address from this and check if that matches with the provided address. If it does the signature is valid.

The recovery identifier (“v”)

v is the last byte of the signature, and is either 27 (0x1b) or 28 (0x1c). This identifier is important because since we are working with elliptic curves, multiple points on the curve can be calculated from r and s alone. This would result in two different public keys (thus addresses) that can be recovered. The v simply indicates which one of these points to use.

In most implementations, the v is just 0 or 1 internally, but 27 was added as arbitrary number for signing Bitcoin messages and CSC adapted that as well.

Since EIP-155, we also use the chain ID to calculate the v value. This prevents replay attacks across different chains: Atransaction signed for CSC cannot be used for Ethereum Classic, and vice versa. Currently, this is only used for signing transaction however, and is not used for signing messages.

Signed transactions

So far we’ve mostly talked about signatures in the context of messages. Transactions are, just like messages, signed as well before sending them. For hardware wallets like Ledger and Trezor devices, this happens on the device itself. For private keys (or keystore files, mnemonic phrases), this is done directly on MyCrypto. This uses a method that is very similar to how messages are signed, but the transactions are encoded a bit differently.

Signed transactions are RLP encoded, and consist of all transaction parameters (nonce, gas price, gas limit, to, value, data) and the signature (v, r, s). A signed transaction looks like this:

0xf86c0a8502540be400825208944bbeeb066ed09b7aed07bf39eee0460dfa261520880de0b6b3a7640000801ca0f3ae52c1ef3300f44df0bcfd1341c232ed6134672b16e35699ae3f5fe2493379a023d23d2955a239dd6f61c4e8b2678d174356ff424eac53da53e17706c43ef871

Recommended

Cryptography

ECDSA

RSA

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing