Forem: Lucas Santos

Cryptography #0 - Essential Concepts

Lucas Santos — Wed, 07 Aug 2024 18:17:23 +0000

The importance of cryptography goes beyond just understanding why it's cool, but also can be the difference between you being a good or bad dev in the long run. Any respectable system, especially those dealing with user data, will need some type of security, and often it’s in your hands as a dev.

So I decided to write this series of articles about cryptography, so you can understand a bit more about the concepts and how everything works! Let’s start with a simple article on the main terms and how they work, and then we'll increase the difficulty with more details and information, maybe even implementing some of the algorithms!

This is the first article in the series. Here we’ll just have a chat about the main concepts and ideas you need to know to follow the rest of the articles in the series! So let’s go!

❗A warning!

I am not a cryptologist, nor have I formally studied cryptography. The concepts here are purely the result of my personal research. While this article can be used for study, it should not be used as a basis for sensitive applications.

Cryptography

This is a concept I have already explained on my channel:

The idea of cryptography is basically to transmit a message from one side to the other so that only the sender and the receiver of the message know its content. To encrypt means "to write in secret" in Greek.

All cryptographic mechanisms depend on 3 parts:

The message that will be transmitted
The method we will use to encrypt the message. Or the Schema that will be applied. This is the algorithm or the step-by-step process we will use to generate the encrypted text, one of the oldest methods is the Caesar Cipher.
The key that will be used to encrypt the message

Every method needs to have a way to encrypt data and optionally a way to decrypt that data. Some methods do not have a way to decrypt, such as hashes. Reversible cryptography is when we can decrypt, irreversible is when we cannot extract the original text.

In the end, the application of the method on the message using the key gives us a cipher or ciphertext which is the encrypted text that will be transmitted.

Keys

Keys are the means we use to keep a message secure; your computer password is a key, for example. Keys can have various classifications:

Symmetric: Encrypt and decrypt at the same time
Asymmetric: Either encrypt or decrypt a message
Composite: Symmetric or Asymmetric, composed of several parts to form a whole; for example, the Enigma had several properties that formed a key
Simple: Only one key is sufficient to decrypt the message
Physical: The most common concept of a key, the physical key... Your house key is a physical key, it exists in the real world
Virtual: The opposite, a key formed of bits and does not exist physically
Mixed: A physical key that contains a virtual key (Yubikeys are an example)

The pillars of security

When we talk about security and cryptography, there are some main concepts that most algorithms need to implement:

Availability: The information must be present and available when needed (performance is important)
Integrity: The data can only be accessed by authorized users
Non-Repudiation: Ensures that someone cannot deny an action because the system itself has proof that the action was performed by a specific user (guarantee of origin)

Symmetric Cryptography

We'll talk more about this in upcoming articles, but symmetric cryptography is a type of cryptography where we have only one key that serves both to encrypt and decrypt data.

The Caesar Cipher, for example, is a symmetric cryptographic cipher because only one key is used to encrypt the message for sending and decrypt it upon receiving.

However, symmetric cryptography does not need to have only one key. The Enigma (see the video below) was a reversible machine that used a series of keys that, when composed, made it possible to decrypt the message.

Asymmetric Cryptography

Unlike symmetric cryptography, an asymmetric scheme always has more than one key, usually a key pair (RSA is the most well-known). The two keys are connected in some way, either mathematically (through Modular Exponentiation for example) or physically in the case of hardware.

Usually, one part or both parts are private; one part is made to encrypt a message that can only be decrypted by the other part, which is a way to prove that the first part (the sender) is really who they say they are (non-repudiation, the user cannot deny who they are).

Block or stream ciphers

Cryptographic algorithms can encrypt data by block or in a data stream:

Block Ciphers: Encrypt data block by block, that is, take an entire block of information and encrypt it all at once. Usually, block sizes are fixed (64~1024 bits); often these sizes are pre-determined and the output always has the same size (like hashes)
Stream Ciphers: Instead of taking an entire block of information, encrypt the data bit by bit; the advantage is that you don't need as much processing power and it's relatively fast, but they require a bit more setup, like having an Initialization Vector.

Hash functions

Irreversible cryptographic functions that receive input data and generate a fixed-size output block, widely used to ensure integrity. Hashes have 3 very important properties:

Entropy: any small change in the input generates a completely different result
Predictability: The same input always generates the same output
Non-collision: two hashes generated for different values cannot have the same output (see the example with SHA1)

XOR Encryption

XOR encryption is a way to apply a key to a cipher. Stream algorithms often use this type of application to encrypt the message.

The idea is to apply the XOR operation (e*Xclusive **OR*) bit by bit on the message using the key. XOR returns 1 only if both bits are different, for example:


A	B	A XOR B
0	0	0
0	1	1
1	0	1
1	1	0

All digital text is a sequence of 0 or 1 bits; when we generate a key, it is also a sequence of 0 or 1 bits. If we use key XOR text, we will get an encrypted text, and if we apply the operation again on the encrypted text with the same key, the text returns to normal.

Ephemeral Keys

A type of key that is generated only to execute a particular step of an algorithm, or as part of encrypting another key through Key Wrapping (when we encrypt a key with another key).

These keys are used once and discarded, and they have no connection to the original data, hence ephemeral.

Rainbow Table

When talking about hashes, each hash can only have a unique output for each input. One way to attack and discover hashes is by computing ALL hashes for ALL possible letter combinations. These computation tables are known as Rainbow Tables.

Hackers often use encrypted database passwords to check if the original values are in the table; for example, 123456 encrypted with the MD5 hash is f447b20a7fcbf53a5d5be013ea0b15af. If a database with passwords leaks, any f447b20a7fcbf53a5d5be013ea0b15af that appears can be compared in a rainbow table to obtain the result 123456.

Salt

A salt is a random sequence of bytes (usually 16 or more) that is added to the end of a text

to be encrypted as a hash to increase entropy and reduce the chance of attacks by Rainbow Tables since 123456 is different from 123456A96!@#$F@f.

Salts are included at the end of user passwords when creating an account and saved in the database alongside the hashed password. When we compare if the password is the same, we just add the password to the salt to check if it produces the same saved hash.

Other acronyms

Integrated Encryption Schemes (IES): Encryption models that apply both symmetric and asymmetric encryption to create a secure communication method. HTTPS is based on such a model.
Elliptic Curve Cryptography (ECC): Instead of using very large prime numbers, this model uses an elliptic curve function to create a number that can be used as a key.
Key Wrapping (Key Encapsulation Mechanism [KEM]): Encapsulating a key with another key, essentially encrypting one key with another.
Message Authentication Code (MAC): Used with an algorithm and a password to produce an authentication value that can be validated by the receiver to ensure the message has not been altered.
Hash MAC (HMAC): The same as MAC, but applied to hashes.
Public-key encryption (PKE): Another name for asymmetric encryption.
Key-Derivation Functions (KDFs): Functions that can derive a key to another key, which can be chained.
RSA: Asymmetric encryption algorithm that generates key pairs.
AES: Symmetric encryption algorithm (also known as Rijndael).
MD5, SHA, Argon2, PBKDF2, Blake2: Hashing algorithms.

Conclusion

A lot of content and a lot to see, right? You don't need to memorize all these names; save this page in your favorites and refer to it whenever you want! I hope you enjoyed the journey so far! Stay with me because there's much more to come!

Share with your friends if you liked it and follow me on my social media; if you have any questions, just send me a message there!

Filtrando classes e métodos de um tipo no TypeScript

Lucas Santos — Wed, 03 Apr 2024 11:00:57 +0000

Nesse post bem curtinho eu quero apresentar um problema que sempre temos quando estamos lidando com TypeScript: como a gente pode listar todas as propriedades de uma classe?

Vamos supor que você queira fazer uma função de filtro, e essa função receba uma classe e permita que você filtre por todas as propriedades dessa classe, naturalmente um tipo que pode resolver o problema é esse aqui:

function filterBy<T, V extends keyof T>(origin: T, key: V, value: T[V]) {
  //
}

Mas quando chamamos essa função vamos ter um problema:

Veja que esse tipo nos dá todas as opções possíveis, porque estamos pegando todas as chaves de Foo, inclusive os métodos.

Se quisermos que apenas as propriedades, ou seja, prop, getter e setter sejam retornadas, podemos criar um tipo mapeado (mapped type), vamos chamar de OnlyProps:

type OnlyProps<ClassType> = Pick<ClassType, {
    [Key in keyof ClassType]: ClassType[Key] extends Function 
                              ? never 
                              : Key
}[keyof ClassType]>;

Vamos quebrar esse tipo, de dentro para fora:

{
    [Key in keyof ClassType]: ClassType[Key] extends Function 
                              ? never 
                              : Key
}

Aqui estamos criando um objeto mapeado onde:

Key são todas as chaves de ClassType, que é nossa classe original, isso significa que vamos retornar um outro objeto (isso vai ser importante depois)
Para cada chave Key, verificamos se aquela propriedade ClassType[Key] é uma função, se for, retornamos never, ou seja, ignoramos.
1. Se não, retornamos o nome da chave.

No final, esse mapped type deveria criar um tipo desse formato se usássemos com Foo:

{
  prop: 'prop',
  method: never,
  readonly getter: 'getter',
  setter: 'setter'
}

Vamos chamar esse tipo de ObjetoMapa, só para a gente ter uma referência nos próximos passos.

Vem aprender comigo!

Se inscreva na Formação TypeScript

Agora, pegamos o objeto mapa (que é um objeto, lembre-se disso), e transformamos em uma união de chaves:

type ObjetoMapa = {
  prop: 'prop',
  method: never,
  readonly getter: 'getter',
  setter: 'setter'
}

type UnionMapa<T> = ObjetoMapa[keyof T] // "prop" | "getter" | "setter"

Essencialmente, o que esse passo faz é transformar tudo em uma union para que o Pick possa trabalhar, e veja que estamos removendo tudo que é never, esse é o segredo.

Agora simplesmente estamos fazendo:

type OnlyProps<T> = Pick<T, "prop" | "getter" | "setter">

Que vai pegar somente essas chaves do objeto. No final podemos modificar a nossa função para usar esse tipo:

function filterBy<T, V extends keyof OnlyProps<T>>(origin: T, key: V, value: T[V]) {
  //
}

Percebeu o keyof OnlyProps<T>? Porque queremos a união das chaves novamente, essencialmente poderíamos ter feito o seguinte que é até mais simples:

type OnlyProps<T> = {
  [K in keyof T]: T[K] extends Function ? never : K
}[keyof T];

function filterBy<T, V extends OnlyProps<T>>(origin: T, key: V, value: T[V]) {
  //
}

Removemos o Pick da equação, porém usar o Pick deixa o tipo mais versátil porque podemos utilizá-lo como objeto também.

Deno KV no NPM - o DB que você precisava e não sabia

Lucas Santos — Wed, 27 Mar 2024 11:00:15 +0000

A gente já trocou uma ideia sobre o Deno KV aqui no passado, mas a grande diferença é que esse banco de dados só funcionava no Deno, até agora!

A galera acabou de anunciar o pacote do Deno KV para o NPM! Permitindo que qualquer usuário do Node já possa utilizar o banco também, mesmo isso já sendo possível com o binário do KV sendo publicado de forma standalone.

O que é o KV

Como já falamos aqui antes, eu não vou me estender muito na explicação.

O Deno KV é um banco de dados no modelo key-value (por isso KV), ou seja, ele armazena chaves em strings e valores que podem variar em formatos, mas é possível armazenar arrays, objetos, além de outros primitivos.

