Come funziona la crittografia

SG/Send utilizza la crittografia simmetrica AES-256-GCM, eseguita interamente nel Suo browser. Il server non vede mai i Suoi dati in chiaro, i nomi dei Suoi file né le Sue chiavi di crittografia. Questa pagina spiega esattamente come funziona.

Crittografia simmetrica: una chiave, due operazioni

SG/Send utilizza la crittografia simmetrica — la stessa chiave cifra e decifra il file. Questo è il modello di crittografia più semplice e veloce, e quando eseguito correttamente, il più sicuro per il trasferimento di file.

Cos'è AES-256-GCM?

AES (Advanced Encryption Standard) è l'algoritmo di crittografia utilizzato da governi, banche e forze armate in tutto il mondo. 256 è la dimensione della chiave in bit — ci sono 2256 chiavi possibili, rendendo la forza bruta computazionalmente impossibile. GCM (Galois/Counter Mode) aggiunge la crittografia autenticata — non solo cifra, ma rileva anche se qualcuno ha manomesso il testo cifrato.

Perché simmetrica?

La crittografia simmetrica utilizza una chiave sia per la crittografia che per la decrittazione. Questo è diverso dalla crittografia asimmetrica (come RSA) che utilizza una coppia di chiavi. Per il trasferimento di file, la simmetrica è la scelta giusta: è veloce, ben compresa, e la Web Crypto API fornisce un'implementazione collaudata in ogni browser moderno.

L'intuizione chiave: se si controlla dove la chiave viene generata e dove viaggia, la crittografia simmetrica offre una confidenzialità perfetta. SG/Send genera la chiave nel Suo browser, e la chiave non tocca mai il server.

Il flusso di crittografia: passo dopo passo

Ecco esattamente cosa succede quando invia un file tramite SG/Send.

1

Generazione della chiave

Quando seleziona un file, il Suo browser genera una chiave AES casuale a 256 bit utilizzando la Web Crypto API (crypto.subtle.generateKey). Viene utilizzato il generatore di numeri casuali crittograficamente sicuro del sistema operativo. La chiave esiste solo nella memoria del Suo browser.

Browser Server | | | crypto.subtle.generateKey( | | { name: "AES-GCM", length: 256 }, | | true, | | ["encrypt", "decrypt"] | | ) | | | | Key generated: 3a7f...b2c1 (256 bits) | | Key stays here. Server knows nothing. | | |
2

Generazione dell'IV

Viene generato casualmente un vettore di inizializzazione (IV) di 12 byte (crypto.getRandomValues). L'IV garantisce che la crittografia dello stesso file due volte produca testo cifrato diverso. L'IV non è segreto — viene preposto all'output crittografato e inviato insieme al testo cifrato.

3

Crittografia

Il file viene crittografato nel browser utilizzando crypto.subtle.encrypt con l'algoritmo AES-GCM, la chiave generata e l'IV. L'output è testo cifrato + un tag di autenticazione a 128 bit. Il tag di autenticazione è la garanzia di integrità di GCM — se qualcuno modifica anche un solo bit del testo cifrato, la decrittazione fallirà.

Browser Server | | | plaintext ──► AES-256-GCM ──► ciphertext | | ▲ | | | | | key + IV | | | | Output = IV (12 bytes) | | + ciphertext (same size as plaintext) | | + auth tag (16 bytes) | | |
4

Caricamento

Solo l'output crittografato (IV + testo cifrato + tag di autenticazione) viene caricato sul server. Il server riceve un blob di byte dall'aspetto casuale. Assegna un ID trasferimento (12 caratteri casuali) e memorizza il testo cifrato. Nessun nome file, nessun hint sul tipo di contenuto, nessuna chiave — solo byte crittografati.

Browser Server | | | POST /transfers/create | | ──────────────────────────────────────────► | | | Stores: | PUT /transfers/{id}/upload | transfer_id: "a7x9k2m4p1" | Body: [IV + ciphertext + auth tag] | data: [encrypted bytes] | ──────────────────────────────────────────► | ip_hash: SHA256(ip + salt) | | timestamp: 2026-02-28T... | Key NEVER sent. File name NEVER sent. | | |
5

Condivisione del link

