Notre incapacité technique à accéder à vos clés : une garantie structurelle

Les questions les plus importantes concernant une messagerie sécurisée sont : "Pouvons-nous lire vos messages ?" et "Pouvons-nous livrer vos clés à une autorité ?". Pour iCanText, la réponse est un "Non" technique et sans équivoque. Cette page explique pourquoi ce n'est pas une promesse, mais une impossibilité inscrite dans notre architecture.

Le Principe Fondamental : L'Architecture « Zéro Connaissance »

iCanText est construit sur un principe de "Zéro Connaissance" (Zero-Knowledge). Cela signifie que nos serveurs, qui ne servent qu'à la mise en relation initiale (signalisation), n'ont jamais, à aucun moment, connaissance de vos clés de chiffrement, de votre identité, de vos contacts ou du contenu de vos messages. Cette ignorance n'est pas une politique, c'est une contrainte technique.

La génération de clés se fait chez vous, pas chez nous.

Lorsque vous utilisez iCanText pour la première fois dans un espace de travail, votre appareil (votre navigateur) génère localement une paire de clés cryptographiques unique. Cette paire de clés constitue votre identité souveraine pour cet espace. La clé privée, qui est le secret absolu permettant de vous identifier et de déchiffrer les messages qui vous sont destinés, **ne quitte jamais votre appareil**.

Le Cycle de Vie de Vos Clés : Deux Modes, Une Seule Promesse

Votre identité (vos clés) peut exister de deux manières, selon votre choix. Dans les deux cas, elles restent hors de notre portée.

1. Mode Éphémère (par défaut)

Si vous n'avez pas coché la case "Se souvenir de moi", votre identité est volatile. Vos clés privées sont générées et stockées uniquement dans la mémoire vive (RAM) de votre navigateur. Elles ne sont jamais écrites sur un disque. Lorsque vous fermez l'onglet ou le navigateur, ces clés sont instantanément et irrémédiablement effacées. C'est l'équivalent numérique d'une conversation qui s'évanouit dans l'air.

Dans ce mode, il n'y a littéralement rien à saisir, ni sur nos serveurs, ni sur votre appareil après la session.

2. Mode Persistant (optionnel)

Si vous choisissez de "vous souvenir", iCanText doit stocker vos clés privées sur votre appareil pour les sessions futures. Cependant, elles ne sont jamais stockées en clair. Voici le processus de sécurisation :

  1. Votre mot de passe est la clé : Lorsque vous activez ce mode, nous vous demandons un mot de passe. Ce mot de passe n'est **jamais** envoyé sur le réseau.
  2. Dérivation de clé robuste : Votre mot de passe est transformé en une clé de chiffrement complexe grâce à un algorithme standard et éprouvé (PBKDF2) avec un grand nombre d'itérations. Cette opération a lieu exclusivement dans votre navigateur.
  3. Chiffrement des clés : La clé dérivée de votre mot de passe est ensuite utilisée pour chiffrer vos clés privées d'identité (avec l'algorithme AES-GCM).
  4. Stockage local sécurisé : C'est uniquement ce bloc de données chiffrées qui est stocké dans le stockage local de votre navigateur (localStorage).

Sans votre mot de passe, ce fichier est un simple bloc de données aléatoires, indéchiffrable. Comme nous ne connaissons jamais votre mot de passe, nous ne pouvons pas le déchiffrer.

Pourquoi Say See Show, l'éditeur, ne peut rien faire

Notre incapacité à accéder à vos données est donc structurelle :

  • Nous n'hébergeons pas vos clés privées.
  • Nous ne connaissons pas le mot de passe qui protège vos clés stockées localement.
  • Nous n'avons pas de base de données centrale liant votre identité à votre personne.

Même si un employé malveillant ou une contrainte externe nous donnait un accès complet à toute notre infrastructure, il n'y trouverait rien d'exploitable concernant vos clés ou vos messages.

Pourquoi une requête judiciaire est techniquement inapplicable

Imaginons le scénario où une autorité judiciaire nous ordonnerait de fournir les clés d'un utilisateur. Nous serions dans l'incapacité technique de nous conformer à cette requête, et ce pour plusieurs raisons :

  • Pas de base de données d'utilisateurs : Nous ne savons pas "qui" est qui. Les identités sont des clés cryptographiques, non liées à des informations personnelles. Nous ne pouvons pas cibler un individu.
  • Pas de stockage central de clés : Il n'y a aucun serveur à saisir qui contiendrait un "trésor" de clés d'utilisateurs. Les clés sont distribuées sur les appareils des utilisateurs eux-mêmes.
  • Le chiffrement côté client : Même si une autorité saisissait l'appareil d'un utilisateur, les clés stockées en mode persistant resteraient chiffrées par un mot de passe que nous ne connaissons pas.
  • Le réseau P2P : Le contenu des messages transite entre les utilisateurs, pas via nos serveurs. Il n'y a donc pas de flux de communication à intercepter sur notre infrastructure.
Imaginez qu'iCanText vous fournit un coffre-fort de pointe et vous aide à le transporter chez vous. Vous êtes la seule personne à créer la combinaison et à la mémoriser. Nous n'avons ni double de la clé, ni copie de la combinaison. Nous ne pouvons pas ouvrir votre coffre, même si on nous l'ordonne.

