<![CDATA[It’s done, just needs testing]]>https://blog.maicol.devhttps://cdn.hashnode.com/res/hashnode/image/upload/v1730584153984/9acea3a2-9cfb-4cc1-9686-7b1023684f3f.pngIt’s done, just needs testinghttps://blog.maicol.devRSS for NodeFri, 17 Apr 2026 17:00:22 GMT60<![CDATA[Além do Código: Redes de Computador para Desenvolvedores]]>https://blog.maicol.dev/alem-do-codigo-redes-de-computador-para-desenvolvedoreshttps://blog.maicol.dev/alem-do-codigo-redes-de-computador-para-desenvolvedoresSat, 18 Jan 2025 03:02:43 GMT

Resumo

Hoje em dia, utilizamos amplamente o conceito de containers, o que nos obriga a compreender melhor essa tecnologia. Consequentemente, isso nos leva a adquirir ao menos um conhecimento básico sobre redes. Este artigo será focado no essencial que você precisa saber sobre redes para se sentir mais à vontade ao lidar com assuntos relacionados a TCP/IP.

Você vai encontrar os códigos apresentados aqui, no repositorio baixo:

→ https://github.com/vakaman/Alem-do-Codigo-Redes-de-computador-para-desenvolvedores

Por que entender redes é essencial para o sucesso do seu código?

Já de antemão e para ser bem sincero, pro seu código em sí, não muda muita coisa não, talvez em algum momento você tenha alguns insites interessantes por já ter visto uma abstração parecida em algum protocolo de rede.

Isso significa que redes não são um problema seu? Não! e eu posso provar.

Hoje vivemos na era dos containers e nos comunicamos com eles frequentemente através de redes TCP/IP, sendo assim… se você quer se manter longe de problemas quando o assunto é redes vem comigo, mas antes… vamos passar pelo básico.

Antes de começar, um ponto que acho interessante reforçar é… se você se sente confortável com o conhecimento de redes que tem hoje e o que eu falei anteriormente reforça a sua ideia de que você já sabe o suficiente, não continue, talvez não faça sentido de fato para você. Agora… se você quer desbravar algo que ainda não teve a oportunidade de ter contato, eu fico feliz e te desejo uma boa leitura.

Domínios de sub-rede

Imagine um cenário onde um grupo de computadores precisa se comunicar, porém para que isto seja possível, um padrão deve ser definido, uma das regras deste padrão é que cada um que entre neste grupo não possa ter identificadores duplicados. Outra regra importante é que os grupos têm tamanhos fixos e previamente definidos. Com isto em mente vou tentar explicar de uma forma didática o mínimo que você precisa saber para entender o conceito.

Aposto que você já viu algumas destas redes 10.0.0.1/24, 192.168.0.0/24, 172.31.0.0/24, e isto se dá pelo fato de serem redes utilizadas dentro do que chamamos rede local, para os exemplos à seguir vou utiliza o prefixo 192.168.0.0/24, mas o conceito se aplica para todos os prefixos do protocolo IP.

Dentro do prefixo 192.168.0.0/24 temos 255 posições, imagine que cada posição pode ser ocupada por um computador com exceção das reservadas.

Mas… como eu sei que são 255? que define isso? 🤔

A máscara de sub-rede, que neste caso é o /24. Mais um nome estranho né? eu sei…eu sei… calma… vamos por partes. Vamos passar pelos nomes logo abaixo, vai ficar fácil entender, confia.

Hostpode ser muitas coisas, desde sua televisão ao um contâiner do postgresqlUm dispositivo ou um serviço. Todos que tem suporte ao protocolo tcp/ip podem ser considerados um host.
IP192.168.0.0 ou 192.168.0.239 ou 1.1.1.1Um único endereço, a unidade de fato, o identificador de um host em uma rede.
Mascara de sub-rede255.255.255.0 ou simplesmente /24A definição dos limites, onde termina uma rede.
Prefixo ou Rede192.168.0.0/24A junção do IP com a máscara de sub-rede, define os limites da rede com os dois sabemos onde inicia e onde termina o range dos IP’s daquele domínio.

Quando definimos as fronteiras de uma rede, estamos estabelecendo um grupo onde todos os participantes podem se comunicar de forma direta ou seja

O host com o IP 192.168.0.10/24 pode se comunicar com o host 192.168.10.11/24 se a necessidade de ou terceiro elemento. Caso algum destes host queira se comunicar com o endereço 10.0.0.10 ele precisa passar por um roteador, mas… daí é uma longa história, vou tentar ir pelo caminho mais curto.

Se sabemos que o endereço 192.168.0.0/24 possui 255 ips e alguns são reservados, quais eu não posso usar?

NO | 192.168.0.0 → rede ( define o inicio da rede )

NO | 192.168.0.1 → gateway ( normalmente um roteador, ele conecta a rede local com outras redes)

YES | 192.168.0.2-254 → livre para alocação ( posições que podemos utilizar )

NO | 192.168.0.255 → broadcast ( envia mensagens para todos na mesma sub-rede simultaneamente )

Normalmente o que vemos em nossas casas é algo parecido com o desenho acima, onde temos um roteador e diversos hosts, cada um deles contém sua tabela de rotas, onde através dela os hosts sabem qual a rede que eles fazem parte e para quem ele precisa perguntar nos casos onde ele não conhece a rede.

Ok, ok tudo muito bonito e tals, mas… oq isso tem a ver com os containers?

Pois então… os containers fazem parte de uma sub-rede, e eles só conseguem se comunicar se estiverem na mesma rede e com permissão para tal.

O que é e pra que servem as portas?

De forma simplista as portas TCP têm a função de criar um canal de comunicação entre dois hosts. Essa conexão é associada a um processo, mas… se acalme que a gente vai chegar lá e você vai conseguir entender o que isso significa.

Existem 65535 portas TCP disponíveis, entretanto, existe uma organização separando as portas para cada contexto, vamos passar brevemente por esta separação

FUNÇÃORANGEDETALHE
WELL KNOWN PORT0-1023São portas utilizadas por sistemas e ou processos root
REGISTERED PORT1024-49151Portas registradas são usadas no TCP e listadas pela IANA como conveniência, mas não são controladas.
PRIVATE OR EPHEMETAL PORTS49152-65535Atribuídas dinamicamente para conexões temporárias

Vamos simular o cenário abaixo, para fazer com que o host A, crie uma conexão com o host B através das portas TCP.

Como podemos ver, temos um servidor, que chamamos de host_a_server, ele tem um processo PID 1, escutando na porta 6969.

Já do outro lado, temos um segundo elemento que chamamos de host_b_client, que deverá iniciar uma requisição para o servidor com destino a porta 6969 do servidor e para que a conexão seja estabelecida uma porta de origem é associada a esta conexão.

Servidor

import socket
import logging

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

HOST = '0.0.0.0'
PORT = 6969

logging.info("Iniciando servidor...")
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind((HOST, PORT))
server_socket.listen(1)