A grande vantagem do Deno KV é que ele é totalmente incluso no Deno, então você pode criar e acessar um banco direto com :

const kv = await Deno.openKv()

E mesmo se você não tiver uma URL, se o projeto estiver no Deno Deploy, então ele já vai conseguir resolver o banco de dados e vai te dar um banco completo com replicação automática.

O problema é quando você não está no Deno.

Usando o KV no Node.js

Para usar o KV no Node, podemos fazer a forma mais simples primeiro, usando o banco em memória! É só a gente instalar o pacote usando:

npm install @deno/kv

E depois criar um arquivo JS ou TS com o seguinte conteúdo:

import { openKv } from '@deno/kv'

const kv = await openKv('')
await kv.set(['key'], 'value')
console.log(await kv.get(['key']))
/**
 * { key: ['key'],
    value: 'value',
    versionstamp: '00000000000000010000' }
 */

Rodar o KV em memória é uma das coisas legais que podemos fazer com o pacote do Node.js, inclusive é uma funcionalidade que você pode utilizar ao invés de mapas e outras coisas para poder, por exemplo, criar testes automatizados, ou até mesmos caches locais.

SQLite

Por padrão, quando estamos executando localmente, o KV vai criar uma instancia local de um SQLite, o que é muito legal para projetos onde a persistência é necessária (já que podemos também usar o KV para dados efêmeros, como caches, nonces e etc).

Para criar um banco de dados usando SQLite é só passar o nome do banco no primeiro parâmetro:

import { openKv } from '@deno/kv'

const kv = await openKv('sqlite.db')
await kv.set(['key'], 'value')
console.log(await kv.get(['key']))
/**
 * { key: ['key'],
    value: 'value',
    versionstamp: '00000000000000010000' }
 */

A única diferença é que o KV vai criar um banco local em um arquivo:

Você pode também fazer self hosting usando este projeto para criar um banco na sua própria infraestrutura usando a mesma API e o backend do Deno KV, porém com SQLite.

Vem aprender comigo!

Se inscreva na Formação TypeScript

Conectando a uma instância online

Você também pode passar uma conexão para o banco de dados hospedado na web. Primeiro de tudo você precisa de um token de acesso.

E depois criar um banco de dados em um projeto, existem duas formas de fazer isso, a primeira é como a documentação mostra, através de um playground.

Para isso você pode fazer um projeto em branco no Deno Deploy

A segunda é criando um projeto comum indo na aba projetos do deno deploy:

Depois crie um projeto em branco:

Vá na barra de endereços e adicione /kv na URL, você vai cair nessa página:

Basta copiar a linha de comando aqui e colar na sua aplicação, seguido do token de acesso!

import { openKv } from '@deno/kv'

const kv = await openKv("https://api.deno.com/databases/UUIDAQUI/connect", {accessToken: 'SEUTOKEN'});
await kv.set(['key'], 'value')
console.log(await kv.get(['key']))
/**
 * { key: ['key'],
    value: 'value',
    versionstamp: '00000000000000010000' }
 */

É mais seguro setar uma variável de ambiente chamada DENO_KV_ACCESS_TOKEN com seu token para evitar vazamentos de dados.

Já conhece os acessores automáticos no TypeScript?

Lucas Santos — Wed, 20 Mar 2024 11:00:23 +0000

O TypeScript tem várias funcionalidades super interessantes que poucas pessoas conhecem, uma dessas funcionalidades é o uso de auto-accessors em classes.

Presente desde o TypeScript 4.9, ela também é uma funcionalidade que está descrita na proposta original de decorators (que inclusive a gente já falou sobre aqui).

Vem aprender comigo!

Se inscreva na Formação TS!

Essencialmente, essa sintaxe funciona da seguinte maneira, quando temos um acessor, geralmente temos um método get que traz uma variável interna de uma classe, por exemplo:

class Pessoa {
    #__nome: string;

    get name() {
        return this.#__nome;
    }
    set name(val: string) {
        this.#__nome = val;
    }

    constructor(nome: string) {
        this.nome = nome;
    }
}

Percebe que a gente tem não uma, mas 7 linhas só para poder criar um acessor que vai setar e obter a variável interna #__nome? Seria muito melhor se a gente pudesse fazer tudo isso de uma vez, e é pra isso que os auto-accessors existem. Tudo isso que eu escrevi pode virar isso aqui:

class Person {
    accessor nome: string;

    constructor(nome: string) {
        this.name = nome;
    }
}

Por baixo dos panos, o que os acessores automáticos vão fazer é exatamente o que fizemos no primeiro código, eles vão expandir o nome para uma variável privada interna da classe, e uma variável externa acessível somente por um getter e um setter.

No geral, essa feature não é algo muito relacionado à lógica, mas sim a qualidade de vida, especialmente quando vamos criar decorators que precisam de vários getters e setters.

Parallel Assignments - A feature que você não sabia que existia no JavaScript

Lucas Santos — Wed, 13 Mar 2024 11:00:54 +0000

Hoje pra mais um artigo curtinho aqui, vou te mostrar uma funcionalidade que você provavelmente não sabia que existia no JavaScript. Os parallel assignments.

Muitas linguagens tem o conceito de parallel assignments implementado, mas o que é isso?

Um parallel assignment, ou "associação em paralelo", é uma funcionalidade que permite que você troque o valor de duas variáveis ao mesmo tempo, mesmo se elas se referenciarem. No JavaScript isso é parte da sintaxe do destructuring então podemos associar mais de duas variáveis ao mesmo tempo.

Por exemplo, vamos imaginar essa função de fibonacci, que é uma função onde o próximo item da lista é a soma dos dois itens anteriores:

function fibonacci(terms: number) {  
  let a = 0;
  let b = 1;
  for (let i = 0; i <= terms; i++) {    
    const temp = a + b;   
    a = b;  
    b = temp; 
  }  
  return a;
}

Se você observar bem, dentro do nosso laço for a gente tem uma variável temporária, que só serve para armazenar o valor de a+b e, depois, a variável a assume o valor de b e b se torna a soma das duas.

Mas e se eu te disser que é possível fazer esse for inteiro em uma linha só?

A gente pode usar a sintaxe [a, b] = [v1, v2] onde a e b são as variáveis que queremos trocar, e v1 e v2 são os valores que queremos dar para elas respectivamente. Isso é possível mesmo se as variáveis sejam referências a si mesmas , como é o nosso caso onde b vai ser a+b.

Então podemos reescrever a nossa função para isso aqui:

function fibonacci (terms: number) {
    let a = 0;
    let b = 1;
    for (let i = 0; i <= terms; i++) {
      [a, b] = [b, a + b];
    }
    return a;
}

O destructuring é muito utilizado quando estamos fazendo a criação de variáveis a partir de arrays ou objetos, como em:

const [a, b] = [0, 1]
const { nome, idade } = { nome: 'lucas', idade: 28, sexo: 'M' }

Mas essa sintaxe também pode ser aplicada para quando estamos associando variáveis a seus valores. Inclusive podemos reduzir ainda mais fazendo:

function fibonacci (terms: number) {
    let [a, b] = [0, 1];
    for (let i = 0; i <= terms; i++) {
      [a, b] = [b, a + b];
    }
    return a;
}

E até transformar essa função em um generator:

function* fibonacciGenerator () {
    let [a, b] = [0, 1]
    while (true) {
        yield a;
        [a, b] = [b, a + b]
    }
}

const fGen = fibonacciGenerator()
fGen.next() // 0

for (let i = 0; i < 10; i++) {
  console.log(fGen.next()) // 0 1 1 2 3 5 8 ...
}

Criptografia #1 - Criptografia Assimétrica com RSA

Lucas Santos — Wed, 06 Mar 2024 11:00:32 +0000

Se você estiver com problemas para visualizar a matemática, sugiro que você vá até o blog para ver o artigo completo

No primeiro artigo dessa série a gente falou de alguns conceitos básicos sobre criptografia, sabendo desses conceitos, agora vamos entrar em um dos temas mais comuns para devs no geral. A Criptografia Assimétrica.

Então aqui eu vou tentar entrar fundo no tema, e a gente vai construir a nossas próprias chaves e implementar o algoritmo de novo! Esse vai ser um artigo longo, mas profundo.

Você pode ouvir falar de Asymmetric-Key/Public-key Cryptosystems que é o guarda-chuva sob o qual existem vários algoritmos como RSA, Diffie-Helman, ElGamal e etc. Esses sistemas tem vários tipos de serviços, mas todos usando sistemas de chaves públicas:

Geração de pares de chaves
Encriptação/Decriptação de dados
Assinatura Digial
Mecanismos de trocas de chaves

Então hoje vamos falar sobre o que são esses sistemas, mas principalmente de um algoritmo específico, o RSA.

Chaves Assimétricas

Criptografia Assimétrica é um dos modelos mais comuns de criptografia que existem em tecnologia, por exemplo, para abrir essa blog você usou HTTPS, que é um protocolo HTTP em cima de outro protocolo de segurança chamado TLS (Transport Layer **S*ecurity), este protocolo utiliza criptografia assimétrica.

Vamos falar de criptografia simétrica na próxima parte da série

Como o nome já diz, é um modelo de criptografia que não é idêntico dos dois lados, onde os dois lados são o emissor e o receptor. Quando estamos falando de criptografia simétrica, por exemplo, ambos o receptor e o emissor da mensagem possuem a mesma chave. Isso não é verdade em criptografia assimétrica.

Nesse sistema criptográfico, sempre vamos ter um componente que só é conhecido pelo dono da chave, esse componente é chamada de valor privado e é o valor utilizado para se compor uma chave privada. Outro componente presente é o componente misto , que é conhecido tanto pelo emissor (o dono da chave) quanto pelo receptor da mensagem, o componente misto é o que vai ser utilizado para fazer a derivação da chave pública a partir da chave privada.

Opcionalmente esses sistemas também podem possuir um valor público que é utilizado para gerar as chaves públicas , privadas, ou ambas (Diffie-Helman, por exemplo, tem um valor público usado para gerar a chave privada).

A saída de um sistema de criptografia assimétrica é um par de chaves , essa palavra soa familiar? Pois é, isso é porque muita coisa que a gente usa tanto na Internet, ou até mesmo fora dela, usa um par de chaves. Por exemplo, suas mensagens no WhatsApp tem a famosa "criptografia ponta a ponta", pois bem, essa criptografia é provavelmente assimétrica, e você é o dono da chave privada.

Mas o que são essas chaves afinal?

Chaves públicas

São as partes públicas da criptografia assimétrica. A chave pública é quem criptografa as mensagens que só podem ser descriptografadas pela sua contraparte privada. Você vai ver ela sendo chamada de Pk para Public Key.

Chaves públicas são derivadas das chaves privadas a partir de uma propriedade matemática chamada inversão, portanto as chaves não são iguais (nem entre si) mas conseguem produzir valores que podem ser descriptografados pela chave privada, no entanto, chaves públicas não podem descriptografar dados criptografados por outras chaves públicas, porque elas não são derivadas dessas chaves e sim da chave privada.

Calcular a chave privada a partir da chave pública é computacionalmente inviável por definição.

Então, resumindo, a chave pública é conhecida por todo mundo e é utilizada para criptografar mensagens. Se você quer mandar uma mensagem para mim, você criptografa a sua mensagem usando a minha chave pública.

Chaves privadas