Conclusion : La Confiance par la Preuve, Pas par la Promesse

De nombreuses entreprises promettent de protéger vos données. Notre approche est différente : nous avons conçu un système où nous n'avons même pas la possibilité technique de trahir cette promesse. La sécurité d'iCanText ne repose pas sur notre fiabilité, mais sur les lois mathématiques de la cryptographie et sur une architecture qui, par conception, nous place en dehors de votre cercle de confiance.

C'est ce que nous appelons la confidentialité structurelle : une sécurité que vous n'avez pas besoin de croire sur parole, mais que vous pouvez vérifier par l'architecture même du système.

Our Technical Inability to Access Your Keys: A Structural Guarantee

The most important questions about a secure messenger are: "Can you read my messages?" and "Can you turn over my keys to an authority?" For iCanText, the answer is a technical and unequivocal "No." This page explains why this isn't a promise, but an impossibility designed into our architecture.

The Core Principle: Zero-Knowledge Architecture

iCanText is built on a "Zero-Knowledge" principle. This means that our servers, which are only used for initial peer discovery (signaling), never, at any point, have knowledge of your encryption keys, your identity, your contacts, or the content of your messages. This ignorance is not a policy; it's a technical constraint.

Key Generation Happens on Your Device, Not Ours.

When you use iCanText for the first time in a workspace, your device (your browser) locally generates a unique cryptographic key pair. This key pair constitutes your sovereign identity for that workspace. The private key, which is the absolute secret that allows you to be identified and to decrypt messages sent to you, **never leaves your device**.

The Lifecycle of Your Keys: Two Modes, One Promise

Your identity (your keys) can exist in two ways, depending on your choice. In both cases, they remain beyond our reach.

1. Ephemeral Mode (Default)

If you do not check the "Remember me" box, your identity is volatile. Your private keys are generated and stored only in your browser's Random Access Memory (RAM). They are never written to disk. When you close the tab or browser, these keys are instantly and irretrievably erased. It is the digital equivalent of a conversation vanishing into thin air.

In this mode, there is literally nothing to seize, neither on our servers nor on your device after the session.

2. Persistent Mode (Optional)

If you choose to be "remembered," iCanText must store your private keys on your device for future sessions. However, they are never stored in plaintext. Here is the security process:

  1. Your Password is the Key: When you enable this mode, we ask for a password. This password is **never** sent over the network.
  2. Robust Key Derivation: Your password is transformed into a complex encryption key using a standard and proven algorithm (PBKDF2) with a high number of iterations. This operation takes place exclusively in your browser.
  3. Key Encryption: The key derived from your password is then used to encrypt your private identity keys (with the AES-GCM algorithm).
  4. Secure Local Storage: Only this encrypted data blob is stored in your browser's local storage (localStorage).

Without your password, this file is just a block of random, indecipherable data. Since we never know your password, we cannot decrypt it.

Why Say See Show, the Publisher, Can Do Nothing

Our inability to access your data is therefore structural:

  • We do not host your private keys.
  • We do not know the password that protects your locally stored keys.
  • We do not have a central database linking your identity to you as a person.

Even if a malicious employee or an external constraint gave us full access to our entire infrastructure, they would find nothing usable regarding your keys or messages.

Why a Judicial Request is Technically Unenforceable

Imagine a scenario where a judicial authority orders us to provide a user's keys. We would be technically unable to comply with this request for several reasons:

  • No User Database: We don't know "who" is who. Identities are cryptographic keys, not linked to personal information. We cannot target an individual.
  • No Central Key Storage: There is no server to seize that contains a "treasure trove" of user keys. The keys are distributed across the users' own devices.
  • Client-Side Encryption: Even if an authority were to seize a user's device, the keys stored in persistent mode would remain encrypted by a password we do not know.
  • The P2P Network: The content of messages travels between users, not through our servers. Therefore, there is no communication flow to intercept on our infrastructure.
Imagine that iCanText provides you with a state-of-the-art safe and helps you carry it home. You are the only person who creates the combination and memorizes it. We have no duplicate key, no copy of the combination. We cannot open your safe, even if ordered to do so.

Conclusion: Trust Through Proof, Not Promises

Many companies promise to protect your data. Our approach is different: we have designed a system where we don't even have the technical ability to betray that promise. The security of iCanText does not rely on our trustworthiness, but on the mathematical laws of cryptography and an architecture that, by design, places us outside your circle of trust.

This is what we call structural privacy: security that you don't have to take on faith, but can verify through the very architecture of the system.

Nuestra incapacidad técnica para acceder a sus claves: una garantía estructural

Las preguntas más importantes sobre una mensajería segura son: "¿Pueden leer mis mensajes?" y "¿Pueden entregar mis claves a una autoridad?". Para iCanText, la respuesta es un "No" técnico e inequívoco. Esta página explica por qué no es una promesa, sino una imposibilidad inscrita en nuestra arquitectura.

El Principio Fundamental: La Arquitectura de "Conocimiento Cero"

iCanText se basa en un principio de "Conocimiento Cero" (Zero-Knowledge). Esto significa que nuestros servidores, que solo se utilizan para el descubrimiento inicial de pares (señalización), nunca, en ningún momento, tienen conocimiento de sus claves de cifrado, su identidad, sus contactos o el contenido de sus mensajes. Esta ignorancia no es una política, es una restricción técnica.