Il mittente riceve un link di download. La chiave di decrittazione viene inserita nel frammento URL (la parte dopo #). I frammenti URL non vengono mai inviati al server dal browser — questo è definito in RFC 3986. Il mittente condivide questo link attraverso qualsiasi canale scelga (email, chat, di persona).

Link format: https://send.sgraph.ai/download/a7x9k2m4p1#3a7f...b2c1 ├──────────── domain ────────────┤├─ transfer id ─┤├─ key ─┤ ▲ │ URL fragment (#) Never sent to server Stays in the browser
6

Decrittazione

Il destinatario apre il link. Il suo browser scarica i byte crittografati dal server, estrae la chiave dal frammento URL, separa l'IV dal testo cifrato e decrittografa utilizzando crypto.subtle.decrypt. Se il tag di autenticazione non corrisponde (manomissione rilevata), la decrittazione fallisce. Il server non partecipa mai alla decrittazione.

Recipient's Browser Server | | | GET /transfers/{id}/download | | ──────────────────────────────────────────► | | ◄────────────────────────────────────────── | | Response: [IV + ciphertext + auth tag] | | | | Key extracted from URL fragment (#) | | crypto.subtle.decrypt( | | { name: "AES-GCM", iv: IV }, | | key, | | ciphertext | | ) | | | | ──► plaintext file restored | | Server never saw the key or the plaintext. |

Cosa vede il server e cosa no

Questa è la garanzia di conoscenza zero. Ecco esattamente quali dati esistono sul server.

Il server memorizza

ID trasferimento — 12 caratteri casuali
Byte crittografati — indistinguibili da dati casuali
Hash IP — SHA-256 dell'IP + salt a rotazione giornaliera
Timestamp — quando il trasferimento è stato creato
Dimensione del file — dimensione del blob crittografato (byte)

Il server non vede mai

Chiave di crittografia — rimane nel browser, condivisa tramite frammento URL
Nome del file — mai inviato al server
Tipo di file — nessun metadato content-type memorizzato
Contenuto in chiaro — viene caricato solo il testo cifrato
Indirizzo IP in chiaro — sottoposto a hash prima della memorizzazione

Una compromissione completa del server — accesso totale al database, tutti i backup, tutti i log — non rivela nulla sul contenuto dei file trasferiti. Il testo cifrato è computazionalmente indistinguibile dal rumore casuale senza la chiave.

Stack tecnologico

Ogni livello è scelto per semplicità, sicurezza e deployment senza dipendenze.

Livello Tecnologia Scopo
Runtime Python 3.12 / arm64 Linguaggio del server applicativo
Web framework FastAPI via osbot-fast-api Routing HTTP e gestione delle richieste
Compute AWS Lambda + Mangum Esecuzione serverless, pay-per-use
Storage Memory-FS (Storage_FS) Backend intercambiabile: memoria, disco o S3
Crittografia Web Crypto API (AES-256-GCM) Crittografia lato client nel browser
Sistema di tipi Type_Safe (osbot-utils) Definizioni di schema senza Pydantic
Frontend Vanilla JS + Web Components Zero dipendenze da framework (IFD)
Test pytest, stack in-memory Nessun mock, nessuna patch, implementazioni reali
CI/CD GitHub Actions Pipeline di test, tag e deployment

Architettura del sistema

Due funzioni Lambda, un livello di storage, un CDN. Semplice per progettazione.

User Lambda (pubblico)

Funzione pubblica che gestisce i trasferimenti di file, i controlli di integrità, gli upload presigned, i vault personali e l'integrazione MCP. Accesso tramite Lambda Function URL dietro CloudFront.

18 endpoint

Admin Lambda (autenticato)

Funzione solo per amministratori per la gestione dei token, analisi, statistiche del server e strumenti admin MCP. Richiede autenticazione. Lambda separato = confine di sicurezza separato.

55 endpoint

Memory-FS (Storage_FS)

Ogni accesso allo storage passa attraverso un livello di astrazione. Il codice applicativo non sa se il backend è in memoria, su disco o su S3. Lo stesso codebase su tutti i 7 target di deployment.

Backend intercambiabile

CloudFront CDN

Asset statici, caching, terminazione SSL e WAF. Le Lambda URLs forniscono gli endpoint HTTPS direttamente — nessun API Gateway necessario.

Rete edge

Target di deployment

Un unico codebase, sette target di deployment raggruppati in quattro pattern.

Lambda

Deployment primario. Due funzioni Lambda dietro Lambda Function URLs. Endpoint HTTPS diretti, nessun API Gateway necessario.

Produzione

Container

Docker, AWS Fargate e GCP Cloud Run. La stessa applicazione confezionata come container.

Docker / Fargate / GCP

Server

Istanze EC2 e build AMI. Per i team che necessitano di pieno controllo sull'ambiente di runtime.

EC2 / AMI

CLI

Interfaccia a riga di comando per trasferimenti scriptati, pipeline CI/CD e utenti esperti.

Terminal
18
Agenti IA
73
Endpoint HTTP
393
Test superati
7
Target di deployment
Veda il codice sorgente su GitHub →