A chave privada (comumente chamada de Sk para Secret Key) é uma chave gerada a partir de pelo menos dois componentes privados (no caso do RSA, números primos bem grandes) que só são conhecidos pela pessoa que é dona da chave. Essa premissa garante que:

A chave pertence a uma pessoa, portanto a origem do dado é validada
Ninguém mais tem acesso à essa chave, portanto é possível utilizá-la como mecanismo de assinatura (que vamos cobrir em outro artigo)

Nessa sessão vamos falar da chave privada como algo geral, mais abaixo vamos falar dela no contexto do algoritmo RSA

Lembre-se: criptografia assimétrica é um sistema criptográfico (cryptosystem) que é implementado por vários algoritmos. Um deles é o RSA, mas ele não é o único, portanto existem várias implementações de chaves privadas diferentes, mas todas vão ter as mesmas propriedades.

As chaves privadas são utilizadas para decriptar dados criptografados pela chave pública, ou então assinar dados que possam ser validados pela chave pública. Não é aconselhável encriptar dados usando a chave privada porque qualquer chave pública pode decriptar esses dados, por isso que essas chaves são chamadas de assinantes (vamos entender o conceito de assinatura nos demais artigos).

Resumindo, a chave privada é o oposto da pública, ela vai decriptar os dados, então aquela mensagem que você me mandou que foi criptografada com a minha Pk, vai ser descriptografada usando a minha Sk.

A chave privada deve ser conhecida somente pelo seu dono , por isso que ela é privada. E, a partir dela, é possível derivar várias chaves públicas, mas como isso é possível?

O que é criptografar?

Quando falamos de criptografia digital, não estamos mais falando de texto, estamos falando de números. Então "criptografar" algo com uma chave pública, "descriptografar" algo com a chave privada são apenas operações matemáticas que fazemos com uma chave.

Como ainda não discutimos o que são as chaves, eu vou deixar a explicação mais profunda pra nossa sessão de RSA, mas essa é a ideia, pegar um número, elevar ele a outro número e dividir por ainda mais um número, o resto da divisão é a mensagem criptografada (continue lendo para saber o que são esses números).

Derivação e inversão

Quando dizemos que uma chave pública pode ser derivada de uma chave privada (já vamos ver como fazer isso), estamos dizendo que tanto a chave pública quanto a Sk estão matematicamente conectadas.

A chave pública é o inverso da chave privada (e, portanto, a privada também é o inverso da pública), e isso significa que algo que é criptografado com uma chave pública pode ser descriptografado pela chave privada.

Assim como tudo que é criptografado pela chave privada, pode ser descriptografado por q uaisquer chaves públicas. Mas algo que é criptografado por uma chave pública não pode ser descriptografado por outra chave pública e isso que torna a criptografia assimétrica tão poderosa.

No caso de RSA, estamos falando de chaves que estão conectadas a partir de exponenciação modular, e é exatamente esse critério que torna a criptografia assimétrica algo interessante.

Exponenciação modular

Não vou me estender nesse tópico porque não é o nosso tema (inclusive esse parágrafo é mais uma curiosidade do que obrigatório), mas a exponenciação modular é uma operação de potenciação (exponenciação) sobre um módulo (sim, o resto da divisão de um número por outro como em a % b, chamado de aritmética modular, um outro tema pra outra hora).

Exponenciação modular é quando pegamos o resto de algum número b (uma base), elevado a um número x (expoente) e dividido por um inteiro positivo m (o módulo) e isso tudo é representado assim:

C=bxmod  mC = b^x\mod{m}C=bxmodm

E C é um número que vai ficar sempre entre 0 e m. Por exemplo, se a base for 5, o expoente for 2 e o módulo for 3:

b^x\mod{m} \newline C = 5^2\mod{3} \newline C = 25\mod{3} \newline C = 1C=bxmodmC=52mod3C=25mod3C=1

O resultado C é 1 porque 25/3 é 8 com resto de 1. E a grande vantagem desse sistema todo é que exponenciação modular é muito eficiente para computar, até mesmo para números muito grandes, porém computar o inverso dessa operação (o logarítmo discreto), ou seja, qual é o x quando você tem b, C e m é uma operação difícil, ainda mais se você utilizar números primos.

Usando essa matemática, é possível criar um valor que, como um relógio, vai realizar um wrap around, ou seja, quando ele chegar em um determinado número, ele volta a ser 0 (assim como a % b em programação vai estar sempre entre 0 e b-1)

Asymmetric Encryption Schemes

Criptografia assimétrica é muito mais complexa e pode chegar a ser até 1000x mais lenta do que algoritmos simétricos (como o AES), por isso algoritmos assimétricos (como o RSA) não são utilizados constantemente, mas sim em conjunto com criptografia simétrica. A junção desses dois sistemas forma diversas técnicas que são chamadas de esquemas de encriptação assimétrico.

Como esses sistemas conseguem ser utilizados ao mesmo tempo? Um dos esquemas de encriptação é chamado de KEM (Key Encapsulation Mechanism) que basicamente consiste em criptografar uma chave com outra chave:

Criptografia simétrica e assimétrica em conjunto

Aqui a gente está usando uma chave simétrica (muito mais leve) para criptografar um documento e gerar um DEM Block. Depois estamos criptografando a chave simétrica que usamos com uma chave pública de um usuário, criando o que é chamado de KEM Block , até agora é só uma chave criptografando outra chave.

Depois juntamos os dois e mandamos para o nosso recipiente, dessa forma mesmo se o documento for interceptado, a chave não pode ser recuperada porque ela foi encriptada com a chave pública. O usuário que recebe o arquivo pode decriptar da seguinte forma:

Decriptando um DEM Block

Pegamos o DEM block, separamos em chave e arquivo, decriptamos a chave simétrica usando a chave privada, obtendo a chave simétrica original, que podemos usar para decriptar o arquivo encriptado.

O protocolo HTTPS funciona "mais ou menos" assim.

RSA

Depois de entender muito sobre criptografia assimétrica, vamos finalmente falar de RSA!

RSA significa Rivest-Shamir-Adleman , e é um algoritmo de criptografia utilizado para criptografar informações, um dos mais antigos ainda em uso. Criado por Ron Rivest, Adi Shamir e Leonard Adleman em 1977. Como falamos antes, o RSA é um algoritmo relativamente lento, por isso não é utilizado para criptografar grandes volumes de dados, mas sim chaves simétricas.

O RSA gera pares de chaves com tamanhos entre 1024 e 65536 bits que podem encriptar uma mensagem (que é um número inteiro entre 0 e o tamanho da chave), bem como descriptografar usando a chave privada, gerar assinaturas e trocar chaves, embora não seja o principal para este último.

Pontos chave:

Uma chave boa geralmente está entre 1024 e 4096 bits
Quando maior a chave (mais bits) mais tempo de computação vai ser necessário
Chaves muito grandes (como 65536 bits) são muito seguras , porém muito lentas para uso prático, já que elas podem levar horas para serem geradas
Qualquer chave acima de 3072 bits é considerada segura

Lembre-se que, quando falamos de chaves aqui, estamos falando de números, nada mais. É como se fosse uma senha, só que ela tivesse 1234 dígitos (2^4096). Quando estamos "criptografando" algo, estamos aplicando uma operação de exponenciação entre a chave e o valor que queremos criptografar.

Um número de 4096 bytes

As chaves públicas e privadas do RSA derivam de dois números primos que chamamos de p e q, esses números são os componentes privados do RSA. Desses dois números é que vem a segurança.

Quando estamos utilizando RSA, vamos calcular um número n, que é chamado de módulo (tem muitos módulos, então não confunda esse com a operação modulus que a gente falou ali em cima). A questão é que é relativamente fácil encontrar primos, mas é extremamente difícil fatorar um número em seus componentes.

Um exemplo simples, quais são e quantas vezes temos que multiplicar dois números primos x e y para chegar no número 216? A fatorização desse número pequeno leva 7 passos:

2\times108\newline 108 = 2\times54\newline 216 = 2\times2\times54\newline 54 = 2\times27 \therefore 216 = 2\times2\times2\times27\newline 216=2\times2\times2\times3\times9\newline 216= 2\times2\times2\times3\times3\times3\newline 216=2^3\times3^3216=2×108108=2×54216=2×2×5454=2×27∴216=2×2×2×27216=2×2×2×3×9216=2×2×2×3×3×3216=23×33

E esse é um número simples, de 9 bits (100000000) e leva todo esse tempo. Agora imagina para um número composto de dois primos muito grandes com mais de 3000 bits.

É por isso que muita gente está preocupada com a capacidade de computadores quânticos de quebrar o RSA, porque teoricamente eles poderiam fatorar números de forma muito mais rápida

Chaves em RSA

As chaves em RSA são calculadas com alguns componentes, já falamos de três deles até aqui mas vou reiterar só para podermos nos lembrar, e agora eu vou deixar vários termos que não são triviais aqui também:

p e q são os componentes privados , eles devem ser dois números primos muito grandes, quanto maiores e mais distantes um do outro melhor.
n é o módulo , ele é a multiplicação de p por q: n = p*q. Esse número é público.
e que é o expoente público que é menor e coprimo do totiente de n e é maior que 2. Esse número é, geralmente, 65537 porque é um número de fácil representação hexadecimal (0x010001).
d é chamado de expoente privado e é composto pelo multiplicador modular inverso entre e e o totiente de Carmichael.

Essa lista não foi fácil de ler 🤣. Mas vamos quebrar esses passos gerando nossas próprias chaves manualmente. Mas, antes, vamos explicar um conceito que começamos lá atrás.

O que é criptografar? (em RSA)

A gente sabe que criptografar é uma operação matemática, mas como ela se parece?

Bem, uma chave pública não é só um número, ela é composta de dois números, então você geralmente vai ver uma chave dessa forma:

Pk = {n, e}
Sk = {n, d}

Isso significa que a chave pública é composta do nosso módulo n e do expoente público e. Um exemplo de uma chave pode ser esse (retirado desse livro incrível):

n = 0xa709e2f84ac0e21eb0caa018cf7f697f774e96f8115fc2359e9cf60b1dd8d4048d974cdf8422bef6be3c162b04b916f7ea2133f0e3e4e0eee164859bd9c1e0ef0357c142f4f633b4add4aab86c8f8895cd33fbf4e024d9a3ad6be6267570b4a72d2c34354e0139e74ada665a16a2611490debb8e131a6cffc7ef25e74240803dd71a4fcd953c988111b0aa9bbc4c57024fc5e8c4462ad9049c7f1abed859c63455fa6d58b5cc34a3d3206ff74b9e96c336dbacf0cdd18ed0c66796ce00ab07f36b24cbe3342523fd8215a8e77f89e86a08db911f237459388dee642dae7cb2644a03e71ed5c6fa5077cf4090fafa556048b536b879a88f628698f0c7b420c4b7
e = 0x010001

Enquanto a chave privada é composta do nosso módulo e do expoente privado d:

n = 0xa709e2f84ac0e21eb0caa018cf7f697f774e96f8115fc2359e9cf60b1dd8d4048d974cdf8422bef6be3c162b04b916f7ea2133f0e3e4e0eee164859bd9c1e0ef0357c142f4f633b4add4aab86c8f8895cd33fbf4e024d9a3ad6be6267570b4a72d2c34354e0139e74ada665a16a2611490debb8e131a6cffc7ef25e74240803dd71a4fcd953c988111b0aa9bbc4c57024fc5e8c4462ad9049c7f1abed859c63455fa6d58b5cc34a3d3206ff74b9e96c336dbacf0cdd18ed0c66796ce00ab07f36b24cbe3342523fd8215a8e77f89e86a08db911f237459388dee642dae7cb2644a03e71ed5c6fa5077cf4090fafa556048b536b879a88f628698f0c7b420c4b7
d = 0x10f22727e552e2c86ba06d7ed6de28326eef76d0128327cd64c5566368fdc1a9f740ad8dd221419a5550fc8c14b33fa9f058b9fa4044775aaf5c66a999a7da4d4fdb8141c25ee5294ea6a54331d045f25c9a5f7f47960acbae20fa27ab5669c80eaf235a1d0b1c22b8d750a191c0f0c9b3561aaa4934847101343920d84f24334d3af05fede0e355911c7db8b8de3bf435907c855c3d7eeede4f148df830b43dd360b43692239ac10e566f138fb4b30fb1af0603cfcf0cd8adf4349a0d0b93bf89804e7c2e24ca7615e51af66dccfdb71a1204e2107abbee4259f2cac917fafe3b029baf13c4dde7923c47ee3fec248390203a384b9eb773c154540c5196bce1

Então, "criptografar" uma mensagem nada mais é do que aplicar a seguinte formula:

encriptada=planoemod  nencriptada = plano^e \mod nencriptada=planoemodn

Ou seja, vamos imaginar que nossa mensagem é 42:

Elevamos 42 a e, vamos supor que e é 7
42 elevado a 7 é 230 539 333 248
Agora dividimos por n, digamos que n é 3977
O resultado é 57 968 150,1755091778, mas não queremos o resultado, queremos o resto! que é 698, essa é nossa mensagem criptografada

Você me manda essa mensagem, eu recebo 698, agora preciso decriptar a mensagem, para isso posso fazer a mesma operação, só que com meus valores, ao invés de e eu uso d:

plano=encriptadadmod  nplano = encriptada^d \mod nplano=encriptadadmodn

Elevo 698 a d, digamos que d seja 343
Isso vai me dar um número com 976 dígitos
Que eu agora vou dividir por 3977 e pegar o resto
Que vai nos dar a mensagem 42 de volta

A escolha desses números não foi arbitrária, existem algumas regras que precisam ser seguidas e um pouco de computação não muito trivial, mas como eu prometi, vamos explorar isso no próximo capítulo.

Criando chaves

Para gerar um par de chaves real, vamos utilizar TypeScript para poder fazer as operações matemáticas.

Definindo primos

Inicialmente vamos precisar definir alguns números, primeiro vamos começar com os nossos dois primos. Eles são os mais simples. A única regra é que eles precisam ser grandes e separados, mas, para facilitar nossas contas eu vou usar números primos pequenos, de 12 bits.

Isso significa que podemos criptografar mensagens de até 12 bits, ou seja, números até 4096.

Pegamos p como 41
Pegamos q como 97

O próximo passo é definir o módulo, que é a múltiplicação de q e p, logo:

n é p*q que é 41*97=3977, agora temos o primeiro valor que você viu no passo 3 lá em cima (tente fatorar 3977 para chegar nos primos dele, quantos passos levou?)

Lembrando que p e q são privados, não podem ser divulgados, enquanto n é público.

Até agora temos isso:

const p = 41
const q = 97
const n = p*q

Definindo expoentes

A definição dos expoentes é mais chata. Vamos precisar de um passo intermediário: definir o totiente de n.

Isso que pode ser feito através da função de Carmichael (expressado pela letra Lambda λ(n)) ou pelo totiente de Euler (expressado pela letra Phi φ(n)) que é consideravelmente mais simples, porém produz e e d maiores, então os cálculos são mais complicados.

Eu não sou matemático, então não vou complicar as coisas aqui, para resolvermos λ(n) precisamos achar o menor multiplicador comum entre p-1 e q-1, isso pode ser feito pelo algoritmo euclidiano:

λ(n)=∣(p−1)(q−1)∣mdc((p−1),(q−1))λ(n)=∣(p−1)(q−1)∣mdc((p−1),(q−1))λ(n)=mdc((p−1),(q−1))∣(p−1)(q−1)∣​λ(n)=∣(p−1)(q−1)∣mdc((p−1),(q−1))\lambda({n}) = \frac{|(p-1)(q-1)|}{mdc((p-1),(q-1))}λ(n)=mdc((p−1),(q−1))∣(p−1)(q−1)∣​

Onde o mdc é o maior divisor comum entre p-1 e q-1, então nossa conta fica:

λ(3977)=∣40×96∣mdc(40,96)λ(3977)=∣40×96∣mdc(40,96)λ(3977)=mdc(40,96)∣40×96∣​λ(3977)=∣40×96∣mdc(40,96)\lambda({3977}) = \frac{|40\times96|}{mdc(40,96)}λ(3977)=mdc(40,96)∣40×96∣​

O JS não tem uma função para calcular o MDC, então vamos codar uma bem rápido aqui usando o algoritmo euclidiano, podemos aplicar recursivamente:

function mdc (a: number, b: number) {
  if (b === 0) return a
  return mdc(Math.abs(b), Math.abs(a)%Math.abs(b))
}

Mas ela é mais lenta, especialmente para números grandes, então vamos aplicar iterativamente:

function mdc(a: number, b: number) {
  let absA = Math.abs(a)
  let absB = Math.abs(b)

  while (absB) {
    ;[absB, absA] = [absA % absB, absB]
  }

  return absA
}

Agora podemos calcular λ(n), que vai ser:

function mdc(a: number, b: number) {
  let absA = Math.abs(a)
  let absB = Math.abs(b)

  while (absB) {
    ;[absB, absA] = [absA % absB, absB]
  }

  return absA
}

const p = 41
const q = 97
const n = p * q // 3977
const lambdaN = Math.abs((p-1)*(q-1))/mdc(p - 1, q - 1).mdc // 480

Com esses números podemos calcular d e e, vamos para e primeiro porque d depende dele.

e precisa ser um número pequeno, mas ele também precisa ser um número que seja maior que 2 e menor que λ(n), então não podemos usar 65537 porque nosso λ(n) é 8, além de que o MDC entre e e λ(n) deve ser 1, então vamos fazer uma função que calcula isso:

function publicExponent (lambdaN: number) {
  let e = 2
  while (mdc(e, lambdaN) !== 1 || e < lambdaN) {
    e++
  }
  return e
}

No nosso caso, e vai ser 7, um número pequeno. Então até agora temos isso aqui:

function mdc(a: number, b: number) {
  let absA = Math.abs(a)
  let absB = Math.abs(b)

  while (absB) {
    ;[absB, absA] = [absA % absB, absB]
  }

  return absA
}

function publicExponent (lambdaN: number) {
  let e = 2
  while (mdc(e, lambdaN) !== 1 && e < lambdaN) {
    e++
  }
  return e
}

const p = 41
const q = 97
const n = p * q // 3977
const lambdaN = Math.abs((p-1)*(q-1))/mdc(p - 1, q - 1) // 480
const e = publicExponent(lambdaN) // 7

Agora vamos calcular d, que deve ser um multiplicativo modular inverso de e, ou seja, vamos ter que calcular isso aqui:

\equiv e^{-1}(\mod(\lambda{n}))d≡e−1(mod(λn))

Isso significa que d é um número que, quando multiplicado por e, tem como resultado um número que é 1 mod(λ(n)).

Para calcular esse valor, podemos modificar o nosso MDC para usar o algoritmo estendido, que vai computar não só os dois divisores, mas também dois coeficientes chamados x e y que satisfazem uma identidade chamada identidade de Bézout.

Essa identidade diz que, para todos os MDCs existem dois números (chamados coeficientes) que podem ser utilizados como multiplicadores de uma função linear ax + by = mdc(a, b), ou seja, o maior divisor comum entre a e b podem ser expressados como uma função dos próprios parâmetros. Nosso número d é um desses coeficientes.

Vamos modificar o código pra refletir isso de acordo com essa implementação:

function mdc(a: number, b: number) {
  let [absA, absB] = [Math.abs(a), Math.abs(b)]
  let [prevX, x] = [1, 0]
  let [prevY, y] = [0, 1]

  while (absB) {
    const q = Math.floor(absA / absB)
    ;[absB, absA] = [absA % absB, absB]
    ;[x, prevX] = [prevX - q * x, x]
    ;[y, prevY] = [prevY - q * y, y]
  }

  return {
    mdc: absA,
    x: prevX,
    y: prevY
  }
}

Para isso vamos modificar os demais códigos também para poder corrigir o retorno da função que agora é um objeto, e já criar a nossa função modular inversa, ficamos com isso no final:

function mdc(a: number, b: number) {
  let [absA, absB] = [Math.abs(a), Math.abs(b)]
  let [prevX, x] = [1, 0]
  let [prevY, y] = [0, 1]

  while (absB) {
    const q = Math.floor(absA / absB)
    ;[absB, absA] = [absA % absB, absB]
    ;[x, prevX] = [prevX - q * x, x]
    ;[y, prevY] = [prevY - q * y, y]
  }

  return {
    mdc: absA,
    x: prevX,
    y: prevY
  }
}

function modInverse(e: number, m: number) {
  const result = mdc(e, m)
  if (result.mdc !== 1) {
    throw new Error('modular inverse does not exist')
  }
  return ((result.x % m) + m) % m
}

function publicExponent(lambdaN: number) {
  let e = 2
  while (mdc(e, lambdaN).mdc !== 1 && e < lambdaN) {
    e++
  }
  return e
}

const p = 41
const q = 97
const n = p * q // 3977
const lambdaN = Math.abs((p-1)*(q-1))/mdc(p - 1, q - 1).mdc // 480
const e = publicExponent(lambdaN) // 7
const d = modInverse(e, lambdaN) // 343

Veja que nosso d é o nosso x da função modular, o que estamos fazendo é obter o resto de x por λ(n), depois somamos λ(n) para garantir que o resultado é positivo e pegamos o resto por λ(n) novamente para manter o valor entre 0 e λ(n)-1.

Agora que temos d, e e n não precisamos mais de p, q ou λ(n). d deve ser mantido privado.

Vamos fazer uma função para criptografar e descriptografar nossos dados, dado que ela é a mesma, vamos somente trocar os valores passados.

Criptografando na mão

A função final de criptografia é bem simples:

function encrypt(message: number, exponent: number, mod: number) {
  return (message ** exponent) % mod
}

E podemos fazer um teste!

const message = 42
const encrypted = encrypt(message, e, n) // 698
const decrypted = encrypt(encrypted, d, n) // NaN

Opa! O que aconteceu!? Porque estamos tendo um NaN? Se voltarmos um pouco no processo, vamos ver que o processo de decriptação é muito mais complexo porque estamos elevando uma mensagem a um d grande, então nossa mensagem ultrapassa os 52 bits que o JavaScript pode armazenar na memória. Para isso vamos ter que usar BigInts!

Nossa função de criptografia fica assim, certo?

function encrypt(message: number|bigint, exponent: number, mod: number) {
  return (message**exponent) % BigInt(mod)
}

Errado! BigInts não suportam o operador ** porque ele tenta converter para number no final, vamos ter que criar nossa própria função de exponenciação, que é bem simples, a gente só precisa iterar pelo número do expoente e multiplicar várias vezes:

function bigIntPower(base: number|bigint, exponent: number) {
  let result = 1n
  const bigBase = BigInt(base)
  for (let i = 0; i < exponent; i++) {
    result *= bigBase
  }
  return result
}