La generación de claves se realiza en su dispositivo, no en el nuestro.

Cuando utiliza iCanText por primera vez en un espacio de trabajo, su dispositivo (su navegador) genera localmente un par de claves criptográficas único. Este par de claves constituye su identidad soberana para ese espacio. La clave privada, que es el secreto absoluto que permite identificarle y descifrar los mensajes que se le envían, **nunca abandona su dispositivo**.

El Ciclo de Vida de Sus Claves: Dos Modos, Una Sola Promesa

Su identidad (sus claves) puede existir de dos maneras, según su elección. En ambos casos, permanecen fuera de nuestro alcance.

1. Modo Efímero (por defecto)

Si no ha marcado la casilla "Recordarme", su identidad es volátil. Sus claves privadas se generan y almacenan únicamente en la memoria de acceso aleatorio (RAM) de su navegador. Nunca se escriben en un disco. Cuando cierra la pestaña o el navegador, estas claves se borran de forma instantánea e irremediable. Es el equivalente digital de una conversación que se desvanece en el aire.

En este modo, literalmente no hay nada que incautar, ni en nuestros servidores ni en su dispositivo después de la sesión.

2. Modo Persistente (opcional)

Si elige que se le "recuerde", iCanText debe almacenar sus claves privadas en su dispositivo para futuras sesiones. Sin embargo, nunca se almacenan en texto plano. Este es el proceso de seguridad:

  1. Su contraseña es la clave: Cuando activa este modo, le pedimos una contraseña. Esta contraseña **nunca** se envía a través de la red.
  2. Derivación de clave robusta: Su contraseña se transforma en una clave de cifrado compleja mediante un algoritmo estándar y probado (PBKDF2) con un gran número de iteraciones. Esta operación tiene lugar exclusivamente en su navegador.
  3. Cifrado de claves: La clave derivada de su contraseña se utiliza para cifrar sus claves de identidad privadas (con el algoritmo AES-GCM).
  4. Almacenamiento local seguro: Únicamente este bloque de datos cifrados se almacena en el almacenamiento local de su navegador (localStorage).

Sin su contraseña, este archivo es simplemente un bloque de datos aleatorios e indescifrables. Como nunca conocemos su contraseña, no podemos descifrarlo.

Por qué Say See Show, el editor, no puede hacer nada

Nuestra incapacidad para acceder a sus datos es, por lo tanto, estructural:

  • No alojamos sus claves privadas.
  • No conocemos la contraseña que protege sus claves almacenadas localmente.
  • No tenemos una base de datos central que vincule su identidad con usted como persona.

Incluso si un empleado malintencionado o una coacción externa nos diera acceso completo a toda nuestra infraestructura, no encontraría nada útil sobre sus claves o mensajes.

Por qué una solicitud judicial es técnicamente inaplicable

Imaginemos el escenario en el que una autoridad judicial nos ordenara proporcionar las claves de un usuario. Estaríamos en la incapacidad técnica de cumplir con esta solicitud, por varias razones:

  • Sin base de datos de usuarios: No sabemos "quién" es quién. Las identidades son claves criptográficas, no vinculadas a información personal. No podemos dirigirnos a un individuo.
  • Sin almacenamiento central de claves: No hay ningún servidor que incautar que contenga un "tesoro" de claves de usuario. Las claves se distribuyen en los propios dispositivos de los usuarios.
  • El cifrado del lado del cliente: Incluso si una autoridad incautara el dispositivo de un usuario, las claves almacenadas en modo persistente permanecerían cifradas con una contraseña que no conocemos.
  • La red P2P: El contenido de los mensajes transita entre los usuarios, no a través de nuestros servidores. Por lo tanto, no hay flujo de comunicación que interceptar en nuestra infraestructura.
Imagine que iCanText le proporciona una caja fuerte de última generación y le ayuda a llevarla a casa. Usted es la única persona que crea la combinación y la memoriza. No tenemos duplicado de la llave ni copia de la combinación. No podemos abrir su caja fuerte, aunque se nos ordene.

Conclusión: La Confianza a través de la Prueba, no de la Promesa

Muchas empresas prometen proteger sus datos. Nuestro enfoque es diferente: hemos diseñado un sistema en el que ni siquiera tenemos la capacidad técnica de traicionar esa promesa. La seguridad de iCanText no se basa en nuestra fiabilidad, sino en las leyes matemáticas de la criptografía y en una arquitectura que, por diseño, nos sitúa fuera de su círculo de confianza.

Esto es lo que llamamos privacidad estructural: una seguridad que no necesita creer en nuestra palabra, sino que puede verificar a través de la propia arquitectura del sistema.

La nostra incapacità tecnica di accedere alle vostre chiavi: una garanzia strutturale

Le domande più importanti riguardo a un servizio di messaggistica sicuro sono: "Potete leggere i miei messaggi?" e "Potete consegnare le mie chiavi a un'autorità?". Per iCanText, la risposta è un "No" tecnico e inequivocabile. Questa pagina spiega perché non è una promessa, ma un'impossibilità inscritta nella nostra architettura.

Il Principio Fondamentale: L'Architettura "a Conoscenza Zero"