logging.info(f"Servidor escutando na porta {PORT}...")

try:
    while True:
        connection, client_address = server_socket.accept()
        logging.info(f"Conexão estabelecida com {client_address}")

        data = connection.recv(1024).decode('utf-8')
        if data:
            logging.info(f"Mensagem recebida: {data}")
            connection.sendall(
                "Olá, cliente! Conexão estabelecida.".encode('utf-8')
            )
        connection.close()
        logging.info(f"Conexão com {client_address} encerrada.")
except KeyboardInterrupt:
    logging.info("Servidor interrompido manualmente.")
finally:
    server_socket.close()
    logging.info("Servidor finalizado.")

Cliente

import socket
import logging
import os

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)


HOST = os.getenv("SERVER_HOST", "host_a_server")
PORT = 6969

logging.info(f"Tentando conectar ao servidor {HOST}:{PORT}...")
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

try:
    client_socket.connect((HOST, PORT))
    logging.info(f"Cliente conectado ao servidor {HOST}:{PORT}")

    client_socket.sendall("Olá, servidor!".encode('utf-8'))
    logging.info("Mensagem enviada ao servidor.")

    data = client_socket.recv(1024).decode('utf-8')
    logging.info(f"Resposta do servidor: {data}")
finally:
    client_socket.close()
    logging.info("Conexão com o servidor encerrada.")

Assim que rodamos o projeto, vamos ver este comportamento.

host_a_server  | 2025-01-19 13:05:16,795 - INFO - Iniciando servidor...
host_a_server  | 2025-01-19 13:05:16,795 - INFO - Servidor escutando na porta 6969...

host_b_client  | 2025-01-19 13:05:17,028 - INFO - Tentando conectar ao servidor host_a_server:6969...
host_b_client  | 2025-01-19 13:05:17,029 - INFO - Cliente conectado ao servidor host_a_server:6969
host_b_client  | 2025-01-19 13:05:17,029 - INFO - Mensagem enviada ao servidor.

host_a_server  | 2025-01-19 13:05:17,029 - INFO - Conexão estabelecida com ('1.2.9.3', 44890)

host_b_client  | 2025-01-19 13:05:17,029 - INFO - Resposta do servidor: Olá, cliente! Conexão estabelecida.
host_b_client  | 2025-01-19 13:05:17,029 - INFO - Conexão com o servidor encerrada.

host_a_server  | 2025-01-19 13:05:17,029 - INFO - Mensagem recebida: Olá, servidor!
host_a_server  | 2025-01-19 13:05:17,029 - INFO - Conexão com ('1.2.9.3', 44890) encerrada.

Podemos ver no container do servidor, que o mesmo está com uma porta listen no endereço 0.0.0.0, ou seja, a porta 6969 está disponível em qualquer uma das interfaces que o servidor possuir.

root@host_a_server:/app# netstat -nat
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:6969            0.0.0.0:*               LISTEN

Um ponto importante que vale ressaltar é que no contexto TCP/IP, precisamos entender que existem IP’s de origem e destino e portas de origem e destino para uma conexão estabelecida, ou seja, o IP e porta de origem de um host se comunica com o IP e porta de destino de outro host, esse processo acontece através do 3-way-handshake, mas não vou evoluir o assunto para este caminho, em todo caso se quiser mais detalhes, deixei nas referências um material falando do assunto.

Vamos falar de docker

Aposto que você já teve algum contato com docker, porém mágicamente meio que… em um cenário ideal, tudo meio que funciona certo?

Vamos pensar em um cenário onde temos uma aplicação, seja ela em PHP, Python, Js, tanto faz, vamos chamar ela de APP, um banco de dados, neste caso vou chamar de DB, e um serviço de cache, que simplesmente vou chamar de cache, o docker-compose dele será algo parecido com isso.

services:
    app:
        image: nginx:latest
        container_name: app
    db:
        image: mysql:latest
        container_name: db
        environment:
            MYSQL_ROOT_PASSWORD: root
            MYSQL_DATABASE: app
            MYSQL_USER: bad_user
            MYSQL_PASSWORD: bad_pass
    cache:
        image: redis:latest
        container_name: cache

Você vai perceber que se tentar subir estes serviços, cada um de forma isolada vai funcionar, porém não vão conseguir se comunicar, isso porque para que os serviços possam se comunicar, precisamos que eles façam parte da mesma rede, lembra?

Verificando a rede dos containers

Assim que subimos os serviços, cada um dos hosts/containers vão ter seu próprio endereço de IP, vamos verificar qual endereço foram associados utilizando o comando do docker em conjunto com o jq abaixo:

## Apenas comando do docker
docker container inspect app

## Comando do docker filtrando com jq a configuração de Network
docker container inspect app | jq '.[0].NetworkSettings'

Utilizando o comando acima, conseguimos ver que o endereço que o host (app) recebeu foi o endereço:

HOST: 1.2.7.2/24

{
  "Bridge": "",
  "SandboxID": "210f0e9ba9e77201d7e0f3a2948ce31826353c4727d8f45c0bcabb6bf5b020ac",
  "SandboxKey": "/var/run/docker/netns/210f0e9ba9e7",
  "Ports": {
    "80/tcp": null
  },
  "HairpinMode": false,
  "LinkLocalIPv6Address": "",
  "LinkLocalIPv6PrefixLen": 0,
  "SecondaryIPAddresses": null,
  "SecondaryIPv6Addresses": null,
  "EndpointID": "",
  "Gateway": "",
  "GlobalIPv6Address": "",
  "GlobalIPv6PrefixLen": 0,
  "IPAddress": "",
  "IPPrefixLen": 0,
  "IPv6Gateway": "",
  "MacAddress": "",
  "Networks": {
    "redes-docker_default": {
      "IPAMConfig": null,
      "Links": null,
      "Aliases": [
        "app",
        "app"
      ],
      "MacAddress": "02:42:01:02:07:02",
      "DriverOpts": null,
      "NetworkID": "961d9113f94092827308148af99793a9ea3d471716a14979b3dcce6683cd5b66",
      "EndpointID": "52e065cd20596fae04409ad82488297ba659c483b42527df4445e3b595533cae",
      "Gateway": "1.2.7.1",
      "IPAddress": "1.2.7.2",
      "IPPrefixLen": 24,
      "IPv6Gateway": "",
      "GlobalIPv6Address": "",
      "GlobalIPv6PrefixLen": 0,
      "DNSNames": [
        "app",
        "5ec26cac5ce0"
      ]
    }
  }
}

Continuando a inspeção, chegamos no seguinte resultado.

ServiçoIP/PREFIXGATEWAY
app1.2.7.2/241.2.7.1
db1.2.7.3/241.2.7.1
cache1.2.7.4/241.2.7.1

Ou seja

Ok, ok… então significa que a aplicação consegue falar com o banco de dados e consequentemente a aplicação também consegue falar com o cache, pois os mesmos estão na mesma rede certo?