Agora podemos usar dentro da nossa função de criptografia:

function encrypt(message: number|bigint, exponent: number, mod: number) {
  return bigIntPower(message, exponent) % BigInt(mod)
}

Agora sim!

const message = 42
const encrypted = encrypt(message, e, n) // 698n
const decrypted = encrypt(encrypted, d, n) // 42n

Para finalizar essa parte, podemos criar um keyset em um objeto bonitinho:

type Key = { exp: number, mod: number }
const publicKey = { exp: e, mod: n }
const privateKey = { exp: d, mod: n }

E ai modificamos a função de encriptação para aceitar uma chave:

function encrypt(message: number|bigint, key: Key) {
  return bigIntPower(message, key.exp) % BigInt(key.mod)
}

E ficamos com esse código final (veja no gist):

/**
 * Calcula a potência de um número bigInt
 * O JS não suporta números inteiros maiores que 2^53-1
 * e BigInts não podem ser usados com o operador **, por isso
 * essa função foi criada
 */
function bigIntPower(base: number|bigint, exponent: number) {
  let result = 1n
  const bigBase = BigInt(base)
  for (let i = 0; i < exponent; i++) {
    result *= bigBase
  }
  return result
}

/** 
 * Calcula o mdc de dois números e os coeficientes de Bézout
 * usando o algoritmo de Euclides estendido
 */
function mdc(a: number, b: number) {
  let [absA, absB] = [Math.abs(a), Math.abs(b)]
  let [prevX, x] = [1, 0]
  let [prevY, y] = [0, 1]

  while (absB) {
    const q = Math.floor(absA / absB)
    ;[absB, absA] = [absA % absB, absB]
    ;[x, prevX] = [prevX - q * x, x]
    ;[y, prevY] = [prevY - q * y, y]
  }

  return {
    mdc: absA,
    x: prevX,
    y: prevY
  }
}

/**
 * Calcula o inverso modular de um número
 */
function modInverse(e: number, m: number) {
  const result = mdc(e, m)
  if (result.mdc !== 1) {
    throw new Error('modular inverse does not exist')
  }
  return ((result.x % m) + m) % m
}

/**
 * Calcula o expoente público de uma chave RSA
 */
function publicExponent(lambdaN: number) {
  let e = 2
  while (mdc(e, lambdaN).mdc !== 1 && e < lambdaN) {
    e++
  }
  return e
}

/**
 * Criptografa/Descriptografa uma mensagem usando a chave RSA
 */
function encrypt(message: number|bigint, key: Key) {
  return bigIntPower(message, key.exp) % BigInt(key.mod)
}

const p = 41 // numero primo p pequeno
const q = 97 // numero primo q pequeno
const n = p * q // módulo n = 3977
const lambdaN = Math.abs((p-1)*(q-1))/mdc(p - 1, q - 1).mdc // totiente de carmichael = 480
const e = publicExponent(lambdaN) // expoente publico 7
const d = modInverse(e, lambdaN) // expoente privado 343

// Chaves
type Key = { exp: number, mod: number }
const publicKey = { exp: e, mod: n }
const privateKey = { exp: d, mod: n }

// Exemplo de uso
const message = 42
const encrypted = encrypt(message, publicKey) // 698n
const decrypted = encrypt(encrypted, privateKey) // 42n -> mensagem original

Variação de Euler

Se você leu até aqui, meus parabéns, não foi fácil! Mas eu queria te mostrar mais uma coisinha só! Lembra que eu comentei que podemos utilizar um totiente de Euler ao invés do totiente de Carmichael, e que ele é bem mais simples?

Bom, na verdade já estamos usando esse totiente. O totiente de Euler (φ(n)) é definido como sendo a multiplicação de p-1 por q-1, essa é a nossa função hoje:

const lambdaN = Math.abs((p-1)*(q-1))/mdc(p - 1, q - 1).mdc

Matematicamente mais bonitinha:

λn=∣(p−1)∗(q−1)∣mdc(p−1,q−1)λn=∣(p−1)∗(q−1)∣mdc(p−1,q−1)λn=mdc(p−1,q−1)∣(p−1)∗(q−1)∣​λn=∣(p−1)∗(q−1)∣mdc(p−1,q−1)\lambda{n} = \frac{|(p-1)*(q-1)|}{mdc(p-1, q-1)}λn=mdc(p−1,q−1)∣(p−1)∗(q−1)∣​

Olha ali no numerador, estamos lidando com o φ. Então se removermos a segunda parte (a divisão) não vamos ter nenhuma mudança no resultado:

const lambdaN = Math.abs((p-1)*(q-1))

// ... o resto do código aqui

const message = 42
const encrypted = encrypt(message, publicKey) // 698n
const decrypted = encrypt(encrypted, privateKey) // 42n -> mensagem original

O que muda então? φ(n) é muito maior do que λ(n), enquanto λ(n) é 480, φ(n) é 3840. Isso vai refletir em performance, lembre-se que estamos fazendo uma iteração por cada valor dentro da função MDC, quanto maior o número, mais iterações temos que fazer, então manter os números menores é melhor!

De qualquer forma, você pode ver a variação aqui.

Conclusão

Esse foi um dos maiores posts que eu já fiz, mas acredito que valeu muito a pena, exploramos a fundo o que é o RSA e como ele funciona, criamos duas chaves manualmente e testamos a criptografia manual. E agora?

Para criptografar texto ou qualquer outro valor não numérico, você precisa converter essa mensagem para um número entre 0 e o tamanho da sua chave, no nosso caso usamos uma chave pequena, mas se o valor passar dessa chave, vamos ter um problema de criptografia. Você pode converter qualquer string para um valor binário e usar as mesmas funções!

Os códigos para ambas implementações estão aqui e aqui e nos vemos na próxima parada com as chaves simétricas!

Até mais galera!

Novidades do Deno 1.40

Lucas Santos — Wed, 28 Feb 2024 11:00:45 +0000

O Deno chegou na versão 1.40 e essa é uma das versões mais legais de todas! Primeiro, porque ela tem a adição da Temporal API que eu estou falando aqui desde 2020! E eu acho que é o primeiro runtime a implementar essa funcionalidade de fato!

Além disso, uma série de outras novidades que eu vou passar por aqui uma por uma!

Temporal API

A temporal API é a nova forma de lidar com as datas no JavaScript, eu falei muito sobre ela neste artigo e mostrei todos os detalhes, então não vou entrar em muitos detalhes aqui, mas essencialmente, o Deno é o primeiro runtime que implementa essa API completamente.

Ela ainda está por trás de uma flag --unstable-temporal mas você já pode utilizar da mesma forma que a documentação oficial informa! Se você rodar um terminal com deno --unstable-temporal, você já pode fazer alguns testes:

console.log(Temporal.Now.instant()) // data e hora de hoje
console.log(Temporal.Now.zonedDateTimeISO()) // equivalente ao toISOString
const birthday = Temporal.PlainMonthDay.from("12-15");
const birthdayIn2030 = birthday.toPlainDate({ year: 2030 });
console.log(birthdayIn2030.toString()); // 2030-12-15

Por algum motivo o método Temporal.Now.timeZoneId não foi implementado.

Import.meta.filename e dirname

Isso aqui era algo que eu queria muito que acontecesse. Desde o advento dos ECMAScript modules, toda a forma de resolução de módulos mudou, o que significa que pegar o nome de um arquivo ou o diretório onde ele existe não são mais tão simples de buscar.

No Node, temos duas variáveis "mágicas" chamadas __dirname e __ filename que retornam respectivamente o caminho do diretório e do arquivo que você está executando.

Mas com ESM não podemos usá-las porque elas não são setadas no início da aplicação, então temos que buscar a URL do módulo com import.meta.url, que retorna uma fileURL no modelo file://caminho, e ai temos que usar dirname nessa URL, mas apenas depois de converter essa URL para um caminho!

import { fileURLToPath } from 'node:url'
import { dirname } from 'node:path'

const fileurl = import.meta.url
const path = fileURLToPath(fileurl)
const dir = dirname(path)
const filename = path.split('/').pop()

console.log({ fileurl, path, dir, filename })
/*
{
  fileurl: "file:///Users/lucas/repos/deno/teste.ts",
  path: "/Users/lucas/repos/deno/teste.ts",
  dir: "/Users/lucas/repos/deno",
  filename: "teste.ts"
}
*/

Isso era muito chato! Especialmente se você tinha que lidar com caminhos constantemente, então duas propostas foram adicionadas para poder suportar tanto o arquivo quanto a pasta, chamadas import.meta.filename e import.meta.dirname, agora você pode substituir tudo isso por:

console.log(import.meta.dirname) // /Users/lucas/repos/deno
console.log(import.meta.filename) // /Users/lucas/repos/deno/teste.ts

Decorators

Finalmente vamos ter suporte nativo a decorators, uma proposta que está no estágio final e deve chegar nos browsers logo mais! Depois de mais de 5 anos em espera, a nova proposta junta todas as propostas anteriores em uma só.

Um exemplo clássico que a gente pode dar é o @trace que serve para debugar qualquer função colocando um console antes e depois da execução:

function trace(fn: any, ctx: ClassMethodDecoratorContext) {
  return function (...args: unknown[]) {
    console.log("ENTERED", ctx.name);
    const v = fn(...args);
    console.log("EXITED", ctx.name);
    return v;
  };
}

class App {
  @trace
  static start() {
    console.log("Hello World!");
  }
}

App.start();

Imports mais simples

Essa é outra novidade interessante. Antigamente, quando tínhamos import maps com módulos que tinham subdiretórios, tínhamos que definir dois imports diferentes:

{
  "imports": {
    "preact": "npm:preact@10.5.13",
    "preact/": "npm:/preact@10.5.13/"
  }
}

Isso permitia que a gente pudesse importar tanto o top-level preact com import preact from 'preact', e também os submódulos tipo import hooks from 'preact/hooks'.

Agora a simplificação funciona para que você possa só ter um módulo no import map e consiga importar tudo da mesma raiz só com um map:

{
  "imports": {
    "preact": "npm:preact@10.5.13"
  }
}

Embora eu não goste muito de usar import maps e prefira a abordagem de um arquivo deps.ts

Outras mudanças

Uma série de APIs e comandos estão sendo depreciados, em especial o deno.run e deno.serveHttp
Suporte ao rejectionHandled, um evento que é disparado sempre que uma exception acontece em uma promise que já foi rejeitada (quando você tem um catch não usado)
Suporte a janelas com WebGPU
Suporte a novas APIs nativas do Node.js
Melhores mensagens no deno lint e deno doc

O conceito de "referência" e "valor" no JavaScript

Lucas Santos — Wed, 21 Feb 2024 11:00:38 +0000

Durante uma conversa na comunidade da Formação TS, um dos alunos perguntou sobre um dos temas que eram muito famosos no passado, mas eu mesmo não ouço falar dele faz alguns anos. O conceito de referência vs valor no JavaScript.

Então eu percebi que nunca tinha feito um conteúdo sobre isso e resolvi elaborar mais sobre esse tema.

O que é ref e val?

Referencia e valor são conceitos bem antigos, eu lembro que o Visual Basic tinha duas keywords que permitiam que você escolhesse se o resultado seria um ByVal ou ByRef:

Public Sub ChangeFieldValue(ByVal cls As Class1)
        cls.Field = 500
End Sub

Public Sub ChangeFieldReference(ByRef cls As Class1)
  cls.Field = 500
End Sub

