diff <(ssh-keygen -y -f id_rsa) id_rsa.pub
Tag: rsa
How To Read RSA, X509, PKCS12 Certificates with OpenSSL?
Read RSA Private Key
RSA is popular format use to create asymmetric key pairs those named public and private key. We can use rsa verb to read RSA private key with the following command.
openssl rsa -in myprivate.pem -check
Read X509 Certificate
Another case reading certificate with OpenSSL is reading and printing X509 certificates to the terminal. We will use x509 version with the following command.
openssl x509 -in mycert.pem -text -noout
Print Certificate Purpose
X509 certificates also holds information about the purpose of the cerficate. This will be beneficial while using certificate to learn the creation aim of the certificate. We can print certificate purpose with the -purpose command like below.
openssl x509 -in mycert.pem -text -noout -purpose
Read Web Sites HTTPS TLS/SSL Certificates
We can read and print web sites HTTPS certificates with the s_client verb which is explained in this tutorial. We can print the SSL/TLS X509 certificate with the following command.
openssl s_client -showcerts -connect poftut.com:443
Read PKCS12 File
We can also read and print PKCS12 files which can be used store keys and related information. We will use pkcs12 verb like below.
openssl pkcs12 -info -in keystore.p12
Read Certificate Signing Request
Certificate signing requests are used to create required request in order to sign our certificate from certificate authority. After creating a Certificate Signing Request we should check the CSR with the following command where we can see all information provided by CSR.
openssl req -text -noout -verify -in myrequest.csr
How Bitcoin Works
As interest and coverage continues to rise on the topic of Bitcoin and cryptocurrency, there is an increasing number of investors that are completely dubious to the “under-the-hood” mechanics of the technology. While a ‘complex’ understanding is typically left for the software-engineers and experts alike, a dumb-downed version can easily explain all the intricate complexities of Bitcoins; that is, without leaving much room for questions or concerns on the legitimacy of the rising cryptocurrency market.
That is what this article will concentrate on. Explaining Bitcoin a bit further from the usual “it’s a ledger… kept by everyone!” notion.
Quick recap on Bitcoin’s origin and its price history.
Bitcoin was introduced back in 2007, when an individual or group of people by the pseudonym of Satoshi Nakamoto published a detailed white-paper, a proof-of-concept explanation, of a currency that had the potential to be both decentralized and self-governed. The paper is still officially hosted on http://bitcoin.org, and can be accessed and read by anyone with an understanding of cryptology and mathematics.
From the original white paper to 2013, the cryptocurrency gained some traction and found itself at an all-time high of $1,165 per bitcoin on November 30, 2013. Soon after, due to some controversy surrounding 850,000 coins (priced at more than $450 million) disappearing from the biggest exchange at the time, Bitcoin took a hard plummet to less than $200 per coin.
After the plummet in 2013, Bitcoin slowly began rising back to the $1,000 mark that it had crossed, and it successfully did so in January of 2017.
Following January, Bitcoin took another small dive due to news from China (one of Bitcoins main user) stating the country was closing its door on the cryptocurrency. This was eventually found to be false, and Bitcoin quickly found its way back to its usual prices and where we currently stand.
While there has been more news that has affected the price of Bitcoin post misinformed China-ban news, there has not yet been another incident as price-drastic as the two mentioned.
If you would like some more in-depth reading of the above, I recommend checking out the following resources:
Bitcoin and how it works.
The magic behind Bitcoin is not hard to explain, but for the bigger picture to be understood there ought to be an understanding of three preceding technologies that are crucial to the Bitcoin environment. Those three technologies being peer-to-peer, hashing, and signature algorithms.
Peer-to-peer (P2P)
Popularized in 1999 through Napster, peer-to-peer is a method of sharing information through a decentralized network.
When you access any website on the internet, that website is being hosted and projected by another computer within the world. This means that your computer sends a request through the World Wide Web over to another machine, and asks ‘hey, can you send me your website?’ This query is quickly realized and accepted, and a website like Google.com will send back the page requested. This is what is called the client-server model.
The client-server model is the usual method in which your computer communicates with the rest of the internet, but the issue relies on the fact that the server, which processes queries, is centralized and bound by issues such as bandwidth allocation — the server can only send the file requested at a pace noted by its upload rate, so instead of hauling the process for many, it accommodates all by decreasing the upload speed to each user. In the case of the user, the file gets downloaded at a slower pace.
In the realms of website hosting, the client-server model is not that big of an issue. A website is rather light in weight, and the client-server model is perfect at delivering sections of a website in quick pulses to requesting users. The main issue is when the file is larger in size, as that of a movie or a music file — in the case of Bitcoin, a ledger.
The whole notion of the client-server model was seen faulty for such applications, especially for Napster. First of all, someone would have to store illegal movies or music on a centralized server, and second of all, too many people accessing the server would cause major slowdowns in download speeds. The following issues had to be fixed:
- Centralization — How can we make sure we don’t store the files?
- Download-speed — How can we make sure download speed is kept at full?
And thus P2P was introduced, allowing people to download a file from all others who owned the file:
Peer-to-peer allowed anyone to download files at much faster rates, from different sources at the same time. This means that the bottom left computer on the image above, would be downloading pieces of a file from all computers it is connected to. While it’s downloading, it would also serve as a uploading hotspot for other computers lacking the pieces in which it had already downloaded. When the computer was done downloading the whole file, it became another node to download the file at full.
Peer-to-peer created a decentralized system that allowed quick downloads without much concern for the end-user or the original uploader of the file. Once the file was uploaded and downloaded, it could quickly spread as it began downloading and uploading by all individuals who now had the file on their machine.
This is the technology of peer-to-peer. This is one of the fundamental workings of Bitcoin, and we will proceed to the next important piece: hashing.
Hashing
The first designs of hash functions were introduced in the late 1970’s, and in today’s world there are few accepted hash functions that are known to be secure and viable. Hashing is the term utilized for putting any kind of information through a hash function and receiving an output that cannot be traced back to its original content.
In a normal mathematical function, a user places a value within the designated function and receives a solution in return.
Let us take y = x + 1 . Make x = 10 and we have the y value of 11 ( y = 10 + 1 = 11 ). A normal mathematical formula, though, can be easily reversed engineered to find that y — 1 = x and thus 11 — 1 = x = 10 , or the original value of x.
The issue is that if given the value of y, a user can easily reverse the value back to x. The question forms: How can we send the value of y , without it being able to be reverse engineered? This is where hash functions come into play.
Hash functions are one-way functions. This means that when an input of x is made, the returning output is one that cannot be traced back — even if the user holds the formula which led to the x value eventually becoming y. The mathematics behind hash functions will greatly differ depending on the specific hash function. All hash functions, however, have few things in common:
- Same inputs will always output the same result. This means that if you input
x = 10, the value forywill never be different if the function is run multiple times withx = 10. It will always output the same value. - Outputs are always the same size. This means that no matter if the input is 5,000 characters or 1 character, the output will always be the same length — designated by the specific hash function.
- Majority of hash functions (including the one utilized within Bitcoin) will have what is called the ‘avalanche effect’, in which any slight change to an input (for example, adding a single ‘a’ to the end of ‘hello’) changes the output completely.
Hash functions are widely used in database and password storage. When you sign-up for a website, proper websites will hash your password and store the hash result within their database. When you login at a future date, your password gets hashed and the hashed password is compared with the hash stored in the database. This prevents, in the incident that the database is hacked and leaked, that your password is found in plain text.
Here are some examples of SHA-256, a widely used cryptographic hash function that is also found in Bitcoin:
hello : 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824a :
ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bbhelloa :
9abfe77d5eb12f4a1012ac1407ce8aeb73b76803caf2092247777b1a70cc118eAs you can see, there are no recognizable patterns from hashing that allows one to distinguish the word hello, the single letter a, or the combined helloa. This is because hashing is made specifically for that; a lack of distinction. Also notice how SHA-256 produces a 256-bit (character length) output, no matter the input’s length.
The last piece of this puzzle is the signature algorithm.
Signature Algorithm (Digital Signatures)
Introduced for the purpose of verifying digital documents, a signature algorithm is utilized to verify the sender of a message. In an offline world, a person’s signature is a representation of a person’s validity and agreement. If you sign a message in the offline world and mail it to someone, that signature is typically enough to prove the sender of the document.
The issue is that within the online world, a signature can easily be copied. Signing a document with the written words “~ Felipe Faria” is not very secure. Anyone with the ability to type “~ Felipe Faria” could claim to be someone they are not (unless their name is also Felipe Faria, which also creates conflicts), and so the question arises; “how do we create a viable signature system online?”
The answer is a signature algorithm like ECDSA. ECDSA stands for Elliptic Curve Digital Signature Algorithm, and through some high-math we are able to verify the integrity of a document through the use of a public and a private key.
The way in which everything works is rather simple. When a user generates an ECDSA pair (public and private key), the user is effectively generating a key that can sign a message and another key that can verify the signature.
The private key effectively ‘signs’ the document, and the public key is utilized to verify the document. As the name suggests, a private key is kept by the user (and never shared), and the public key is given to verify the sender.
Keep in mind that a public key is exclusive to one private key. This means that when pairs are generated, the private and public keys are mathematically linked together in a way that allows a private key to output the public key, but with just the public key it is impossible to reverse back to the private key. This means I can send someone a public key that is known to be linked to me, a message in which I would like to be read, and a signed message to basically tell the user at the other end: “hey, I just send you a document. It’s me, Felipe Faria.”
So let us generate some key pairs for ourselves:
Private Key: a055b7929836f686932ee2b952da2e6a45ebe9209995ecee8fe3e00dca4823c1
Public Key: 0400818a8553c104bb80daa5efd191156fb7d0c7c07d0ce9ee5893fc86490328d8fb5ea89f7c0b54cbc496724658baee46d7ad1cd1c75205c3195384e4cef0c69d
Now these two keys are used in conjunction with each other. We can utilize the algorithm to sign a message with our private key, for example Hello , and we receive the following signed message:
Message: Hello
Signed Message: 3045022100d8c4ea6c3746a3a4426a1b6f4d0d90bb0f20fe49d5dac1c83a8afd039864a8e102202c41fb356187d0a48fd627fd7594f8d805f578fd9d23711d30236b47a9ea0f5a
The message Hello is signed with our private-key, and an output is given as the signed message (which is really a signature specific to the message, not the messaged encrypted). Now we can send another user our public key, the original message, and our signed message, and that user can utilize our public key to verify that the message was signed by us.
You can actually go to the website above (leave all configurations as they are), place the public key, the message, and the signed message, and verify the signature. You should receive a “valid ECDSA signature” dialog. Modify any section of the original Hello , public key, or signature, and you will receive an invalid dialog.
The essence of a signature algorithm is to simply verify the sender of the message by creating a signature generated by the message and a private key, that can be verified by a public key that is linked to the signing private key.
Review
- Peer-to-peer allows the downloading and uploading of files without the hassle of a main centralized server. It allows a file to be kept and downloaded from multiple machines.
- Hashing allows any input to become an irreversible output. This allows passwords, for example, to be stored in a safe manner. Hash a password and store it. When a user attempts to access your website, all one has to do is hash their password and send it to the server as proof that they are the user they claim to be.
- Signature algorithm allows a file or string to be signed by a private key and verified by a linking public key, effortlessly proving that the private key signed the original message.
Bitcoin
Now that we have peer-to-peer, hash, and digital signatures explained, a more fundamental understanding can be made about Bitcoin. For that, I’ve cut the explanation of Bitcoin into different sections:
- Network and Roles: How all computers within the Bitcoin network communicate (users, miners, nodes), and their specific jobs.
- Wallets: How a wallet works and how coins are kept safe.
- Transactions: How a transaction is created and sent into the network.
- Mid-Review: Quick review on how wallets, transactions, and nodes interact.
- Mining: What mining is and how it keeps the network alive.
We will tie everything together in the next section, the conclusion.
Network and Roles
Within the Bitcoin network, there are three important (and distinctive) entities:
- Users: Individuals who simply own and give value (through supply and demand) to Bitcoins. I will go into more depth on how Bitcoins are stored within the wallet section, and how they are spent within the transactions section.
- Miners: Individuals who purposely mine Bitcoins by utilizing massive computer power to literally ‘guess’ a hash puzzle (explained further under mining). When a hash puzzle is solved, 12.5 BTC (yes, 12.5, currently at a value of a bit over $13,500) is rewarded, and transactions are considered verified along the way.
- Nodes: Broadcasters of messages within the network. When a user creates a transaction it relays it to a node, who verifies the transaction first and then creates a list of unverified transactions in which miners can pull from. Miners, who then mine the selected transactions, send these finalized (and confirmed transactions) back to the nodes. Nodes will take this information and place all verified transaction on the public ledger. Nodes also communicate among themselves to verify they are all kept up-to-date on the information they store.
In the bigger picture, this is what’s occurring when a user sends a transaction to the network:
- User will specify another wallet to send Bitcoins to.
- The user’s transaction is broadcasted to a node, who verifies the integrity of the transaction and then places it in a list of unverified transactions (called a block) that gets broadcasted to miners.
- Miners receive a block, and through a hashing game they generate new Bitcoins and relay to nodes the completed puzzle.
- Nodes receive a message that a miner has been able to solve the hashing puzzle, they verify the integrity of the puzzle and place all unverified transactions into the verified transaction list, known as the blockchain.
Wallets
For anyone to securely own a Bitcoin, they must have a wallet. Wallets are typically third-party (open source) software that keeps track of a user’s Bitcoin. The intricacy of a wallet is formed by the last piece of technology we discussed, the signature algorithm.
When a Bitcoin wallet is created, a ECDSA pair is also generated. This ECDSA pair, as we discussed above, has a private and a public key:
Private Key: a055b7929836f686932ee2b952da2e6a45ebe9209995ecee8fe3e00dca4823c1
Public Key: 0400818a8553c104bb80daa5efd191156fb7d0c7c07d0ce9ee5893fc86490328d8fb5ea89f7c0b54cbc496724658baee46d7ad1cd1c75205c3195384e4cef0c69d
Utilizing our public key and some cryptographic math, the wallet automatically formulates our public key into a Bitcoin address:
Public Key: 0400818a8553c104bb80daa5efd191156fb7d0c7c07d0ce9ee5893fc86490328d8fb5ea89f7c0b54cbc496724658baee46d7ad1cd1c75205c3195384e4cef0c69d
Bitcoin Address: 1NSk3icpDQR1vyyk14XA8qrnn4nAThTdac
This Bitcoin address is now our identity within the network. The wallet will now contain the following information:
Private Key: a055b7929836f686932ee2b952da2e6a45ebe9209995ecee8fe3e00dca4823c1
Public Key: 0400818a8553c104bb80daa5efd191156fb7d0c7c07d0ce9ee5893fc86490328d8fb5ea89f7c0b54cbc496724658baee46d7ad1cd1c75205c3195384e4cef0c69d
Bitcoin Address: 1NSk3icpDQR1vyyk14XA8qrnn4nAThTdac
Wallets do not need to tell nodes that a new address has been created. Nodes simply assume that every possible Bitcoin address exists, and that as long as someone owns the private key to a Bitcoin address they are free to send transactions. This means that yes; you can send Bitcoins to a wallet that has never actually been generated.
The same wallet being generated twice is mathematically improbable. There can be a total of 2¹²⁸ wallets generated, that’s the following number:
340,282,366,920,938,463,463,374,607,431,768,211,456
When a transaction is created through the wallet, the wallet will sign the transaction using its private key to tell anyone who decides to look at the transaction: “Yes, I am sending this amount of Bitcoins over to address x.”
Wallets also store specific values of incoming transactions. This means that when a Bitcoin is received, said Bitcoin is stored with information regarding its past owners. This is a major point to the Bitcoin network because it allows every single Bitcoin to be traced back to its origins (expanded more on transactions).
Transactions
Now that we have a wallet with its corresponding private and public key, we can send and receive transactions. Transactions are based on two things:
- Inputs: Reference to an output from a previous transaction.
- Outputs: Contains instructions for sending bitcoins.
Transactions will look like so:
Each rectangular block is its own transaction. In each transaction, the following is held:
- The transactions content (expanded bellow; inputs and outputs).
- The signature of the creator of the transaction — the signature is based on the transaction’s content.
- The public key of the creator of the transaction to verify the signature, created based on the content.
As the diagram shows and indicates, every transaction must be met by a preceding one. The transactions content is both the inputs and outputs of the said transaction.
The input(s) is the past transaction that led the Bitcoin to the sender’s wallet, and the output(s) is the receiver of the Bitcoin, and possibly the sender in special circumstances. In the case of input(s), Bitcoins are stored in its final value, so let us say 1.0 BTC. If an owner of a wallet owns that 1.0 BTC and is attempting to send 0.2 BTC over to friend B, the outputs of said transaction would have to be the following:
- 0.8 BTC to the original sender.
- 0.2 BTC to friend B.
Effectively, this system creates a tracking system that never allows the spawn of random Bitcoins within the network. This means that all Bitcoins must be traced back to its origins (we will discuss how Bitcoins ‘spawn’ within mining).
Transactions are based on two principals: verification, and content. The verification of a transaction is done by the signing of the content utilizing a private key, and then placing the signature and the corresponding public key within the transaction. The content of a transaction is all its past transactions and the receiver of Bitcoins.
Mid Review
The contents of the last two sections can be somewhat confusing, so through this mid-review hopefully we can grasp the interaction of a wallet and a transaction if we haven’t yet.
A wallet generates an ECDSA key-paring. The public key runs through some cryptographic steps to output what effectively looks like a Bitcoin address. For simplicity’s sake, let us say this wallet contains 1.0 BTC. We will name our wallet wallet_1 and wallet_1 is going to make a transaction of 0.2 BTC to wallet_2. To do so, wallet_1 will have to create a transaction that looks like the following:
- Inputs: … (past transactions)
- Outputs: 0.8 BTC to
wallet_1, 0.2 BTC towallet_2. - Signature: Signature of the content.
- Public Key: The public key of the sender;
wallet_1.
This transaction will be sent to a node, who will verify the inputs with the ledger, the validity of the signature/public-key/content, and who will place the transaction within a block (unverified transactions) that will get sent for mining (this process will be explained under mining). Once that transaction is mined and is placed within the verified transaction list (the blockchain), wallet_1 is known within the network to have 0.8 BTC and wallet_2 is now known to have 0.2 BTC. wallet_2 will now send wallet_3 0.1 BTC:
- Inputs: 0.2 BTC from
wallet_1. - Outputs: 0.1 BTC to
wallet_2, 0.1 BTC towallet_3. - Signature: Signature of the content.
- Public Key: The public key of the sender;
wallet_2.
And this process will continue on forever. These transactions, keep in mind, are stored within the public ledger called ‘the blockchain’. This means that every coin can be traced back to its origin, and when a transaction is sent to a node for verification a node can effectively say: “Hey, your inputs are not valid!” or “Hey, your signature does not match your public key! You don’t own these Bitcoins!” (with that level of enthusiasm, I like to believe).
Mining
One of the most crucial parts to Bitcoin is mining. Miners will pull unverified transactions based on their criteria from nodes. By combining this list of unverified transaction and the last blocked that was mined, miners will hash everything together to a small 256-bit string, or set of characters.
This 256-bit string is then placed together with digital trash (random data), simply called ‘nonce’… and this is where the hashing game begins. The miner’s job is to now discover a nonce that when placed with the unverified transaction and the last block, will generate a hash with a specific amount of leading zeros.
The amount of leading zeros is what creates the ‘difficulty’ within the network, and at the time of this article this was the hash of the last block mined:
000000000000000000520aea43a637615c5ada8a2ef96a4d3a23a9bdd73c12d5
Keep in mind that due to the avalanche effect, a simple change within the nonce of the data will completely change the outputting hash. For all those leading zeros to have been found, billions of hashes with different nonces had to be tried. When the proper nonce is found, however, the network allows the miner to create one transaction at a limit of 12.5 BTC within that block; and that’s exactly what a miner will do. The miner will reward itself by creating a 12.5 BTC transaction to, well, itself.
Nodes also hold the unverified transactions, which miners will pull from. This means that miners are on a timetable. If a miner is able to successfully mine a block, that block is officially added to the blockchain (the ledger), and it can no longer be mined. This means other miners have to disregard their work, and begin mining the next block.
When the Bitcoin network was first created the reward for each block mined was at 50 BTC. Hard-coded to Bitcoin, after 210,000 blocks had been mined (approximately 4 years) the network dropped the reward to 25, and after 420,000 blocks the network dropped the reward to 12.5. This will continue on until the reward is effectively zero. This implementation was done so the Bitcoin network never surpasses 20999999.9769 BTC or the current value of $22,760,849,974.96.
Conclusion
So now that we have all the pieces to the puzzle, we can go ahead and place the puzzle completely together. Let’s quickly review all aspects explained above:
- Peer-to-peer allows the downloading and uploading of files without the hassle of a main centralized server. It allows a file to be kept and downloaded from multiple machines.
- Hashing allows any input to become an irreversible output. This allows passwords, for example, to be stored in a safe manner. Hash a password and store it. When a user attempts to access your website, all one has to do is hash their password and send it to the server as proof that they are the user they claim to be.
- Signature algorithm allows a file or string to be signed by a private key, and verified by a linking public key, effortlessly proving that the private key signed the original message.
- Network and roles include the user, nodes, and miners. Users are everyday individuals simply sending and receiving Bitcoins. Nodes relay messages around the network, verify transactions, and keep the full ledger of the Bitcoin network. Miners effectively place unverified transactions (blocks) into the blockchain by completing a hash game.
- Wallets are what a user will utilize to send and receive transactions. Wallets sign transactions before sending them to a node to be verified, which eventually is picked up by a miner to be mined, and eventually back to the nodes to be considered confirmed.
- Transactions are sent by a user’s wallet to a node. They include the input(s) of the Bitcoin being sent (previous transactions that led to this Bitcoin), and the output (receiving address(es)).
- Mining is when a miner successfully mines the block through the hash game and is reward how much ever Bitcoin the network allows at the time.
Now that we have all the information above, I can tell you what Bitcoin is in one paragraph:
Bitcoin is a peer-to-peer network, effectively making it decentralized, that utilizes nodes to keep the full ledger of the network, verify transactions, and broadcast messages. Miners generate new Bitcoins through a hashing game, and users use and give value to Bitcoins. Through the use of signature algorithm, a wallet can generate transactions that are verified by nodes, mined by miners, and stored in the ledger by nodes. Hashing allows a simple way to keep track of previous transactions, previous blocks, and creating new Bitcoins.
A Passionate Techie 