iCanText è costruito su un principio di "Conoscenza Zero" (Zero-Knowledge). Ciò significa che i nostri server, utilizzati solo per la scoperta iniziale dei peer (segnalazione), non hanno mai, in nessun momento, conoscenza delle vostre chiavi di crittografia, della vostra identità, dei vostri contatti o del contenuto dei vostri messaggi. Questa ignoranza non è una politica, è un vincolo tecnico.

La generazione delle chiavi avviene sul vostro dispositivo, non sul nostro.

Quando utilizzate iCanText per la prima volta in uno spazio di lavoro, il vostro dispositivo (il vostro browser) genera localmente una coppia di chiavi crittografiche unica. Questa coppia di chiavi costituisce la vostra identità sovrana per quello spazio. La chiave privata, che è il segreto assoluto che permette di identificarvi e di decifrare i messaggi a voi destinati, **non lascia mai il vostro dispositivo**.

Il Ciclo di Vita delle Vostre Chiavi: Due Modalità, Una Sola Promessa

La vostra identità (le vostre chiavi) può esistere in due modi, a seconda della vostra scelta. In entrambi i casi, rimangono fuori dalla nostra portata.

1. Modalità Effimera (predefinita)

Se non avete spuntato la casella "Ricordami", la vostra identità è volatile. Le vostre chiavi private vengono generate e memorizzate solo nella memoria ad accesso casuale (RAM) del vostro browser. Non vengono mai scritte su un disco. Quando chiudete la scheda o il browser, queste chiavi vengono cancellate istantaneamente e irrimediabilmente. È l'equivalente digitale di una conversazione che svanisce nell'aria.

In questa modalità, non c'è letteralmente nulla da sequestrare, né sui nostri server, né sul vostro dispositivo dopo la sessione.

2. Modalità Persistente (opzionale)

