commit cb4a4f5266a1764234840e0944abc7c4fb17d356
parent f2ebf339fc735f626094407dfc56746e31315d16
Author: oscarbenedito <oscar@oscarbenedito.com>
Date: Sat, 4 Apr 2020 12:44:23 +0200
Raw HTML on Markdown now working
Diffstat:
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/config.toml b/config.toml
@@ -24,3 +24,6 @@ disableKinds = "taxonomyTerm"
[frontmatter]
date = [":filename", ":default"]
+
+[markup.goldmark.renderer]
+ unsafe = true # This just allows HTML on Markdown, unsafe here just means that if everyone could edit your Markdown, someone could put malicious JS on it.
diff --git a/content/blog/2020-01-12-securing-communications.md b/content/blog/2020-01-12-securing-communications.md
@@ -19,7 +19,7 @@ Craig's attack is known as a man-in-the-middle attack, happening when the attack
Alice knows about the flaws of the mail system, so she decides to encrypt her message. She could use the Caesar cipher. If Bob knows how much Alice "shifted" the alphabet, he will be able to read her message, while Craig won't. Or will he? Couldn't Craig just try all the numbers from 1 to 25 and just see which one gives a message that makes sense? And how did Alice tell Bob how much she "shifted" the alphabet without Craig reading it?
-Those are good points. We currently use better encryption methods than the Caesar cipher that tackle these issues. The first concern is talking about a brute-force attack (when the attacker tries many keys in order to—eventually—find the correct one). We can protect our messages against brute-force attacks by using an encryption method that admits a huge number of different possible keys. How big? If you create a key with GPG, the minimum key size is 1024 bits (which gives us 2{{< raw-html >}}<sup>1024</sup>{{< /raw-html >}} different possible keys). How hard would it be to crack it? [This video](https://www.invidio.us/watch?v=S9JGmA5_unY)[^invidious] explains it pretty well for a key that is 256 bits long (2{{< raw-html >}}<sup>256</sup>{{< /raw-html >}} possible keys). First problem solved! Bob isn't deciphering our letter anytime soon!
+Those are good points. We currently use better encryption methods than the Caesar cipher that tackle these issues. The first concern is talking about a brute-force attack (when the attacker tries many keys in order to—eventually—find the correct one). We can protect our messages against brute-force attacks by using an encryption method that admits a huge number of different possible keys. How big? If you create a key with GPG, the minimum key size is 1024 bits (which gives us 2<sup>1024</sup> different possible keys). How hard would it be to crack it? [This video](https://www.invidio.us/watch?v=S9JGmA5_unY)[^invidious] explains it pretty well for a key that is 256 bits long (2<sup>256</sup> possible keys). First problem solved! Bob isn't deciphering our letter anytime soon!
[^invidious]: The video was originally posted on YouTube, I linked to Invidious, a platform that minimizes Google's tracking while watching YouTube. The original video link is <https://www.youtube.com/watch?v=S9JGmA5_unY>.
diff --git a/content/blog/2020-03-02-types-of-networks.md b/content/blog/2020-03-02-types-of-networks.md
@@ -9,9 +9,7 @@ When we are trying to understand a communications network, having an approximate
When all the nodes on a network are connected to one unique node, we call it a centralized network. All communications happen through that one "master" node. An example of a centralized network is the one created by most instant messengers, for example [Signal](https://signal.org/). Every time we send a message, it goes to Signal's servers and it is then sent to its destination. This creates a network similar to the following, where everyone is connected to one server (or cluster of servers).
-{{< raw-html >}}
<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/centralized-network.svg#l"></use></svg></p>
-{{< /raw-html >}}
Having everything go through the same computer has its pros and cons. On the one hand, it makes deployment easier and faster, data consistency is easy to maintain and it is an efficient network (if, for instance, you need to gather data, it is all in one server). On the other hand, it creates a single point of failure for the whole network (which also facilitates censorship) and it makes it easier to abuse users (as the central server has a monopoly over the network)[^common]. This type of network also makes escalation much harder, as the resources are provided by one sole party.
@@ -21,9 +19,7 @@ Having everything go through the same computer has its pros and cons. On the one
Decentralized networks don't have one central node, but multiple of them, which are connected between themselves. When clients connect to the network, their communications go through their "master" node, to the destination's "master" node, and finally to the destination. An example of a decentralized network is [e-mail](https://en.wikipedia.org/wiki/Email). When Alice (`alice@example.com`) wants to send an e-mail to Bob (`bob@example.org`), Alice's computer sends the message to `example.com`'s server. From there, it is sent to `example.org`, and finally `example.org` sends it to Bob's computer. A decentralized network looks similar to the following network.
-{{< raw-html >}}
<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/decentralized-network.svg#l"></use></svg></p>
-{{< /raw-html >}}
Decentralized networks solve some of the centralization problems: no entity has control over the whole network anymore, allowing users to choose between different providers and switch servers (or self-host) if one starts abusing its power. If a server is down, others can still communicate ordinarily, which also makes censorship more difficult. Decentralized networks are also easier to escalate. Nonetheless, this type of network requires more infrastructure and can become less efficient for certain operations (like global tasks). It is also harder to deploy updates, as servers might update at different times, when each administrator decides to do so.
@@ -31,9 +27,7 @@ Decentralized networks solve some of the centralization problems: no entity has
Distributed networks only have one type of node, and they are connected with each other (although not necessarily all with all). This creates a very robust network where all nodes are client and server at the same time. The [BitTorrent protocol](https://en.wikipedia.org/wiki/BitTorrent) is an example of a protocol that works with a distributed network. The following image shows what a distributed network looks like.
-{{< raw-html >}}
<p style="text-align: center"><svg class="basic-svg" viewBox="0 0 633.9 523.77"><use xlink:href="/img/blog/2020/03/types-of-networks/distributed-network.svg#l"></use></svg></p>
-{{< /raw-html >}}
Because there are no central servers, distributed networks easily circumvent censorship and are practically immune to denial-of-service attacks. Since every user is client and server at the same time, these networks are highly scalable without the need for additional central resources. However, distributed networks make deployment a lot harder.
diff --git a/layouts/shortcodes/raw-html.html b/layouts/shortcodes/raw-html.html
@@ -1 +0,0 @@
-{{ .Inner -}}