A ideia é bastante simples:

Referências apontam para o objeto original como um ponteiro, então alterações em qualquer variável com esse ponteiro, vão alterar o objeto original também
Valores não alteram o objeto original porque o valor da variável é um clone do valor original, e não um ponteiro

Mas como isso funciona no JavaScript?

No JavaScript

No JavaScript a gente chama essa galera de Reference Type quando é uma referência ou Value Type para valores. Em suma, tudo que for um tipo primitivo em JS é passado por valor :

Numbers
Strings
Booleans

Sempre que você tiver um desses três tipos, você vai ter uma passagem por valor, ou seja, eles serão clonados quando você enviar a variável de um lugar para outro, por exemplo:

let original = 10

function vezesDois (num) {
  num *= 2
  return num
}

const mutado = vezesDois(original)

console.log(mutado) // 20
console.log(original) // 10

Veja que, mesmo que a gente modifique o valor da variável e associe ela novamente com o valor num, o valor original permaneceu 10, porque num é uma cópia do original.

Agora e com as referências? Todo esse conceito é um pouco diferente.

Referências

Tudo o que não for um primitivo no JS é tratado como um objeto, ou seja, muita coisa no JS é um objeto:

Objetos (claro)
Funções
Arrays
null
RegExp
Classes
...

Quando você cria um objeto no JS de forma literal ou pelo construtor, você está criando um ponteiro para algo chamado de hidden class (eu tenho um artigo só sobre isso, são 10 na verdade). Uma hidden class é um valor, o objeto que você criou aponta para esse valor, mas não vamos entrar em detalhes aqui.

O que é importante saber é que, sempre que você tiver um objeto, quando passarmos o objeto para outra variável ou para outra função, o ponteiro que vai ser passado, e não o valor em si. E isso é extremamente importante porque qualquer alteração no ponteiro, vai alterar o objeto original.

Você sabia?

Esse é um dos motivos pelo qual podemos usar const x = [] e depois modificar o array mesmo ele sendo constante, pois estamos modificando a referência e não o ponteiro. Mas se tentarmos associar x = [] isso não é possível porque [] é outro objeto e outro ponteiro.

O exemplo mais famoso disso são os métodos de arrays como sort e reverse, que modificam o array original (em conjunto com o push e o pop e muitos outros):

const original = [1, 2, 3, 4, 5]

function foo (arr: any[]) {
  arr.reverse()
}

console.log(original) // [1, 2, 3, 4, 5]
foo(original)
console.log(original) // [5, 4, 3, 2, 1]

Comparação

Um outro ponto importante é quando falamos de comparações usando referências. Quando estamos usando valores, podemos fazer algo assim:

const a = 10
const b = 10
console.log(a===b) // true

O que é totalmente válido visto que a e b tem o mesmo valor. Mas e se a gente fizer assim:

const a = { nome: 'Lucas' }
const b = { nome: 'Lucas' }
console.log(a===b) // false

Isso complica a cabeça de muita gente, tanta gente que eu até fiz um tweet sobre isso:

// Detect dark theme var iframe = document.getElementById('tweet-1510709606569414663-595'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1510709606569414663&theme=dark" }

Mas a realidade é que entender esse problema é bem simples. Lembra que falamos de ponteiros? Então, sempre que você cria um novo objeto com {} ou com o construtor, vamos ter um novo ponteiro, imagine que é algo assim:

const a = {} // ponteiro: 0x89ac (exemplo)
const b = {} // ponteiro: 0x1b3d

console.log(a === b) // 0x89ac === 0x1b3d? false

Claro que ponteiros são um pouco diferentes do que eu mostrei, mas você pegou a ideia. Não podemos comparar objetos porque as referências são diferentes, e só podemos saber se dois objetos são iguais caso a referência de ambos sejam iguais:

const a = {} // ponteiro: 0x89ac (exemplo)
const b = a // ponteiro: 0x89ac

console.log(a === b) // 0x89ac === 0x89ac? true

Cloning

Para sair desse problema e evitar que a gente modifique a variável original, existe o conceito de clonagem. Isso inclusive é um tema bastante interessante porque foi um dos temas do artigo sobre os novos métodos de arrays aqui do blog.

Quando clonamos um objeto, estamos pegando todas as propriedades do objeto original e jogando em outro ponteiro diferente, de forma que se mudarmos esse objeto, não vamos alterar a variável original. O mais comum era fazermos algo assim:

const original = [1, 2, 3, 4, 5]

function foo (arr: any[]) {
  const clone = Object.assign([], arr)
  return clone.reverse()
}

console.log(original) // [1, 2, 3, 4, 5]
const clone = foo(original) // [5, 4, 3, 2, 1]
console.log(original) // [1, 2, 3, 4, 5]

Veja que agora o array original continuou o mesmo. Com o tempo fomos removendo o uso do Object.assign para o uso do StructuredClone, que faz a mesma coisa mas com um twist:

const original = [1, 2, 3, 4, 5]

function foo (arr: any[]) {
  const clone = structuredClone(arr)
  return clone.reverse()
}

console.log(original) // [1, 2, 3, 4, 5]
const clone = foo(original) // [5, 4, 3, 2, 1]
console.log(original) // [1, 2, 3, 4, 5]

O twist é que, se você tem um objeto com outro objeto dentro, usando o Object.assign você só está clonando o ponteiro de fora, porque o próprio objeto tem um ponteiro para outro objeto dentro dele:

const nested = { c: 1 }
const objNested = {
  a: {
    b: nested
  }
}

function modify(obj) {
  obj.a.b.c = 10
}

console.log(objNested.a.b.c) // 1
modify(objNested)
console.log(objNested.a.b.c) // 10

E mesmo com o clone, isso não funciona:

const nested = { c: 1 }
const objNested = {
  a: {
    b: nested
  }
}

function modify(obj) {
  const clone = Object.assign({}, obj)
  clone.a.b.c = 10
}

console.log(objNested.a.b.c) // 1
modify(objNested)
console.log(objNested.a.b.c) // 10

Porque é como se estivéssemos lendo isso aqui:

const nested = { c: 1 } // ponteiro 0x1a
const objNested = { // ponteiro 0x5b
  a: {
    b: nested // objNested.a.b === c -> 0x1a === 0x1a -> true
  }
}

function modify(obj) {
  const clone = Object.assign({}, obj) // clone.a.b é 0x1a
  clone.a.b.c = 10 // estamos modificando o ponteiro de c aqui
}

console.log(objNested.a.b.c) // 1
modify(objNested)
console.log(objNested.a.b.c) // 10

Para funcionar, teríamos que falar que objNested.a.b = Object.assign({}, objNested.a.b.c), isso é simples quando temos um objeto filho, mas quando temos vários, essa função fica complicada. Por conta disso podemos usar o StructuredClone.

Conclusão

Espero que esse breve artigo tenha clarificado as ideias sobre as diferenças principais entre referências e valores com JavaScript, existe muito mais conteúdo legal sobre objetos por ai, inclusive, eu mesmo já escrevi um artigo sobre protótipos que vai te dar uma luz sobre como o JavaScript gerencia métodos e herança por baixo dos panos!

Até mais!

Novidades do TypeScript 5.4

Lucas Santos — Wed, 14 Feb 2024 11:00:19 +0000

Mais um dia e mais uma versão do TS está no ar! Dessa vez a gente vai trocar uma ideia sobre as principais mudanças no beta do TypeScript 5.4.

Lembrando que essa versão é um beta e pode ser que todas as funcionalidades não cheguem à versão final.

Melhor inferência em closures

Um dos grandes problemas que o TS tinha em inferência (ou type narrowing) era que, muitas vezes, dentro de closures como o map o tipo não seria inferido de forma correta.

Um exemplo clássico disso é quando temos um parâmetro que pode ser mais de um tipo, mas dentro da função é inferido para um único tipo:

function uppercaseStrings(x: string | number) {
    if (typeof x === "string") {
        return x.toUpperCase();
    }
}

Aqui, o TS vai saber que o tipo é uma string, porque estamos explicitamente dizendo que o tipo é string na checagem, portanto se ele passou ali, então é uma string.

Mas, quando usamos o mesmo tipo depois de ele ter sofrido o narrow, como nesse exemplo que a equipe do TS deu:

function getUrls(url: string | URL, names: string[]) {
    if (typeof url === "string") {
        url = new URL(url);
    }

    return names.map(name => {
        url.searchParams.set("name", name)
        // ~~~~~~~~~~~~
        // error!
        // Property 'searchParams' does not exist on type 'string | URL'.

        return url.toString();
    });
}

O problema é que, dentro da closure do map, o TS não inferia corretamente que o tipo URL não poderia ser algo diferente de uma URL, já que, se ele fosse uma string, ele seria convertido.

Para resolver esse problema, é muito comum criar uma nova variável intermediária que vai receber o valor final como let url = typeof url === 'string' ? new URL(url) : url

Só que, dentro do map, o TypeScript identificava que essa URL seria modificada em outro lugar, portando ele usa o valor do parâmetro, e ai temos um erro. Na nova versão, o TS é mais inteligente e consegue inferir os tipos baseados na última associação da variável então:

Se for um parâmetro ou uma variável do tipo let
Se essas variáveis forem usadas em funções que não são hoisted
O TS vai olhar o último lugar que essa variável sofre uma mudança e inferir o tipo a partir dali.

Porém se você modificar a variável em qualquer outro lugar, mesmo usando o mesmo valor, isso vai invalidar todas as tipagens posteriores porque não há como saber que o tipo se mantém.

NoInfer

Um novo utility type que veio para prevenir que o TS faça inferência de argumentos genéricos que são passados. Isso é algo que comentamos muito no módulo de generics da Formação TypeScript, existem dois tipos de generics:

Generics explícitos são aqueles que você pode passar diretamente o tipo: foo<string>('param')
Generics implícitos são inferidos pelo TS, então se foo fosse algo como foo<T> (a: T), poderíamos fazer foo('param') e o TS iria inferir nosso parâmetro como string

Porém nem sempre essa inferência funciona, especialmente para tipos super complexos. O exemplo que o time do TS deu aqui, porém, é bastante simples e ajuda a entender melhor o que está acontecendo:

function createStreetLight<C extends string>(colors: C[], defaultColor?: C) {
    // ...
}

createStreetLight(["red", "yellow", "green"], "red");

Aqui temos uma função que aceita uma lista de cores e uma cor opcional, então se chamamos a função como esperado, tudo funciona legal:

function createStreetLight<C extends string>(colors: C[], defaultColor?: C) {
    // ...
}

createStreetLight(["red", "yellow", "green"], "red");

Porém, quando usamos uma cor que não está no array de cores, o TS vai inferir que essa cor também é parte do array original:

// Aqui o generic C se torna red | yellow | green | blue
createStreetLight(["red", "yellow", "green"], "blue");

Existem duas formas atualmente de resolver esse problema, a primeira é criar um enumerador ou objeto com as cores permitidas:

const colors = ["red", "yellow", "green"] as const;
function createStreetLight<C extends typeof colors[number]>(colors: C[], defaultColor?: C) {
  // ...
}

createStreetLight(["red", "yellow", "green"], "blue");
// Blue vai ter um erro de não permitido pois não está no array original

Porém o ideal seria que a gente não precisasse ter um tipo externo e pudesse inferir um tipo a partir de outro, por isso geralmente criamos um outro generic que estende o primeiro:

function createStreetLight<C extends string, D extends C>(colors: C[], defaultColor?: D) {
}