Se scegliete di essere "ricordati", iCanText deve memorizzare le vostre chiavi private sul vostro dispositivo per le sessioni future. Tuttavia, non vengono mai memorizzate in chiaro. Ecco il processo di sicurezza:

  1. La vostra password è la chiave: Quando attivate questa modalità, vi chiediamo una password. Questa password non viene **mai** inviata in rete.
  2. Derivazione robusta della chiave: La vostra password viene trasformata in una chiave di crittografia complessa tramite un algoritmo standard e collaudato (PBKDF2) con un elevato numero di iterazioni. Questa operazione avviene esclusivamente nel vostro browser.
  3. Crittografia delle chiavi: La chiave derivata dalla vostra password viene quindi utilizzata per crittografare le vostre chiavi di identità private (con l'algoritmo AES-GCM).
  4. Archiviazione locale sicura: Solo questo blocco di dati crittografati viene memorizzato nell'archivio locale del vostro browser (localStorage).

Senza la vostra password, questo file è solo un blocco di dati casuali e indecifrabili. Poiché non conosciamo mai la vostra password, non possiamo decifrarlo.

Perché Say See Show, l'editore, non può fare nulla

La nostra incapacità di accedere ai vostri dati è quindi strutturale:

  • Non ospitiamo le vostre chiavi private.
  • Non conosciamo la password che protegge le vostre chiavi memorizzate localmente.
  • Non abbiamo un database centrale che colleghi la vostra identità a voi come persona.

Anche se un dipendente malintenzionato o una coercizione esterna ci desse pieno accesso a tutta la nostra infrastruttura, non vi troverebbe nulla di utilizzabile riguardo alle vostre chiavi o ai vostri messaggi.

Perché una richiesta giudiziaria è tecnicamente inapplicabile

Immaginiamo lo scenario in cui un'autorità giudiziaria ci ordinasse di fornire le chiavi di un utente. Saremmo tecnicamente impossibilitati a conformarci a questa richiesta, per diverse ragioni:

  • Nessun database di utenti: Non sappiamo "chi" è chi. Le identità sono chiavi crittografiche, non collegate a informazioni personali. Non possiamo prendere di mira un individuo.
  • Nessuna archiviazione centrale delle chiavi: Non c'è alcun server da sequestrare che contenga un "tesoro" di chiavi utente. Le chiavi sono distribuite sui dispositivi degli utenti stessi.
  • La crittografia lato client: Anche se un'autorità sequestrasse il dispositivo di un utente, le chiavi memorizzate in modalità persistente rimarrebbero crittografate da una password che non conosciamo.
  • La rete P2P: Il contenuto dei messaggi transita tra gli utenti, non attraverso i nostri server. Non c'è quindi alcun flusso di comunicazione da intercettare sulla nostra infrastruttura.
Immaginate che iCanText vi fornisca una cassaforte all'avanguardia e vi aiuti a portarla a casa. Siete l'unica persona a creare la combinazione e a memorizzarla. Non abbiamo una chiave duplicata, né una copia della combinazione. Non possiamo aprire la vostra cassaforte, anche se ci venisse ordinato.

Conclusione: La Fiducia attraverso la Prova, non la Promessa

Molte aziende promettono di proteggere i vostri dati. Il nostro approccio è diverso: abbiamo progettato un sistema in cui non abbiamo nemmeno la possibilità tecnica di tradire quella promessa. La sicurezza di iCanText non si basa sulla nostra affidabilità, ma sulle leggi matematiche della crittografia e su un'architettura che, per progettazione, ci colloca al di fuori della vostra cerchia di fiducia.

Questo è ciò che chiamiamo privacy strutturale: una sicurezza che non dovete credere sulla parola, ma che potete verificare attraverso l'architettura stessa del sistema.

Unsere technische Unfähigkeit, auf Ihre Schlüssel zuzugreifen: Eine strukturelle Garantie

Die wichtigsten Fragen zu einem sicheren Messenger sind: "Können Sie meine Nachrichten lesen?" und "Können Sie meine Schlüssel an eine Behörde aushändigen?". Für iCanText lautet die Antwort ein technisches und unmissverständliches "Nein". Diese Seite erklärt, warum dies kein Versprechen ist, sondern eine in unsere Architektur eingebaute Unmöglichkeit.

Das Grundprinzip: Zero-Knowledge-Architektur

iCanText basiert auf dem Prinzip des "Zero-Knowledge" (Null-Wissen). Das bedeutet, dass unsere Server, die nur zur anfänglichen Peer-Findung (Signalisierung) dienen, zu keinem Zeitpunkt Kenntnis von Ihren Verschlüsselungsschlüsseln, Ihrer Identität, Ihren Kontakten oder dem Inhalt Ihrer Nachrichten haben. Diese Unkenntnis ist keine Richtlinie, sondern eine technische Einschränkung.

Die Schlüsselerzeugung findet auf Ihrem Gerät statt, nicht auf unserem.

Wenn Sie iCanText zum ersten Mal in einem Arbeitsbereich verwenden, erzeugt Ihr Gerät (Ihr Browser) lokal ein einzigartiges kryptografisches Schlüsselpaar. Dieses Schlüsselpaar stellt Ihre souveräne Identität für diesen Bereich dar. Der private Schlüssel, das absolute Geheimnis, das Ihre Identifizierung und die Entschlüsselung an Sie gesendeter Nachrichten ermöglicht, **verlässt niemals Ihr Gerät**.

Der Lebenszyklus Ihrer Schlüssel: Zwei Modi, ein Versprechen

Ihre Identität (Ihre Schlüssel) kann je nach Ihrer Wahl auf zwei Arten existieren. In beiden Fällen bleiben sie für uns unerreichbar.

1. Ephemerer Modus (Standard)

Wenn Sie das Kästchen "Angemeldet bleiben" nicht aktivieren, ist Ihre Identität flüchtig. Ihre privaten Schlüssel werden nur im Arbeitsspeicher (RAM) Ihres Browsers generiert und gespeichert. Sie werden niemals auf eine Festplatte geschrieben. Wenn Sie den Tab oder den Browser schließen, werden diese Schlüssel sofort und unwiederbringlich gelöscht. Dies ist das digitale Äquivalent eines Gesprächs, das sich in Luft auflöst.

In diesem Modus gibt es buchstäblich nichts zu beschlagnahmen, weder auf unseren Servern noch auf Ihrem Gerät nach der Sitzung.

2. Persistenter Modus (Optional)

Wenn Sie wählen, "erinnert" zu werden, muss iCanText Ihre privaten Schlüssel für zukünftige Sitzungen auf Ihrem Gerät speichern. Sie werden jedoch niemals im Klartext gespeichert. Hier ist der Sicherheitsprozess:

  1. Ihr Passwort ist der Schlüssel: Wenn Sie diesen Modus aktivieren, fragen wir Sie nach einem Passwort. Dieses Passwort wird **niemals** über das Netzwerk gesendet.
  2. Robuste Schlüsselableitung: Ihr Passwort wird mit einem standardisierten und bewährten Algorithmus (PBKDF2) mit einer hohen Anzahl von Iterationen in einen komplexen Verschlüsselungsschlüssel umgewandelt. Dieser Vorgang findet ausschließlich in Ihrem Browser statt.
  3. Schlüsselverschlüsselung: Der aus Ihrem Passwort abgeleitete Schlüssel wird dann zur Verschlüsselung Ihrer privaten Identitätsschlüssel (mit dem AES-GCM-Algorithmus) verwendet.
  4. Sichere lokale Speicherung: Nur dieser verschlüsselte Datenblock wird im lokalen Speicher Ihres Browsers (localStorage) abgelegt.

Ohne Ihr Passwort ist diese Datei nur ein Block zufälliger, unentschlüsselbarer Daten. Da wir Ihr Passwort niemals kennen, können wir es nicht entschlüsseln.

Warum Say See Show, der Herausgeber, nichts tun kann

Unsere Unfähigkeit, auf Ihre Daten zuzugreifen, ist daher strukturell bedingt:

  • Wir hosten Ihre privaten Schlüssel nicht.
  • Wir kennen das Passwort nicht, das Ihre lokal gespeicherten Schlüssel schützt.
  • Wir haben keine zentrale Datenbank, die Ihre Identität mit Ihnen als Person verknüpft.

Selbst wenn ein böswilliger Mitarbeiter oder externer Zwang uns vollen Zugriff auf unsere gesamte Infrastruktur verschaffen würde, würden sie dort nichts Verwertbares bezüglich Ihrer Schlüssel oder Nachrichten finden.

Warum eine gerichtliche Anfrage technisch nicht durchsetzbar ist

Stellen wir uns ein Szenario vor, in dem eine Justizbehörde uns anweisen würde, die Schlüssel eines Benutzers bereitzustellen. Wir wären technisch nicht in der Lage, dieser Aufforderung nachzukommen, und das aus mehreren Gründen:

  • Keine Benutzerdatenbank: Wir wissen nicht, "wer" wer ist. Identitäten sind kryptografische Schlüssel, die nicht mit persönlichen Informationen verknüpft sind. Wir können keine Einzelperson ins Visier nehmen.
  • Keine zentrale Schlüsselspeicherung: Es gibt keinen Server, der beschlagnahmt werden könnte und einen "Schatz" an Benutzerschlüsseln enthält. Die Schlüssel sind auf den Geräten der Benutzer selbst verteilt.
  • Client-seitige Verschlüsselung: Selbst wenn eine Behörde das Gerät eines Benutzers beschlagnahmen würde, blieben die im persistenten Modus gespeicherten Schlüssel durch ein uns unbekanntes Passwort verschlüsselt.
  • Das P2P-Netzwerk: Der Inhalt der Nachrichten wird zwischen den Benutzern ausgetauscht, nicht über unsere Server. Es gibt also keinen Kommunikationsfluss, der auf unserer Infrastruktur abgefangen werden könnte.
Stellen Sie sich vor, iCanText stellt Ihnen einen hochmodernen Safe zur Verfügung und hilft Ihnen, ihn nach Hause zu tragen. Sie sind die einzige Person, die die Kombination erstellt und sich merkt. Wir haben keinen Zweitschlüssel und keine Kopie der Kombination. Wir können Ihren Safe nicht öffnen, selbst wenn man es uns befiehlt.

Fazit: Vertrauen durch Beweis, nicht durch Versprechen

Viele Unternehmen versprechen, Ihre Daten zu schützen. Unser Ansatz ist anders: Wir haben ein System entwickelt, bei dem wir nicht einmal die technische Möglichkeit haben, dieses Versprechen zu brechen. Die Sicherheit von iCanText beruht nicht auf unserer Vertrauenswürdigkeit, sondern auf den mathematischen Gesetzen der Kryptographie und einer Architektur, die uns von Natur aus außerhalb Ihres Vertrauenskreises platziert.

Das nennen wir strukturelle Privatsphäre: eine Sicherheit, die Sie nicht auf Treu und Glauben hinnehmen müssen, sondern die Sie durch die Architektur des Systems selbst überprüfen können.

Khả năng kỹ thuật của chúng tôi không thể truy cập khóa của bạn: Một sự đảm bảo về cấu trúc

Những câu hỏi quan trọng nhất về một trình nhắn tin an toàn là: "Bạn có thể đọc tin nhắn của tôi không?" và "Bạn có thể giao nộp khóa của tôi cho cơ quan chức năng không?". Đối với iCanText, câu trả lời là một "Không" dứt khoát về mặt kỹ thuật. Trang này giải thích tại sao đây không phải là một lời hứa, mà là một điều bất khả thi được thiết kế trong kiến trúc của chúng tôi.

Nguyên tắc cốt lõi: Kiến trúc "Không kiến thức"

iCanText được xây dựng trên nguyên tắc "Không kiến thức" (Zero-Knowledge). Điều này có nghĩa là các máy chủ của chúng tôi, chỉ được sử dụng để phát hiện ngang hàng ban đầu (báo hiệu), không bao giờ, tại bất kỳ thời điểm nào, có kiến thức về khóa mã hóa, danh tính, danh bạ hoặc nội dung tin nhắn của bạn. Sự thiếu hiểu biết này không phải là một chính sách; đó là một ràng buộc kỹ thuật.

Việc tạo khóa diễn ra trên thiết bị của bạn, không phải của chúng tôi.

Khi bạn sử dụng iCanText lần đầu tiên trong một không gian làm việc, thiết bị của bạn (trình duyệt của bạn) sẽ tạo ra một cặp khóa mật mã duy nhất tại chỗ. Cặp khóa này tạo thành danh tính chủ quyền của bạn cho không gian đó. Khóa riêng, là bí mật tuyệt đối cho phép nhận dạng bạn và giải mã các tin nhắn gửi cho bạn, **không bao giờ rời khỏi thiết bị của bạn**.

Vòng đời của khóa: Hai chế độ, một lời hứa

Danh tính của bạn (khóa của bạn) có thể tồn tại theo hai cách, tùy thuộc vào lựa chọn của bạn. Trong cả hai trường hợp, chúng đều nằm ngoài tầm với của chúng tôi.

1. Chế độ tạm thời (Mặc định)

Nếu bạn không chọn ô "Ghi nhớ tôi", danh tính của bạn sẽ biến động. Các khóa riêng của bạn được tạo và chỉ lưu trữ trong bộ nhớ truy cập ngẫu nhiên (RAM) của trình duyệt. Chúng không bao giờ được ghi vào đĩa. Khi bạn đóng tab hoặc trình duyệt, các khóa này sẽ bị xóa ngay lập tức và không thể phục hồi. Đây là phiên bản kỹ thuật số của một cuộc trò chuyện tan biến vào không khí.

Ở chế độ này, hoàn toàn không có gì để thu giữ, cả trên máy chủ của chúng tôi lẫn trên thiết bị của bạn sau phiên làm việc.

2. Chế độ bền vững (Tùy chọn)

Nếu bạn chọn được "ghi nhớ", iCanText phải lưu trữ các khóa riêng của bạn trên thiết bị cho các phiên sau. Tuy nhiên, chúng không bao giờ được lưu trữ ở dạng văn bản thuần túy. Đây là quy trình bảo mật:

  1. Mật khẩu của bạn là chìa khóa: Khi bạn bật chế độ này, chúng tôi yêu cầu một mật khẩu. Mật khẩu này **không bao giờ** được gửi qua mạng.
  2. Dẫn xuất khóa mạnh mẽ: Mật khẩu của bạn được chuyển đổi thành một khóa mã hóa phức tạp bằng một thuật toán tiêu chuẩn và đã được chứng minh (PBKDF2) với số lần lặp lại cao. Thao tác này chỉ diễn ra trong trình duyệt của bạn.
  3. Mã hóa khóa: Khóa được dẫn xuất từ mật khẩu của bạn sau đó được sử dụng để mã hóa các khóa danh tính riêng của bạn (với thuật toán AES-GCM).
  4. Lưu trữ cục bộ an toàn: Chỉ có khối dữ liệu được mã hóa này được lưu trữ trong bộ nhớ cục bộ của trình duyệt (localStorage).

Nếu không có mật khẩu của bạn, tệp này chỉ là một khối dữ liệu ngẫu nhiên, không thể giải mã. Vì chúng tôi không bao giờ biết mật khẩu của bạn, chúng tôi không thể giải mã nó.

Tại sao Say See Show, nhà phát hành, không thể làm gì

Do đó, việc chúng tôi không thể truy cập dữ liệu của bạn là có tính cấu trúc:

  • Chúng tôi không lưu trữ khóa riêng của bạn.
  • Chúng tôi không biết mật khẩu bảo vệ các khóa được lưu trữ cục bộ của bạn.
  • Chúng tôi không có cơ sở dữ liệu trung tâm liên kết danh tính của bạn với bạn như một cá nhân.

Ngay cả khi một nhân viên có ý đồ xấu hoặc một sự ép buộc từ bên ngoài cho chúng tôi toàn quyền truy cập vào toàn bộ cơ sở hạ tầng của mình, họ cũng sẽ không tìm thấy bất cứ điều gì có thể sử dụng được liên quan đến khóa hoặc tin nhắn của bạn.

Tại sao một yêu cầu tư pháp là không thể thực thi về mặt kỹ thuật

Hãy tưởng tượng một kịch bản trong đó một cơ quan tư pháp ra lệnh cho chúng tôi cung cấp khóa của một người dùng. Chúng tôi sẽ không thể tuân thủ yêu cầu này về mặt kỹ thuật, vì nhiều lý do:

  • Không có cơ sở dữ liệu người dùng: Chúng tôi không biết "ai" là ai. Danh tính là các khóa mật mã, không liên quan đến thông tin cá nhân. Chúng tôi không thể nhắm mục tiêu vào một cá nhân.
  • Không có lưu trữ khóa trung tâm: Không có máy chủ nào để thu giữ có chứa "kho báu" khóa người dùng. Các khóa được phân phối trên chính các thiết bị của người dùng.
  • Mã hóa phía máy khách: Ngay cả khi một cơ quan chức năng thu giữ thiết bị của người dùng, các khóa được lưu trữ ở chế độ bền vững vẫn sẽ được mã hóa bằng một mật khẩu mà chúng tôi không biết.
  • Mạng P2P: Nội dung tin nhắn được truyền giữa những người dùng, không phải qua máy chủ của chúng tôi. Do đó, không có luồng giao tiếp nào để chặn trên cơ sở hạ tầng của chúng tôi.
Hãy tưởng tượng rằng iCanText cung cấp cho bạn một chiếc két sắt hiện đại và giúp bạn mang nó về nhà. Bạn là người duy nhất tạo ra mã số và ghi nhớ nó. Chúng tôi không có chìa khóa dự phòng, không có bản sao của mã số. Chúng tôi không thể mở két sắt của bạn, ngay cả khi được lệnh.

Kết luận: Tin cậy qua bằng chứng, không phải lời hứa

Nhiều công ty hứa sẽ bảo vệ dữ liệu của bạn. Cách tiếp cận của chúng tôi khác: chúng tôi đã thiết kế một hệ thống mà chúng tôi thậm chí không có khả năng kỹ thuật để phá vỡ lời hứa đó. An ninh của iCanText không phụ thuộc vào sự đáng tin cậy của chúng tôi, mà vào các quy luật toán học của mật mã và một kiến trúc mà, theo thiết kế, đặt chúng tôi ra ngoài vòng tròn tin cậy của bạn.

Đây là những gì chúng tôi gọi là quyền riêng tư theo cấu trúc: một sự bảo mật mà bạn không cần phải tin vào lời nói, mà có thể xác minh thông qua chính kiến trúc của hệ thống.

Наша техническая невозможность доступа к вашим ключам: структурная гарантия

Самые важные вопросы о безопасном мессенджере: "Можете ли вы читать мои сообщения?" и "Можете ли вы передать мои ключи властям?". Для iCanText ответ — техническое и однозначное "Нет". Эта страница объясняет, почему это не обещание, а невозможность, заложенная в нашу архитектуру.

Основной принцип: Архитектура с "нулевым разглашением"

iCanText построен на принципе "нулевого разглашения" (Zero-Knowledge). Это означает, что наши серверы, которые используются только для первоначального обнаружения пиров (сигнализации), никогда и ни в какой момент не имеют доступа к вашим ключам шифрования, вашей личности, вашим контактам или содержанию ваших сообщений. Это неведение — не политика, а техническое ограничение.

Генерация ключей происходит на вашем устройстве, а не на нашем.

Когда вы впервые используете iCanText в рабочем пространстве, ваше устройство (ваш браузер) локально генерирует уникальную пару криптографических ключей. Эта пара ключей составляет вашу суверенную идентичность для этого пространства. Приватный ключ, который является абсолютным секретом, позволяющим идентифицировать вас и расшифровывать адресованные вам сообщения, **никогда не покидает ваше устройство**.

Жизненный цикл ваших ключей: два режима, одно обещание

Ваша идентичность (ваши ключи) может существовать двумя способами, в зависимости от вашего выбора. В обоих случаях они остаются вне нашей досягаемости.

1. Эфемерный режим (по умолчанию)

Если вы не установили флажок "Запомнить меня", ваша идентичность является временной. Ваши приватные ключи генерируются и хранятся только в оперативной памяти (RAM) вашего браузера. Они никогда не записываются на диск. Когда вы закрываете вкладку или браузер, эти ключи мгновенно и безвозвратно удаляются. Это цифровой эквивалент разговора, который растворяется в воздухе.

В этом режиме буквально нечего изымать, ни на наших серверах, ни на вашем устройстве после окончания сеанса.

2. Постоянный режим (опционально)

Если вы выберете "запомнить", iCanText должен сохранить ваши приватные ключи на вашем устройстве для будущих сессий. Однако они никогда не хранятся в открытом виде. Вот процесс обеспечения безопасности:

  1. Ваш пароль — это ключ: Когда вы включаете этот режим, мы запрашиваем пароль. Этот пароль **никогда** не передается по сети.
  2. Надежное получение ключа: Ваш пароль преобразуется в сложный ключ шифрования с помощью стандартного и проверенного алгоритма (PBKDF2) с большим количеством итераций. Эта операция происходит исключительно в вашем браузere.
  3. Шифрование ключей: Ключ, полученный из вашего пароля, затем используется для шифрования ваших приватных идентификационных ключей (с помощью алгоритма AES-GCM).
  4. Безопасное локальное хранилище: Только этот зашифрованный блок данных хранится в локальном хранилище вашего браузера (localStorage).

Без вашего пароля этот файл представляет собой просто блок случайных, нерасшифровываемых данных. Поскольку мы никогда не знаем ваш пароль, мы не можем его расшифровать.

Почему Say See Show, издатель, ничего не может сделать

Таким образом, наша невозможность доступа к вашим данным является структурной:

  • Мы не храним ваши приватные ключи.
  • Мы не знаем пароль, защищающий ваши локально сохраненные ключи.
  • У нас нет центральной базы данных, связывающей вашу личность с вами как с личностью.

Даже если злонамеренный сотрудник или внешнее принуждение предоставят нам полный доступ ко всей нашей инфраструктуре, они не найдут там ничего полезного, касающегося ваших ключей или сообщений.

Почему судебный запрос технически невыполним

Представим себе сценарий, в котором судебный орган предписывает нам предоставить ключи пользователя. Мы были бы технически не в состоянии выполнить этот запрос по нескольким причинам:

  • Нет базы данных пользователей: Мы не знаем, "кто" есть "кто". Идентификаторы — это криптографические ключи, не связанные с личной информацией. Мы не можем нацелиться на конкретного человека.
  • Нет центрального хранилища ключей: Нет сервера, который можно было бы изъять и который содержал бы "сокровищницу" ключей пользователей. Ключи распределены по устройствам самих пользователей.
  • Шифрование на стороне клиента: Даже если бы власти изъяли устройство пользователя, ключи, хранящиеся в постоянном режиме, остались бы зашифрованными паролем, который нам не известен.
  • Сеть P2P: Содержимое сообщений передается между пользователями, а не через наши серверы. Таким образом, на нашей инфраструктуре нет потока связи для перехвата.
Представьте, что iCanText предоставляет вам современный сейф и помогает донести его до дома. Вы — единственный человек, который создает комбинацию и запоминает ее. У нас нет дубликата ключа и копии комбинации. Мы не можем открыть ваш сейф, даже если нам прикажут.

Заключение: Доверие через доказательство, а не через обещания

Многие компании обещают защитить ваши данные. Наш подход иной: мы разработали систему, в которой у нас даже нет технической возможности нарушить это обещание. Безопасность iCanText основана не на нашей надежности, а на математических законах криптографии и на архитектуре, которая по своей сути выводит нас за пределы вашего круга доверия.

Это то, что мы называем структурной конфиденциальностью: безопасность, в которую вам не нужно верить на слово, а которую вы можете проверить через саму архитектуру системы.