Exatamente isso 👏👏👏, obviamente que para o contexto do docker existem restrições a nível de firewall que podem fazer com que os hosts não se comuniquem, mas… com o docker-compose.yaml que eu utilizei e com o Docker Compose version v2.20.3 e o docker Docker version 27.3.1, build ce12230. Assim que eu subi a aplicação, o docker utilizou a rede → redes-docker_default que está em modo bridge, permitindo a comunicação entre os serviços que fazem parte desta rede.

para inspecionar essa rede você pode utilizar o comando

~ docker network inspect redes-docker_default | jq '.[0].IPAM'
{
  "Driver": "default",
  "Options": null,
  "Config": [
    {
      "Subnet": "1.2.7.0/24",
      "Gateway": "1.2.7.1"
    }
  ]
}

Ao tentar pingar, do host da aplicação para o host do banco de dados, percebemos que existe uma resposta. Chegamos a conclusão de que a comunicação existe pois o ping informa quantos pacotes foram transmitidos e quantos destes foram recebidos.

### Acessando o container
~ docker exec -it app bash

### Testando a comunicação
root@app:/# apt-get install -y iputils-ping
root@app:/# ping db
PING db (1.2.7.3) 56(84) bytes of data.
64 bytes from db.redes-docker_default (1.2.7.3): icmp_seq=1 ttl=64 time=0.184 ms
64 bytes from db.redes-docker_default (1.2.7.3): icmp_seq=2 ttl=64 time=0.077 ms
64 bytes from db.redes-docker_default (1.2.7.3): icmp_seq=3 ttl=64 time=0.064 ms
64 bytes from db.redes-docker_default (1.2.7.3): icmp_seq=4 ttl=64 time=0.076 ms
64 bytes from db.redes-docker_default (1.2.7.3): icmp_seq=5 ttl=64 time=0.076 ms
64 bytes from db.redes-docker_default (1.2.7.3): icmp_seq=6 ttl=64 time=0.075 ms
^C
--- db ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5138ms
rtt min/avg/max/mdev = 0.064/0.092/0.184/0.041 ms

Em algumas situações, os hosts negam as requisições ICMP, fazendo com que o ping seja retornado, neste caso podemos utilizar o telnet, assim validamos se existe algum serviço escutando na porta informada.

root@app:/# telnet db 3306
Trying 1.2.7.3...
Connected to db.
Escape character is '^]'.
I
5}lNTcaching_sha2_password2#08S01Got timeout reading communication packetsConnection closed by foreign host.

Mais uma forma de testar conectividade é utilizando o nmap. Com ele podemos não só testar uma porta, mas também quais as portas abertas de um host.

