#opg $OPG
Verschlüsselung klang für mich komplett, bis ich eine etwas unangenehme Frage stellte:
Verschlüsselt für wen?
Eine Nachricht kann perfekt versiegelt sein und trotzdem an die falsche Maschine geliefert werden. Wenn ich jeden öffentlichen Schlüssel akzeptiere, den ein Server mir gibt, schütze ich den Prompt während der Übertragung, ohne zu beweisen, wer ihn öffnen kann.
Das ist das Detail in OpenGradient Chat, das ich fast übersehen hätte.
Bevor chat.opengradient.ai eine private Anfrage verschlüsselt, überprüft der Client zuerst das Enklave.
Es verifiziert, dass die Hardware-Bestätigung von echter AWS Nitro-Infrastruktur stammt. Es vergleicht die PCR-Messwerte der Maschine mit dem genehmigten Build, der im TEE-Register von OpenGradient aufgezeichnet ist. Es bestätigt auch, dass der Verschlüsselungsschlüssel in dieser genauen Enklave erstellt wurde, anstatt stillschweigend außerhalb davon ausgetauscht zu werden.
Nur nachdem diese Prüfungen bestanden werden, wird der Prompt versiegelt.
Die Ordnung hat meine Denkweise über "Ende-zu-Ende-Verschlüsselung" verändert.
Verschlüsselung allein besagt, dass Außenstehende die Nachricht nicht lesen können.
Bestätigung fragt, ob der beabsichtigte Empfänger tatsächlich die Software ausführt, die er vorgibt auszuführen.
Diese zweite Frage ist wichtig, denn eine sichere Verbindung zu verändertem Code ist immer noch eine sichere Verbindung zu verändertem Code.
@OpenGradient lässt den Client das Ziel überprüfen, bevor er dem Schloss vertraut. Das SDK kümmert sich leise um die schwierigen Prüfungen, aber der Benutzer profitiert vom Ergebnis: Ein nicht genehmigter Build sollte den sensiblen Prompt überhaupt nicht erhalten.
Für mich ist das stärker als ein weiteres Schloss-Symbol.
Würdest du lieber der Verschlüsselung allein vertrauen, oder möchtest du, dass dein Gerät die Maschine überprüft, bevor es irgendetwas sendet?
Das ist die Art von versteckter Infrastruktur, die $OPG a einen echten Produktkontext gibt.
Verschlüsselung klang für mich komplett, bis ich eine etwas unangenehme Frage stellte:
Verschlüsselt für wen?
Eine Nachricht kann perfekt versiegelt sein und trotzdem an die falsche Maschine geliefert werden. Wenn ich jeden öffentlichen Schlüssel akzeptiere, den ein Server mir gibt, schütze ich den Prompt während der Übertragung, ohne zu beweisen, wer ihn öffnen kann.
Das ist das Detail in OpenGradient Chat, das ich fast übersehen hätte.
Bevor chat.opengradient.ai eine private Anfrage verschlüsselt, überprüft der Client zuerst das Enklave.
Es verifiziert, dass die Hardware-Bestätigung von echter AWS Nitro-Infrastruktur stammt. Es vergleicht die PCR-Messwerte der Maschine mit dem genehmigten Build, der im TEE-Register von OpenGradient aufgezeichnet ist. Es bestätigt auch, dass der Verschlüsselungsschlüssel in dieser genauen Enklave erstellt wurde, anstatt stillschweigend außerhalb davon ausgetauscht zu werden.
Nur nachdem diese Prüfungen bestanden werden, wird der Prompt versiegelt.
Die Ordnung hat meine Denkweise über "Ende-zu-Ende-Verschlüsselung" verändert.
Verschlüsselung allein besagt, dass Außenstehende die Nachricht nicht lesen können.
Bestätigung fragt, ob der beabsichtigte Empfänger tatsächlich die Software ausführt, die er vorgibt auszuführen.
Diese zweite Frage ist wichtig, denn eine sichere Verbindung zu verändertem Code ist immer noch eine sichere Verbindung zu verändertem Code.
@OpenGradient lässt den Client das Ziel überprüfen, bevor er dem Schloss vertraut. Das SDK kümmert sich leise um die schwierigen Prüfungen, aber der Benutzer profitiert vom Ergebnis: Ein nicht genehmigter Build sollte den sensiblen Prompt überhaupt nicht erhalten.
Für mich ist das stärker als ein weiteres Schloss-Symbol.
Würdest du lieber der Verschlüsselung allein vertrauen, oder möchtest du, dass dein Gerät die Maschine überprüft, bevor es irgendetwas sendet?
Das ist die Art von versteckter Infrastruktur, die $OPG a einen echten Produktkontext gibt.