createStreetLight(["red", "yellow", "green"], "blue");
// ~~~~~~
// error!
// Argument of type '"blue"' is not assignable to parameter of type '"red" | "yellow" | "green" | undefined'.

Veja que D extends C vai fazer a inferência de D com base no primeiro generic, portanto o segundo parâmetro não é atrelado ao primeiro. Mas, embora isso não seja ruim, criar um novo tipo genérico que só vai ser usado para isso é um pouco demais, por isso temos o novo tipo NoInfer.

Ele faz justamente isso, quando colocamos o NoInfer no parâmetro, estamos dizendo que não queremos que o TS faça uma nova inferência de um tipo original, então é como se falássemos "Pare de inferir o tipo aqui"

function createStreetLight<C extends string>(colors: C[], defaultColor?: NoInfer<C>) {
    // ...
}

createStreetLight(["red", "yellow", "green"], "blue");
// ~~~~~~
// error!
// Argument of type '"blue"' is not assignable to parameter of type '"red" | "yellow" | "green" | undefined'.

Uma outra forma de pensar nele é como "Não use esse parâmetro como candidato para uma inferência".

groupBy em Objetos e Maps

Seguindo as propostas de agrupamentos (como a do Array), agora temos os métodos estáticos Object.groupBy e Map.groupBy. Que, basicamente, recebem um iterável e transformam esse iterável em um objeto ou um map agrupado por uma determinada função.

Essa proposta já estava na lista de propostas do TC39 há um bom tempo

const array = [0, 1, 2, 3, 4, 5];

const myObj = Object.groupBy(array, (num, index) => {
    return num % 2 === 0 ? "par": "impar";
});

Isso vai nos dar um objeto final:

const myObj = {
    par: [0, 2, 4],
    impar: [1, 3, 5],
};

O mesmo vale para o Map.groupBy só que, ao invés de produzir um objeto no final, vamos ter um map.

É importante dizer que essas tipagens só vão estar funcionais se você utilizar o target como esnext ou ajustar as suas configurações no lib para conter essas tipagens. Mas, no futuro, essas funções vão estar em um target es2024

Outras mudanças

Os Import Attributes agora são tipados corretamente
Adicionadas quick fixes para parâmetros que faltavam no editor

Sobre Entrevistas Técnicas - Nunca foi sobre o código

Lucas Santos — Wed, 31 Jan 2024 11:00:42 +0000

Em mais de uma década trabalhando na área de TI, eu fiz minha cota de entrevistas, para empresas muito pequenas, empresas médias, empresas grandes e absurdamente grandes. Tanto nacionalmente quanto internacionalmente.

Mas foi quando estive do outro lado, como entrevistador (algumas dezenas de vezes depois), que eu notei como tudo era diferente...

Eu acho que chegou a hora de eu escrever sobre como tanto nós como devs quanto recrutadores estamos entendendo as coisas de forma diferente. Esse artigo vai ser bastante informal, com muitas opiniões minhas, e eu adoraria ouvir um pouco sobre o que você também tem a dizer!

Me chama lá no meu Twitter e me conta o que você acha e quais as suas opiniões sobre esse assunto!

Entrevistas técnicas

Desde que eu comecei a trabalhar, eu sempre tive muito medo de entrevistas, especialmente as técnicas (eu, na verdade, sempre gostei de entrevistas comportamentais), inicialmente eu tinha muito mais, hoje em dia se tornou algo muito mais simples, – especialmente com um mercado mais acelerado onde, como dev, a média de tempo que ficamos em um emprego é de um a dois anos – primeiro eu sempre achei que as pessoas iam me julgar e se eu, por algum motivo, não passasse na entrevista, isso invalidaria todo o trabalho que eu já fiz na vida até aquele momento. Eu era uma fraude!

Mas não é bem assim...

Com o tempo eu fui percebendo que entrevistas técnicas não eram só "um freela não remunerado", ou então "alguém muito sacana que está querendo que você falhe". Claro, entrevistas ruins são assim, mas as boas entrevistas vão muito além do código.

Tipos de entrevistas

Vamos começar diferenciando as etapas destas entrevistas e os tipos que elas podem aparecer para você, mas antes eu quero pincelar um tipo de entrevista interessante. O teste lógico.

Eu vou usar exemplos do que vi aqui (na Suécia) como sendo mais comum, mas isso pode variar de lugar pra lugar

Teste lógico e "entrevista inicial"

Eu nem chamo isso de entrevista por isso que estou colocando antes de tudo, mas é muito comum termos um teste de lógica básica, algo como:

"qual é a próxima figura dada essas três figuras"

O objetivo deste teste, pelo que eu sempre notei, era cortar pessoas que não teriam nenhuma chance nas próximas etapas que iriam requerer muito conhecimento lógico, imagina que é uma nota de corte, só isso.

Esse tipo de teste tanto não é uma entrevista técnica que ele geralmente acontece antes de qualquer entrevista, geralmente depois de uma entrevista inicial, que é uma chamada entre você e a pessoa que está gerenciando o processo (recruiter) só pra garantir que você é uma pessoa de verdade e atende os requisitos mínimos da vaga.

Testes de proficiência

Esse tipo de teste é o que a maioria da galera está acostumada. Um teste que é entregue pela empresa para que você resolva. Ele pode ter tipos diferentes, e pode acontecer de diversas formas, vamos falar de alguns que eu já passei:

Take-home assignment: É o teste enviado pela empresa através de um e-mail, zip ou qualquer coisa que você possa ler com calma, resolver e devolver. Esses são geralmente exercícios mais longos, com mais etapas, mas com um tempo muito maior para fazer e também não tem a pressão de estar sendo observado
Pair programming: Pode ser feito em pessoa ou em chamada, é a mesma coisa do exercício pra casa, só que você faz ao vivo, com alguém falando contigo. Idealmente não é para você se sentir pressionado, mas mesmo que a pessoa não esteja diretamente te julgando, ainda sim é um ambiente bem estressante. Esses exercícios geralmente começam com uma pergunta simples, que vai escalando aos poucos.
Revisão de código: É um meio a meio entre os dois anteriores, e pessoalmente o meu preferido, quando você tem uma etapa onde faz um exercício técnico, devolve, mas recebe feedbacks ao vivo e revisa o código com as pessoas mais técnicas do outro lado, isso tira um pouco da pressão, mas muitas vezes ambas acontecem com um tempo muito longo entre uma e outra e isso pode atrapalhar a resolução.
Entrevista de arquitetura : Uma entrevista focada em criar uma arquitetura para uma determinada solução, o objetivo aqui não é codar a solução, mas explicar como ela funcionaria e como você arquitetaria todo o projeto. Pelo menos aqui, as duas são feitas no mesmo processo para uma vaga.
Algorítmos: Esse tipo de entrevista é aquele onde você recebe um link para uma plataforma tipo o Codility, HackerRank, etc. É um exercício cujo foco é apenas na resolução técnica de um problema teórico, por exemplo: "Achar o menor número de uma lista".

Inclusive, fiz uma thread no Twitter com uma pesquisa sobre qual é o que a galera mais gosta e, sem dúvida, o mais votado foi o exercício para casa:

// Detect dark theme var iframe = document.getElementById('tweet-1733098042390106571-34'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1733098042390106571&theme=dark" }

E isso tem um motivo muito simples.

Entrevistas nunca são sobre código

Existem bons testes e maus testes. Os bons testes são complexos o suficiente para serem desafiadores, mas simples o suficiente para não serem impossíveis. E a parte mais importante: O código não importa.

O que importa nesse tipo de teste é o caminho da resolução do problema, claro que existem nuances de como alguém escreve um código, como a pessoa documenta esse código, como a performance é avaliada, mas você percebe que a pergunta não é sobre o código em si, mas como você pensa sobre o código?

Desafios que eu considero ruins são exatamente os desafios de algorítmos, eles são totalmente sobre o código, você raramente vai ter que resolver um problema desses na vida real, muito menos sobre pressão com algum tempo específico. Transformar uma entrevista em um teste de paciência e estresse é algo que não traz muito valor e, muitas vezes, a razão da falha é justamente por causa disso

Mas isso é uma forma de avaliar como você se comporta sob estresse

A não ser que o seu trabalho seja estar em constante estresse com deadlines absurdamente curtas para o que você precisa fazer, eu diria que talvez essa não seja uma boa empresa para estar...

Além disso, o foco direto no código, e somente no código, não deixa você analisar outras características do desenvolvimento, como comunicação, trabalho em equipe, resolução de problemas...

O código é uma das ferramentas, por exemplo, você precisa saber usar um rolo de pintura se você for um pintor, mas você não precisa saber todos os detalhes sobre todos os rolos de pintura existentes.

As boas entrevistas

Eu, particularmente, gosto de uma sequência de entrevistas que focam não só na parte técnica, muitas vezes a parte técnica nem é a parte mais importante (pelo menos não é para mim quando eu sou o entrevistador), simplesmente pelo fato de que você vai passar substancialmente mais tempo interagindo com o time e com outras pessoas do que codando, de fato.

Isso não significa que a parte técnica pode ser completamente ignorada, pelo contrário, ela é parte integrante do todo que compõe o trabalho, uma entrevista técnica muito ruim vai minar o sucesso da vaga, com certeza. Mas uma entrevista não técnica muito boa pode ser o diferencial entre ser aceito ou não, mesmo que outras partes não tenham sido tão boas.

Para mim, o processo ideal é:

Começar com uma entrevista inicial, que não é técnica, e foca apenas em conhecer a pessoa que está aplicando. Essa entrevista geralmente é feita com a pessoa que conhece da vaga, provavelmente a área de contratação. O objetivo aqui não é avaliar tecnicamente ninguém, mas entender o momento e o background da pessoa para ver se ela vai ter uma boa integração, deve ser curta, no máximo 20 ou 30 minutos.
Depois passamos por uma entrevista comportamental, chamada de behavioural interview , que é uma entrevista focada na parte não técnica da coisa. Ela dura 1h e geralmente as perguntas são relacionadas às coisas do passado, como a pessoa trabalhou com alguma coisa, como ela resolveu um determinado problema, quais foram as principais lições que ela tirou disso. Essa pra mim é a principal entrevista, se a pessoa não conseguir mostrar que ela é uma pessoa que vai se dar bem com o time ou que não tem a mesma ideia da empresa, ela é instantaneamente rejeitada, enquanto você pode não ir tão bem em uma entrevista técnica e ainda passar, mais uma vez: nunca foi sobre o código
o terceiro passo seria a entrevista técnica em si, focada em um desafio específico, vamos ver mais sobre no próximo parágrafo
No final podemos ou não ter uma entrevista de arquitetura, isso depende muito da vaga, eu não acredito que elas contribuem tanto dependendo do nível esperado.

Agora quais são os testes técnicos que eu acho que valem a pena serem aplicados

Os bons testes técnicos

Para mim um bom teste técnico é aquele que consegue replicar bem o ambiente de trabalho e, ao mesmo tempo, mostrar como é o processo de pensamento da pessoa, que é o mais importante.

Eu prefiro não aplicar testes de algoritmos pelos motivos que falei antes, não acho que eles sejam justos. Eles não mostram como alguém resolve um problema, mas sim que alguém consegue resolver aquele problema.

Além disso eu não gosto de testes surpresa onde você não sabe de nada previamente. isso não é real, você nunca vai entrar em uma empresa onde o produto que você precisa desenvolver simplesmente vai aparecer pronto pra você do nada, mas vai existir todo um processo de conhecimento daquele projeto.