root@app:/# nmap -p 3306 db
Starting Nmap 7.93 ( https://nmap.org ) at 2025-01-18 00:11 UTC
Nmap scan report for db (1.2.7.3)
Host is up (0.00011s latency).
rDNS record for 1.2.7.3: db.redes-docker_default

PORT     STATE SERVICE
3306/tcp open  mysql
MAC Address: 02:42:01:02:07:03 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds

Bora aprofundar?

Sendo bem transparente com você, o básico já passou e talvez… apenas com o que eu falei acima já dá pra ter uma boa noção de como a rede dos containers funciona e também, arrisco a dizer que… é um básico do básico de redes. Os mais entendidos do assunto sabem que tem bastante coisa pra falar ainda, mas… agora vamos dar uma aprofundada 😉👌

Domínios de broadcast

Assim como no mundo da camada 3 do modelo TCP/IP existe um identificador único que chamamos de IP e definimos uma rede através dos prefixos, fazendo com que os hosts participantes das redes possam se comunicar, na camada 2 também existe um identificador único que chamamos de MAC ou endereço físico e também podem se comunicar MAC’s que participam do domínio de broadcast. Partindo disso vamos ver os mesmos hosts de antes de uma perspectiva diferente.

Primeiramente, vamos ver todas as interfaces que fazem parte do domínio de broadcast da rede → redes-docker_default, para isso precisamos saber qual bridge foi criada pelo docker.

docker network ls | grep redes-docker_default
NETWORK ID     NAME                         DRIVER    SCOPE
961d9113f940   redes-docker_default         bridge    local

Com o comando acima, chegamos no NETWORK ID 961d9113f940, o docker cria uma bridge com o mesmo id, porém com o prefixo “br-”, conseguimos ver as interfaces virtuais associadas a bridge criada com o seguinte comando.

> ip link show master br-961d9113f940
39: vethbf30c22@if38: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-961d9113f940 state UP mode DEFAULT group default
    link/ether b6:62:83:bd:3c:88 brd ff:ff:ff:ff:ff:ff link-netnsid 0
43: veth512189f@if42: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-961d9113f940 state UP mode DEFAULT group default
    link/ether ce:c0:66:fb:7a:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 2
45: vethb57ac2a@if44: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-961d9113f940 state UP mode DEFAULT group default
    link/ether 5a:6a:f4:78:1c:9d brd ff:ff:ff:ff:ff:ff link-netnsid 1

Assim chegamos nos seguintes endereços fisicos associados a bridge.

b6:62:83:bd:3c:88

ce:c0:66:fb:7a:a9

5a:6a:f4:78:1c:9d

Bora descobrir quem é cada um?

Primeiramente precisamos entender que o docker relaciona uma interface virtual externa ao container com uma interface física dentro do container através do veth pair, onde uma espécie de túnel é criado, relacionando essas duas interfaces.

Vamos acessar o container e verificar qual o endereço mac está associado a ela e o indice externo que ela recebeu.

❯ docker exec -it app bash
root@5ec26cac5ce0:/# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:01:02:07:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Podemos ver que o mac do host app internamente é 02:42:01:02:07:02 e o índice associado a ele é o 39, podemos ver isto pois logo após o eth0 temos o @if39. Com esta informação em mente, vamos sair do container e verificar qual é a interface associada a bridge que está relacionada a interface do container.

Primeiramente, vamos localizar a interface com o índice 39, e então partindo da informação da interface virtual, vamos chegar até o endereço mac associado a ela.

### Localizando interface
ip link | grep "^39:"
39: vethbf30c22@if38: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-961d9113f940 state UP mode DEFAULT group default

### Verificando o MAC da interface
ip link show dev vethbf30c22
39: vethbf30c22@if38: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-961d9113f940 state UP mode DEFAULT group default
    link/ether b6:62:83:bd:3c:88 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Assim conseguimos descobrir que, o endereço MAC b6:62:83:bd:3c:88 é na verdade do container app, e que o endereço mac que aparece na bridge na verdade está fazendo o papel de conectar a interface externa com o endereço físico b6:62:83:bd:3c:88 a interface eth0 interna com o endereço 02:42:01:02:07:02

Caso você queira inspecionar diretamente a bridge que foi gerenciada pelo docker, podemos utilizar o comando abaixo

> docker network inspect redes-docker_default | jq .[0].Containers

O resultado será o seguinte

{
  "4a51cc332df584771fd3ec8d5c229073b1971d2167d3385cd9376ee0b7761a04": {
    "Name": "db",
    "EndpointID": "2be625310559ed29d7d9571f30f43668cc86c0f14612eb0e90ebffd1d51d88e3",
    "MacAddress": "02:42:01:02:07:03",
    "IPv4Address": "1.2.7.3/24",
    "IPv6Address": ""
  },
  "5ec26cac5ce0ddbb299aca8368b7ca77d9149b1ea378e5949b9092c4fa93e586": {
    "Name": "app",
    "EndpointID": "52e065cd20596fae04409ad82488297ba659c483b42527df4445e3b595533cae",
    "MacAddress": "02:42:01:02:07:02",
    "IPv4Address": "1.2.7.2/24",
    "IPv6Address": ""
  },
  "ad888d9e5cbd6a84d868d574b94744d16ef853711e5c4dcbaad4007e07eebd31": {
    "Name": "cache",
    "EndpointID": "ad7604bd382e4f7480303a1b2ca6e9f414af7b3fa54af8c4e5646c35af8a6bdf",
    "MacAddress": "02:42:01:02:07:04",
    "IPv4Address": "1.2.7.4/24",
    "IPv6Address": ""
  }
}

Assim conseguimos ver todos os MAC’s associados aos containers.

Internet das Coisas (IoT)

Para os Dev’s que chegaram até aqui… bora falar de uma coisa muito legal que é internet das coisas, e… eu aposto que você em algum momento já se perguntou… ué? mas como que o meu celular sabe que a minha TV está na minha casa? ou… como a Alexa sabe que existe uma lâmpada ou uma câmera de vigilância? Pois então meu amigo… o mundo do dev que conhece redes também é muito legal, vem comigo.

Primeiramente a gente precisa entender que não é somente o broadcast que ajuda a gente com o processo de descoberta, afinal o broadcast tem como funcionalidade principal, enviar uma mensagem para todos os participantes de uma rede.

Algumas estratégias envolvem:

Broadcast

Multicast

UPNP → SSDP (Simple Service Discovery Protocol)

Para a descoberta usando Broadcast

Neste exemplo abaixo, vamos fazer com que dois hosts se identifiquem através de broadcast, vou utilizar Python, mas tenho certeza que você vai encontrar algo na sua linguagem de preferência.

docker-compose.yaml

services:
  device1:
    build: .
    container_name: device1
    environment:
      - DEVICE_NAME=Device1
    networks:
      iot_network:
        ipv4_address: 192.168.1.10

  device2:
    build: .
    container_name: device2
    environment:
      - DEVICE_NAME=Device2
    networks:
      iot_network:
        ipv4_address: 192.168.1.11

networks:
  iot_network:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.1.0/24

dockerfile

FROM python:3.9-slim

WORKDIR /app
COPY broadcast.py /app/broadcast.py
RUN pip install --no-cache-dir --upgrade pip

CMD ["python", "/app/broadcast.py"]

broadcast.py

import socket
import threading
import time

BROADCAST_IP = "255.255.255.255"
PORT = 5005
DEVICE_NAME = "IoT Device"

discovered_devices = set()
stop_discovery = threading.Event()


def broadcast_sender():
    with socket.socket(
        socket.AF_INET,
        socket.SOCK_DGRAM,
        socket.IPPROTO_UDP
    ) as sender_socket:
        sender_socket.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
        while not stop_discovery.is_set():
            message = f"DISCOVER from {DEVICE_NAME}"
            print(f"[{DEVICE_NAME}] Enviando broadcast: {message}")
            sender_socket.sendto(message.encode(), (BROADCAST_IP, PORT))
            time.sleep(5)


def broadcast_receiver():
    with socket.socket(
        socket.AF_INET,
        socket.SOCK_DGRAM,
        socket.IPPROTO_UDP
    ) as receiver_socket:
        receiver_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        receiver_socket.bind(("", PORT))
        print(f"[{DEVICE_NAME}] Aguardando mensagens de broadcast "
              f"na porta {PORT}...")

        while not stop_discovery.is_set():
            message, address = receiver_socket.recvfrom(1024)
            decoded_message = message.decode()
            sender_ip = address[0]

            print(f"[{DEVICE_NAME}] Recebeu mensagem de {sender_ip}: "
                  f"{decoded_message}")

            if (sender_ip not in discovered_devices and
                    "DISCOVER" in decoded_message):
                discovered_devices.add(sender_ip)
                print(f"[{DEVICE_NAME}] Dispositivo descoberto: {sender_ip}")

                response = f"Hello from {DEVICE_NAME}!"
                print(f"[{DEVICE_NAME}] Respondendo a {sender_ip}: {response}")
                receiver_socket.sendto(response.encode(), address)

                stop_discovery.set()


if __name__ == "__main__":
    threading.Thread(target=broadcast_receiver, daemon=True).start()
    broadcast_sender()

O retorno da execução do exemplo acíma vai ser o seguinte

device2  | [IoT Device] Enviando broadcast: DISCOVER from IoT Device
device2  | [IoT Device] Aguardando mensagens de broadcast na porta 5005...
device2  | [IoT Device] Recebeu mensagem de 192.168.1.11: DISCOVER from IoT Device
device2  | [IoT Device] Dispositivo descoberto: 192.168.1.11
device2  | [IoT Device] Respondendo a 192.168.1.11: Hello from IoT Device!

device1  | [IoT Device] Enviando broadcast: DISCOVER from IoT Device
device1  | [IoT Device] Aguardando mensagens de broadcast na porta 5005...
device1  | [IoT Device] Recebeu mensagem de 192.168.1.10: DISCOVER from IoT Device
device1  | [IoT Device] Dispositivo descoberto: 192.168.1.10
device1  | [IoT Device] Respondendo a 192.168.1.10: Hello from IoT Device!

device2 exited with code 0
device1 exited with code 0

Para descoberta UPNP

dockerfile

FROM python:3.9-slim

WORKDIR /app

COPY upnp_discovery.py /app/upnp_discovery.py

RUN pip install --no-cache-dir --upgrade pip

CMD ["python", "/app/upnp_discovery.py"]

docker-compose.yaml

services:
  device3:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: device3
    environment:
      - DEVICE_NAME=Device3

  device4:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: device4
    environment:
      - DEVICE_NAME=Device4

networks:
  default:
    driver: bridge

upnp_discovery.py

import socket
import threading
import time

MULTICAST_IP = "239.255.255.250"
PORT = 1900
DEVICE_NAME = "UPnP Device"
SERVICE_TYPE = "ssdp:all"
MX = 2

discovered_devices = set()
stop_discovery = threading.Event()


def ssdp_sender():
    with socket.socket(
        socket.AF_INET,
        socket.SOCK_DGRAM,
        socket.IPPROTO_UDP
    ) as sender_socket:
        sender_socket.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)
        message = (
            "M-SEARCH * HTTP/1.1\r\n"
            f"HOST: {MULTICAST_IP}:{PORT}\r\n"
            "MAN: \"ssdp:discover\"\r\n"
            f"ST: {SERVICE_TYPE}\r\n"
            f"MX: {MX}\r\n"
            "\r\n"
        )
        while not stop_discovery.is_set():
            print(
                f"[{DEVICE_NAME}] Enviando mensagem SSDP:\n{message.strip()}"
            )
            sender_socket.sendto(message.encode(), (MULTICAST_IP, PORT))
            time.sleep(5)


def ssdp_receiver():
    with socket.socket(
        socket.AF_INET,
        socket.SOCK_DGRAM,
        socket.IPPROTO_UDP
    ) as receiver_socket:
        receiver_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        receiver_socket.bind(("", PORT))

        mreq = socket.inet_aton(MULTICAST_IP) + socket.INADDR_ANY.to_bytes(
            4,
            "big"
        )
        receiver_socket.setsockopt(
            socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq
        )

        print(f"[{DEVICE_NAME}] Aguardando respostas SSDP na porta {PORT}...")

        while not stop_discovery.is_set():
            try:
                message, address = receiver_socket.recvfrom(1024)
                sender_ip = address[0]
                decoded_message = message.decode()

                if sender_ip not in discovered_devices:
                    discovered_devices.add(sender_ip)
                    print(f"[{DEVICE_NAME}] Resposta recebida de {sender_ip}:\n{decoded_message.strip()}")
                    stop_discovery.set()
            except socket.timeout:
                pass


if __name__ == "__main__":
    threading.Thread(target=ssdp_receiver, daemon=True).start()
    ssdp_sender()

A resposta do script acima vai se parecer com esta abaixo, informando que os dispositivos passaram pelo processo de discover.

device4  | [UPnP Device] Aguardando respostas SSDP na porta 1900...
device4  | [UPnP Device] Enviando mensagem SSDP:
device4  | M-SEARCH * HTTP/1.1
device4  | HOST: 239.255.255.250:1900
device4  | MAN: "ssdp:discover"
device4  | ST: ssdp:all
device4  | MX: 2
device4  | [UPnP Device] Resposta recebida de 1.2.8.3:
device4  | M-SEARCH * HTTP/1.1
device4  | HOST: 239.255.255.250:1900
device4  | MAN: "ssdp:discover"
device4  | ST: ssdp:all
device4  | MX: 2
device4 exited with code 0


device3  | [UPnP Device] Enviando mensagem SSDP:
device3  | M-SEARCH * HTTP/1.1
device3  | HOST: 239.255.255.250:1900
device3  | MAN: "ssdp:discover"
device3  | ST: ssdp:all
device3  | MX: 2
device3  | [UPnP Device] Aguardando respostas SSDP na porta 1900...
device3  | [UPnP Device] Enviando mensagem SSDP:
device3  | M-SEARCH * HTTP/1.1
device3  | HOST: 239.255.255.250:1900
device3  | MAN: "ssdp:discover"
device3  | ST: ssdp:all
device3  | MX: 2
device3  | [UPnP Device] Resposta recebida de 1.2.8.2:
device3  | M-SEARCH * HTTP/1.1
device3  | HOST: 239.255.255.250:1900
device3  | MAN: "ssdp:discover"
device3  | ST: ssdp:all
device3  | MX: 2
device3 exited with code 0

Conclusão

O mundo do desenvolvimento não se limita às fronteiras do código, se permita aprofundar e olhar o que existe embaixo do capô, tenho certeza de que quanto mais deep você se deixar ir, mais apaixonado você vai ficar com o que a tecnologia tem pra te mostrar. Não sabemos e nunca vamos saber de tudo, mas… se deixe desbravar e se veja como um eterno aprendiz, alguém em constante evolução, pronto para transformar curiosidade em conhecimento e desafios em oportunidades. Afinal, a magia da tecnologia está justamente em sua infinita capacidade de nos surpreender e ensinar algo novo a cada dia.

Muito obrigado por ter chegado até aqui…

Referências

]]><![CDATA[Arroz com feijão: A base nutritiva para projetos que funcionam]]>https://blog.maicol.dev/arroz-com-feijao-a-base-nutritiva-para-projetos-que-funcionamhttps://blog.maicol.dev/arroz-com-feijao-a-base-nutritiva-para-projetos-que-funcionamSat, 21 Dec 2024 13:31:06 GMT

Resumo

Neste artigo vamos passar literalmente pelo mínimo. Começou agora? não sabe o que o teu projeto precisa para sobreviver as alterações do dia a dia? fica comigo que a gente vai passar pelo que provavelmente ninguém vai te cobrar pra fazer, mas sério… isso é o mínimo.

Só você sabe?… e talvez nem você saiba mais!

Já se deparou com a situação de ter que sustentar um produto, e ninguém sabe te dizer onde… como, e do que esse produto se alimenta?. Parece impossível né? afinal como que um sistema esta no ar e ninguém sabe de nada?. Pois então irmão, é muito mais comum do que parece.

Na rotina sufocante dos desenvolvedores é muito comum a sensação de urgência e sinceramente… se você se deixar levar por este ritmo, você vai ser engolido.

Com toda certeza, depois de tanto tempo trabalhando com desenvolvimento, uma das frases que mais ouvi ao longo da minha carreira foi: “não dá tempo”, e consequentemente, pilhas e pilhas de linha de código sobem sem o mínimo de empatia para a produção. Empatia? como assim…? sim sim, empatia, tenho certeza que você não está pensando no próximo desenvolvedor que vai olhar para o código que você escreveu, e arrisco a dizer que, não pensou em você mesmo.

Meses se passaram desde o ultimo commit naquele projeto esquecido que você deu manutenção, e olha que incrível, ele deu problema, e agora? quem foi o dev que escreveu aquelas linhas de código? vixx… foi eu mesmo 😅, mas… sei lá! faz tanto tempo, nem sinto que foi eu quem escreveu aquilo 🤷, já não me reconheço mais naqueles linhas de código.

É meio louco pensar nisso, mas, sim, você já não é mais o mesmo, e naquele momento só se preocupou em entregar a solução, e muito provável que achou completa perda de tempo investir algum tempo na documentação do projeto. Agora você se vê tendo que fazer o caminho do zero, entendendo novamente o fluxo inteiro, e tendo que investir novamente horas até chegar na solução.

A conclusão que eu cheguei com isto é, nunca é perda de tempo investir alguns minutos dando contexto suficiente para o seu “eu” do futuro, tenha empatia, nem que seja consigo mesmo, se é um comando, anote, coloque exemplos, explique como se estivesse explicando para uma criança, tenho certeza que você vai agradecer o seu “eu” do passado.

Como sobe isso aqui?

Assim como no tópico anterior, este aqui fala um pouco sobre empatia.