Para mim os melhores testes são aqueles que são enviados para a pessoa e ela tem um determinado tempo (de dias e não horas) para finalizar, usando todos os recursos que ela puder. O teste é então enviado de volta e aí a entrevista técnica em si é sobre a revisão e perguntas sobre aquele código.

Eu acho esse um processo muito mais válido porque você está avaliando um código que foi feito pela pessoa, sobre um desafio imposto pela empresa. Muitas vezes a base do teste vem pronta e você precisa cumprir com alguns requisitos, adicionar outros e etc.

Outro tipo de teste que eu acho interessante é enviar uma aplicação pronta para a pessoa analisar geralmente um dia antes, no dia seguinte a entrevista seria uma série de perguntas para adicionar novas funcionalidades àquela aplicação. Eu acredito que essa é a forma de chegar mais perto do que seria um dia a dia na empresa, porque 99% do tempo nós não vamos criar nada, mas manter o que existe é adicionar coisas novas, além do que esse tipo de aproximação permite que a gente também veja o processo de pensamento de uma pessoa. Que é a parte mais importante.

E não importa se a pessoa finalizar ou não o teste, ou parte de um teste, o importante é saber se ela conseguiria ou não finalizar, ou se a forma de pensar é comunicar dela estaria correta. Lembre-se não é sobre o código.

Conclusão

Esse post foi uma forma de trazer um pouco do que eu aprendi depois de centenas de entrevistas tanto como candidato quanto como entrevistador e ter visto um pouco mais de como tudo isso funciona do ponto de vista técnico como dev.

A minha ideia é expandir mais nesse tópico com vídeos lá no meu canal e falar mais sobre cada parte do processo, mas criar vídeos é um processo complexo e eu queria ter certeza de que existe gente interessada no assunto.

Então, se você achar essa ideia interessante, me chama lá no twitter e me fala o que você achou mais interessante e o que eu posso focar mais nesse tópico! Vou adorar saber o seu feedback!

Aplicações em tempo real com Deno KV

Lucas Santos — Wed, 24 Jan 2024 11:00:34 +0000

Aplicações em tempo real sempre foram um grande problema para a maioria dos devs, principalmente porque elas seguem um paradigma bastante diferente do que a gente está acostumado a trabalhar.

Por conta disso, a maioria das aplicações que precisavam ser feitas com algum tipo de comunicação em tempo real acabavam indo para uma direção como WebSockets, que são um pouco mais difíceis de implementar então geralmente recorríamos a long polling quando não tínhamos tanta pressa em receber as atualizações.

O Deno mais uma vez inovou bastante em relação ao que pode ser feito com o runtime e as aplicações, deixando muito mais fácil a criação de aplicações em tempo real.

KV Watch

Há um tempo eu publiquei um artigo aqui falando sobre o novo banco de dados chave-valor do Deno, o Deno KV.

Só pra gente relembrar o que é o KV. Ele é um banco de dados no modelo chave-valor, ou seja, não temos estruturas como tabelas e etc, a maioria das nossas operações lógicas são feitas em cima de valores armazenados em chaves que seguem um padrão textual, por exemplo, os likes em um post com o ID 1234 poderia ser representado por um número armazenado na chave posts:1234:likes

O KV tem várias APIs super interessantes, como as filas e o cron, mas a que torna tudo isso possível é o watch.

Com essa nova API, o Deno KV pode observar mudanças em tempo real nas chaves, então sempre que uma dessas chaves mudar, a gente pode emitir um evento para algum lugar avisando dessa mudança.

A nova API funciona a partir de um async iterator que vai retornar o novo valor da chave observada:

const db = await Deno.openKv()

const stream = db.watch(["chave1"], ["chave", "2'])
for await (const entries of stream) {
  entries[0] // { key: ['chave1'], value: 'v', versionstamp: ... }
  entries[1] // o mesmo porém com a chave 2
}

Construindo aplicações em tempo real

Como a ideia desse artigo é ser bem curto e direto, eu não vou mostrar totalmente como podemos construir uma aplicação em tempo real aqui, mas vou dar um exemplo de como podemos trabalhar com essa nova ferramenta

Server-sent Events

O mais comum quando estamos fazendo aplicações em tempo real no frontend é tentar criar algum tipo de conexão persistente entre o cliente e o servidor – na verdade, esse é provavelmente o único jeito – que a gente está bem acostumado a chamar de WebSocket.

Existe um outro meio de criar essas conexões persistentes com um outro padrão da web chamado Server-Sent Events (SSE), que é algo realmente implementado no Oak.

SSE's são basicamente uma conexão que fica constantemente aberta a partir do cliente para o servidor, essencialmente um WebSocket, porém você pode fazer a comunicação por HTTP ao invés de realizar o envio de mensagens por TCP diretamente. E você faz isso através de um endpoint.

No frontend, nós criamos uma EventSource com um endpoint:

const eventSource = new EventSource("/api/users/123/notification/subscribe")

Do lado do servidor, temos que ter um handler para essa rota, que vai criar uma stream de dados:

import { Application, Router } from "https://deno.land/x/oak/mod.ts";

const app = new Application();
const router = new Router();

router.get('/api/users/:id/notification/subscribe', async (ctx) => {
  const target = ctx.sendEvents()
  const events = kv.watch(['users', ctx.params.get('id'), 'notifications'])
  for await (const {value} of events) {
    target.dispatchMessage({ notification: value })
  }
})

app.use(router.routes())
await app.listen({ port: 8080 })

Sempre que tivermos uma alteração no nosso array de notificações, vamos mandar ele para o front-end e podemos atualizar nosso cliente.

Claro que esse é um exemplo simples, mas mostra o que podemos fazer com essa API.

Momento FTS!

Se você curtiu esse artigo, eu também tenho um curso completo de TypeScript chamado Formação TypeScript!

Eu te convido a dar uma olhadinha lá se você quiser aprender mais sobre TypeScript comigo e a nossa incrível comunidade com centenas de alunos e alunas!

[

Formação TS

O primeiro e mais completo curso de TypeScript do Brasil

](https://formacaots.com.br/?ref=blog.lsantos.dev)

Cronjobs na cloud com Deno Cron

Lucas Santos — Wed, 17 Jan 2024 11:00:19 +0000

Continuando com as nossas novidades sobre Deno, dessa vez eu quero trazer algo que eu pessoalmente já precisei várias vezes mas nunca encontrei uma solução, cronjobs!

Cronjobs são processos que rodam repetitivamente em um intervalo pré-determinado. A ideia é bem simples, e eles são largamente utilizados para várias coisas, por exemplo, agendamentos de ações que devem acontecer em um determinado horário como postagens de redes sociais, ou então até mesmo processamento de cartões de crédito, eles são os famosos batch jobs.

O problema

Por mais simples que a ideia seja, os cronjobs tem um problema inerente à forma que eles funcionam. Como você tem que rodar alguma coisa de tempos em tempos, a única forma de saber quando ela precisa ser executada é ter um sistema que vai observar a data e verificar se existem jobs para serem executados naquele momento.

Isso demanda uma máquina que esteja sempre ligada, checando periodicamente (geralmente a cada minuto) se existe alguma coisa que ela possa fazer. O problema com isso são dois:

Preço

Manter uma máquina ligada o tempo todo, por menor que ela seja, custa um valor, principalmente se você escolher provedores cloud maiores.

Para reduzir isso, muita gente prefere ter uma máquina que já possuía antes, como um notebook antigo, um media server, um NAS ou, como eu já fiz, ter um Raspberry Pi conectado rodando o Cron do sistema (ou o Systemd).

Mas ai você tem outro problema: segurança e rede, como você expõe uma máquina como essa para poder ser acessada de fora, VPNs talvez? Mas e a segurança?

Todos esses problemas acabam tendo soluções, mas é um trabalho muito grande para algo que, às vezes, é muito pequeno.

Computação desperdiçada

A grande maioria dos serviços do tipo watchdog ou daemon não vão executar nada durante 90% do tempo de execução. Ou seja, se a gente tiver um sistema que é um cron, as chances é que em 90% dos ciclos que essa aplicação esteja rodando, nada esteja acontecendo.

Isso é uma computação desperdiçada, mas é ainda sim computação paga que liga diretamente com o que falamos antes, para resolver isso poderíamos usar Serverless, mas ai temos outro problema porque Serverless não é executado se não tiver um evento que execute essa função, então voltamos para o problema da máquina virtual.

A solução

Felizmente existem serviços que oferecem crontabs online, porém todos são pagos e geralmente não tem uma experiência de usuário muito boa, isso até o Deno Cron.

O Deno Cron é a mais nova adição à família do Deno Deploy, ele permite a inclusão de cronjobs que executam em um ambiente serverless direto no deploy da aplicação. E é tão simples quanto:

Deno.cron('Meu cronjob', '* * * * *', () => {
  console.log('Esse job roda a cada 1 minuto')
})

O primeiro parâmetro é o nome do seu job. Esse nome é muito importante porque ele é a chave que vai impedir outros cronjobs de serem criados como mesmo nome, e esse também é o nome que vai aparecer no painel.

No segundo parâmetro usamos uma sintaxe igual a do crontab (que você pode pegar em sites como o crontab.guru) e o terceiro é a nossa função.

Localmente esse cron vai se comportar como se fosse um setInterval, porém no Deno Deploy ele vai ter a sua própria aba, como essa que eu criei no playground do deno:

Veja a aba Cron

Se abrirmos a aba Cron no topo, vamos ver todas as execuções do Cronjob, bem como os logs na aba de logs:

O cron mostra apenas a última execução de cada cronjob definido, já os logs mostram tudo que aconteceu:

Para remover um cronjob basta remover o código e fazer o deploy novamente.

É importante dizer que os jobs não encavalam , ou seja, se um job já estiver rodando quando o outro iniciar, ele vai ser pulado.

Controle de falhas

O Deno Cron já vem com um sistema de controle de falhas exponencial, então é bem simples criar retries, é só você passar a opção backoffSchedule com um array de tempos em milissegundos, por exemplo:

Deno.cron(
  'Meu cronjob', 
  '* * * * *', 
  { backoffSchedule: [1000, 4000, 8000] }, 
  () => console.log('Esse job roda a cada 1 minuto')
)

Se este cronjob falhar, ele vai ter uma nova tentativa em 1 segundo, depois 4 depois 8. Você também pode passar um AbortSignal para que seja possível cancelar a execução da promise através de outro local.

Limitações e detalhes

Por enquanto a documentação do cron diz que só é possível criar cronjobs no top-level domain. Ou seja, não é possível criar um cron dentro de uma função ou dentro de algum escopo, dessa forma é necessário que você já saiba o que precisa ser executado de antemão. Para criar cronjobs dinâmicos as filas podem ser uma boa opção!

Além disso o fuso horário do Deno Cron é UTC, independente do local.

Essa é uma API que realmente vai facilitar muito a vida de quem está desenvolvendo usando Deno e TypeScript! Me conta ai o que você vai fazer com ela!

Até mais!

Momento FTS!

Se você curtiu esse artigo, eu também tenho um curso completo de TypeScript chamado Formação TypeScript!

Eu te convido a dar uma olhadinha lá se você quiser aprender mais sobre TypeScript comigo e a nossa incrível comunidade com centenas de alunos e alunas!

[

Formação TS

O primeiro e mais completo curso de TypeScript do Brasil

](https://formacaots.com.br/?ref=blog.lsantos.dev)