Imagine-se na situação de iniciar em uma empresa, onboard vai onboard vem, e em algum momento chega até o seu computador o sistema ao qual você vai dar suporte. Uma semana se passou e você ainda não conseguiu subir o dito cujo. Não acredita?… Rede do docker?… Migrations sendo rodadas na mão? variaveis de ambientes não documentadas? falta de permissão?… Fala com um, fala com outro, cada qual te da uma fração de informação e no final do dia… ninguém sabe exatamente como que a disgraça do programa sobe do inicio ao fim.

Já passei por algumas empresas e muitas delas não investiram sequer um dia automatizando o processo de build do projeto. Este comportamento agride diretamente o tempo que um desenvolvedor começa a se tornar produtivo para a empresa, sem falar da percepção de maturidade do sistema.

A minha recomendação é: se eu demoro mais de minutos para subir um projeto, algo de errado não está certo. Atualmente existem diversas formas de automatizar o processo de build do sistema, seja através de bash scripts ou makefiles;

Como um profissional de respeito, é seu dever se preocupar com o mínimo. Como instalar e configurar o seu sistema, como usar e preferencialmente com exemplos de uso. Não esqueça que se for necessário permissões adicionais para sustentar o sistema, uma boa documentação deve ajudar o desenvolvedor, guiando ele para abertura de chamados ou aquisição das devidas permissões.

Abaixo vou deixar um exemplo de readme, ele questiona alguns pontos que vejo como interessantes quando tenho o primeiro contato com o sistema, e… só pra reforçar… é o mínimo.

Exemplo de readme:

## 📝 **Descrição**

* Qual o objetivo do projeto? 
* Qual problema ele resolve? 
* Quais as principais funcionalidades?

## 🛠 **Dependencias**

* Este serviço depende de algum outro serviço ou ferramenta?
* Este serviço depende de algum cadastro em alguma plataforma ou permissão?

## 🚀 **Como rodar o projeto?**

* Quais são os passos necessários para rodar o projeto?
* Quais são as dependências necessárias? Docker? VPN? Certificado?

## 🧠 Como contribuir para o projeto?

* A branch principal é a `main`?
* Este projeto utiliza TAG's para versionamento?
* Respeitamos os testes de cobertura de código?

Testar pra quê?

Tá… eu sei, mais um artigo falando sobre testes… mas sério, você confia no seu código? sim!? pois não deveria! Você mente pra você o tempo todo, e vai por mim, o seu código também, confiar no próprio código não é reflexo de senioridade, e sim o completo oposto, você está sendo imaturo, deixe a sindrome do corno pra trás, não seja o ultimo a saber sobre o erro que seu cógido está gerando.

Mudanças acontecem com frequencia em um código vivo, código que não muda, provavelmente ou está morto ou chegou em um nível de abstração invejável.

Testes não devem ser tratados como opcional, e sim como motivo de orgulho. Pense só… qual a melhor forma de provar que você testou?! mostrando o teste ué!. Dizer que viu funcionar em uma única execução não garante absolutamente nada.

Tem preguiça de testar?… é no mínimo estranho… pois o reflexo da falta de testes vai gerar muito mais horas de trabalho que o tempo dedicado para escrita dos testes.

Testes, acredite ou não, fazem parte do mínimo…

Vamos ver como fazer um teste, bem básico, só pra você ter uma noção do esforço. Bora lá!

Como podemos ver, o objetivo desta classe é validar se o texto informado tem palavão. O código não tem como objetivo atender questões de arquitetura de software e as melhores práticas de mercado, to tentando ser didatico ok?

<?php

class BadWordsFilter
{
    private array $badWords;

    public function __construct(array $badWords)
    {
        $this->badWords = $badWords;
    }

    public function containsBadWords(string $text): bool
    {
        $wordsInText = $this->extractWords($text);

        foreach ($wordsInText as $word) {
            if ($this->isBadWord($word)) {
                return true;
            }
        }

        return false;
    }

    private function extractWords(string $text): array
    {
        // Remove caracteres especiais e retorna uma lista de palavras
        return preg_split('/\s+/', strtolower(trim(preg_replace('/[^\w\s]/', '', $text))));
    }

    private function isBadWord(string $word): bool
    {
        // Verifica se a palavra está na lista de palavras proibidas
        return in_array($word, $this->badWords, true);
    }
}

No teste abaixo conseguimos validar os seguintes pontos.

  • Um caminho feliz, ou seja, o texto informado tem um palavrão que foi previamente mapeado.

  • Outro caminho feliz é, o texto informado não tem palavrão

  • O código também tem a capacidade de identificar uma palavra mesmo com letras maiusculas e minusculas.

  • O código consegue detectar palavrão mesmo contendo caracteres especiais

  • E o código também lida bem com textos em branco.

<?php

use PHPUnit\Framework\TestCase;

class BadWordsFilterTest extends TestCase
{
    public function testContainsBadWordsReturnsTrueWhenTextContainsBadWord()
    {
        $filter = new BadWordsFilter(['badword', 'offensive']);

        $this->assertTrue($filter->containsBadWords('This text contains a badword.'));
    }

    public function testContainsBadWordsReturnsFalseWhenTextDoesNotContainBadWord()
    {
        $filter = new BadWordsFilter(['badword', 'offensive']);

        $this->assertFalse($filter->containsBadWords('This is a clean text.'));
    }

    public function testContainsBadWordsIgnoresCase()
    {
        $filter = new BadWordsFilter(['badword', 'offensive']);

        $this->assertTrue($filter->containsBadWords('This text contains a BADWORD.'));
    }

    public function testContainsBadWordsIgnoresSpecialCharacters()
    {
        $filter = new BadWordsFilter(['badword', 'offensive']);

        $this->assertTrue($filter->containsBadWords('This text contains a badword!'));
    }

    public function testContainsBadWordsHandlesEmptyText()
    {
        $filter = new BadWordsFilter(['badword', 'offensive']);

        $this->assertFalse($filter->containsBadWords(''));
    }
}

Como podemos ver, em momento algum eu precisei testar diretamente os métodos privados, afinal, a interface pública da classe, expõe a abstração que o cliente tem interesse, os detalhes que giram em torno dessa abstração precisam ser testadas mudando o input, mas usando o mesmo método público. Então… isso significa que eu não deva testar métodos privados? Não não, segura ai… extremos são ruins, e eu evito me guiar por eles, quando eu desenvolvo, espero seguir um meio termo, e isso envolve testes também. Eventualmente um método com mais de mil linhas vai passar na sua frente e existe uma chance de ele ser privado, e antes de fazer qualquer alteração nele, comece escrevendo testes com o comportamento do método coberto comece renomeando as variaveis para algo mais palatável, extraia alguns métodos e siga sua refatoração se guiando pelo teste.

Conclusão

Obviamente muitos outros pontos são de extrema importancia para um sistema que resista as evoluções solicitadas pelo time de produto, seja eles monitoramente, entrega contínua, gestão de segredos, tratamento de erros, estratégias de backup, etc.

Tenha orgulho pelo resultado do seu trabalho, no final do dia, apensa você sabe o que você fez, e se você não se sente confortável com o que você anda fazendo, o prazer pelo seu trabalho vai ser afetado, e isto é o que eu menos desejo para você.

Relembrando

  • Faça uma documentação, mínima que seja, dando contexto sobre o sistema

  • Ajude você e os outros com o processo de build e up do sistema no ambiente local.

  • Escreva testes, tá com preguiça de fazer unitário, faça de integração então, mas faça!

Ahhhh mas só isso não é nem o mínimo para ter um sistema top do top!. Calma dev sênior ultra mega foda das galaxias… para quem não tem nada o mínimo já é mais que d+. 😉

Referências

]]><![CDATA[Ei... ECDSA? bora!?]]>https://blog.maicol.dev/ei-ecdsa-borahttps://blog.maicol.dev/ei-ecdsa-boraSat, 02 Nov 2024 21:46:28 GMTOk, ok, este é meu primeiro artigo, então… pega leve comigo 🙏.

Neste ano de 2024, precisei lidar com algo muito incrível chamado ECDSA, e o melhor… eu não fazia ideia do que se tratava (não que eu domine completamente hoje, mas… já sei o suficiente para escrever este artigo), e… aposto que você também não, então bora comigo e vamos ver o poder dessa tecnologia 😜.

O que é ECDSA?

Bom, se a gente simplesmente partir para a definição de cada letrinha, significa (Elliptic Curve Digital Signature Algorithm), em bom portugues seria algo como → “Um monte de código que usa matematica pra assinar coisas".

De forma prática, o ECDSA permite que uma pessoa prove que é proprietaria de uma chave privada sem revelar a chave, assinando digitalmente um conteúdo que outras pessoas possam verificar usando a chave pública.

Este algoritmo se encaixa muito bem em:

  • Blockchain e Criptomoedas

  • Segurança de Redes

  • Assinaturas Digitais

Já ouviu falar em curva eliptica? pois então, eu até pouco tempo atrás também não, se segura que a gente vai dar uma longa volta… E… só pra reforçar… relaxa, se você conseguir chegar até o final, tenho certeza que você vai me agradecer.

O que é curva eliptica e porque eu preciso delas?

Curvas elípticas nos ajudam a definir uma espécie de caminho de mão única, onde é fácil realizar certas operações matemáticas, mas extremamente difícil revertê-las.

Em uma curva elíptica, é fácil multiplicar um ponto específico várias vezes para obter um novo ponto, mas é extremamente difícil descobrir quantas vezes a multiplicação foi feita para chegar naquele ponto resultante. Esse problema de encontrar o número de multiplicações necessárias é conhecido como o problema do logaritmo discreto e é o fundamento da segurança na criptografia de curvas elípticas(dá uma olhada nas referências depois).

Qual a aparência do monstro? 🤔

$$y 2 =x 3 +ax+b$$

Bora entender 🧐

Primeiramente a e b → são constantes que determinam a forma específica da curva (mais sobre formas de curva nas referências).

Cada combinação gera uma curva diferente e elas tem uma caracteristica interessante, onde os pontos da curva podem ser adicionados de forma unica para formar novos pontos. Usando o Desmos você consegue visualizar o que eu estou tentando dizer.

O X da equação, é relacionado a posição horizontal de um ponto na curva. Digamos que temos uma curva onde a = 2 e b = 3 então a equação ficaria

$$y 2 =x 3 +2x+3$$

Ok, mas… e se a gente escolher o valor do X? por exemplo… 1

$$y^2 = 1^ 3 + 2 . 1 +3$$

Podemos dizer que…

$$y 2 = 1 + 2 + 3 = 6$$

Doido né? chegamos no valor do Y definindo a forma da curva através das constantes A e B, e a posição de um ponto horizontal na curva através do x.

$$y^2 = ± \sqrt{6} ≈ ±2.449$$

Dai chegamos na conclusão que os pontos (1, 2.449) e (1, -2.449) são validos na curva.

Se a gente pegar um ponto inicial e for dando novos saltos, teremos algo semelhante a isto:

Primeiro gráfico:

  • a = 2 e b = 3

  • Os pontos P em azul e o Q em laranja

  • Estes são os pontos iniciais. Vamos usar eles nas proximas operações.

Segundo gráfico:

  • Usa o P e o Q gerado anteiormente

  • A soma dos pontos P + Q resulta no novo ponto, que chamamos de R

Terceiro gráfico:

  • Usamos a duplicação de pontos para que através da tangente que cruza a curva, acabamos chegando em outro ponto, chamado de 2P.

Espero que as ilustrações acima, tenham ajudado a entender como os pontos se relacionam. Acabamos usando a adição e duplicidade de pontos na curva.

Essas operações são a base de como o ECDSA funciona. No ECDSA, multiplicamos um ponto inicial na curva várias vezes para gerar uma chave pública segura, e a posição resultante no "caminho" da curva é usada como parte do processo de assinatura digital.

Cada ponto ( 𝑥 , 𝑦 ) na curva tem um papel específico. Ao multiplicar um ponto várias vezes, obtemos novos pontos, mas descobrir o número de multiplicações necessárias para chegar a um ponto específico é extremamente difícil — e essa dificuldade é o que torna o ECDSA seguro.

E eu sou responsável por definir estes valores?

Tá perdidinho né… eu também estava, relaxa que só piora, mas já adiantando, NÃO!

Existem alguns tipos de curvas padrão, como:

  • ecp256k1→ usado em blockchain

  • secp256r1 → usado nos protocolos TLS e SSL

  • secp384r1 → criptografar chaves públicas para segurança a longo prazo com alto nível de segurança, também TLS, SSL e SSH .

Estas curvas já tem seus valores previamente definidos. O pessoal do SECG (Standards for Efficient Cryptography Group) e NIST (National Institute of Standards and Technology) já cuidou disso pra gente, os valores, garantem segurança e compatibilidade, então apesar de saber que existe, não precisamos nos preocupar com isto 😜👌(nas referências temos mais detalhes)

Chega de Teoriaaaaaa 😣🤯

Sobreviveu? tá com pique? então vamo dale!

Gerando o par de chaves

Vamos utilizar o openssl que é uma ferramenta para geração de chaves. Esta chave gerada é compativel com ECDSA.

Lembra da curva secp256k1? é aqui que ela brilha ✨

Podemos gerar o par em conjunto

openssl ecparam -name secp256k1 -genkey -noout -out secp256k1_key.pem

E extrair o par de chaves publica e privada de uma única vez

openssl ec -in secp256k1_key.pem -noout -text

****** OUUUU *******

Podemos gerar apenas a chave privada

openssl ecparam -name secp256k1 -genkey -noout -out private_key.pem

Extraimos a chave pública baseado na chave privada gerada

openssl ec -in private_key.pem -pubout -out public_key.pem

Precisamos da chave pública em formato Hexadecimal não compactado para realizar as assinaturas, podemos gerar ela da chave publica ou diretamente da chave privada, abaixo vou deixar as duas abordagens.

### Extraindo da chave pública
openssl ec -pubin -in public_key.pem -outform DER -out public_key.der
tail -c 65 public_key.der | xxd -p -c 65

### Extraindo da chave privada
openssl ec -in private_key.pem -pubout -outform DER | tail -c 65 | xxd -p -c 65

A chave vai iniciar com 0x04 ou 04, que significa que não está compactada, e depois temos a sequencia de 32 bytes para cada uma das coordenadas x e y da chave pública em hexadecial total de 64 bytes.

### Chave completa
echo -e "### Chave completa\n""04eb59103e1bf87fc458f0cd188c51f1a872beae04\
e4df620d47e7282e8afee09fa5ef139bc781bfc42538f59dcc42e01e5d7e49f531d22e635\
0dfa70ea23cb040"

### Em partes

## 2 caracteres
04

## 64 caracteres
eb59103e1bf87fc458f0cd188c51f1a872beae04e4df620d47e7282e8afee09f

## 64 caracteres
a5ef139bc781bfc42538f59dcc42e01e5d7e49f531d22e6350dfa70ea23cb040

Devirando o endereço ethereum das chaves

Agora que conseguimos chegar na chave pública não compactada em formato hexa, conseguimos derivar desta chave um endereço ethereum, que basicamente define de forma pública uma referência de quem é o proprietário da chave.

Para isso vamos precisar de mais uma nome estranho, Keccak-256, esse rapaz é uma função de hash criptográfica que consegue gerar o hash que será utilizado para definir o endereço ethereum.

Existe uma receita definida pelos desenvolvedores do ethereum (olha as referências 😉)

# Hash inteiro
118a5195281508ca5ab70437c8496f9c8b1922627a4597bb9702b7ad7a9ac55c

O endereço é obtido a partir dos últimos 20 bytes do hash Keccak-256 da chave pública sem o prefixo 0x04.

# ultimos 20 bytes
c8496f9c8b1922627a4597bb9702b7ad7a9ac55c

Estes 20 bytes ou 160 bits que recuperamos, representam o endereço ethereum no formato hexadecimal e tem 40 caracteres. Ainda precisamos adicionar o prefixo 0x como uma ceraja no bolo 🍰.

### Endereço ethereum
0xc8496f9c8b1922627a4597bb9702b7ad7a9ac55c

Acha que acabou? peraí que tem mais uma ultima coisinha.

Foi introduzida uma etapa no processo para garantir que o endereço fique ainda mais seguro, usando um checksum, aplicando o keccak-256 ao endereço após ser convertido para maiúsculo baseado em algumas regras. Nas referências você vai encontrar o link para o EIP-55 Ethereum Improvement Proposal (EIP).

### Endereço final com o EIP-55 aplicado \0/
0xc8496F9C8B1922627A4597bb9702b7ad7A9AC55C

Abaixo disponibilizei alguns exemplos de código 😉

Javascript

https://codepen.io/vakaman/pen/yLmEGwv

Python

Para conseguir ver as rotas, onde eu mostro o funcionamento dos recursos, você vai precisar clicar no Ports e então localizar a porta 5000, depois só clicar no icone que diz Preview in editor e escolher a rota `Calculate Address` (talvez exista uma forma de fazer isso automaticamente, mas eu não achei como… então… me ajuda ai!)

https://codesandbox.io/s/ecdsa-python-3fydf3?embed=1&file=%2FREADME.md&showConsole=true

Assinando uma mensagem

Legal extrair o endereço ethereum né?… até então você deve tá pensando, onde esse maluco quer chegar com isso? E eu digo… calma, agora que a brincadeira fica interessante. Vamos usar a chave privada para realizar a assinatura de uma mensagem, se liga só!

No exemplo, vamos assinar a seguinte mensagem

    message = {
        "nome": "Maicol Oliveira",
        "idade": 34,
        "profissao": "Desenvolvedor"
    }

Consumindo a rota → sign_message, vamos ter o retorno da assinatura

{
  "assinatura": "b9092c7341aaac850c6209a800a0761d9333eb02e765461fd061137ee1bb259e0d90fe911ca5aa0e201e7d512d68d0dba97654d8dd0d0e9588449e9c659cc591"
}

Agora vamos validar esta assinatura, na rota → validate_signature_route, com a nossa chave privada, a mesma que usamos para assinar 😉

{
  "assinatura": "0x155f92d8c68a6741d4074b40d021bdc6e148aabb37ce43f8ce33d3720441c22d7405f748267537fa1ba683bc671e481d229f164a4f79e39bee5febade5861d9d",
  "is_valid": true,
  "message": {
    "idade": 34,
    "nome": "Maicol Oliveira",
    "profissao": "Desenvolvedor"
  }
}

BINGO!!! a assinatura é válida, incrível não é mesmo?

🧐🧐🧐🧐 Tá e… o que eu faço com isso?

Sei lá mano… te mostrei a ferramenta, boa sorte em onde você vai aplicar!🫠😂😅

Código de referência aqui

https://codesandbox.io/s/ecdsa-python-3fydf3?embed=1&file=%2FREADME.md&showConsole=true

Historinha para ajudar…

Tá.. blz, senta que lá vem a história, vamos fazer uma analogia, e depois… você que decide onde vai usar ok?

Imagine que você quer enviar uma mensagem secreta para seu amigo, mas precisa que alguém a transporte para você, e essa pessoa não pode descobrir o conteúdo e também não pode alterálo.

Como Proteger o Segredo? 🤔

Simples! coloque um “selo especial” 📩:

  • Você coloca sua mensagem em um envelope e usa este “selo especial” para fechá-lo. Esse selo é algo que só você sabe fazer – é único e impossível de replicar. O transportador pode ver o envelope, mas ele não consegue abrir sem estragar o selo.

  • Seu amigo conhece o selo. Assim, quando ele recebe o envelope e vê o selo intacto, ele sabe que:

    • A mensagem de fato veio de você

    • Ninguém abriu ou alterou o conteúdo no caminho

O Transportador Não Pode Interferir:

  • Quem transporta o envelope pode ver que ele tem seu selo, mas não tem como abrir e selar o envelope de novo da mesma forma.

Com isso entendemos que o suposto “selo especial” é a assinatura digital, o segreto que cria o selo é a sua chave privada, o amigo que verifica o selo é a chave pública, o conteúdo da mensagem ou o segredo que ela tem é o conteúdo, seja ele um texto ou um documento e o transportador é o canal de comunicação que pode ser a internet ou outro meio de transporte dessas informações.

Conclusão

Enfim… chegamos ao final, espero de coração que eu tenha ajudado. Tentei trazer de uma forma leve e mais didatica possível. Ficaria muito feliz com seu ponto de vista sobre o meu primeiro artigo e deixo completamente aberto o canal para feedback.

Referências

Ferramentas

]]>