Shadowsocks dokumentation
Navigation
FREM
FREM står for Authenticated Encryption with Associated Data. AEAD-cifre giver samtidig fortrolighed, integritet og autenticitet. De har fremragende ydeevne og strømeffektivitet på moderne hardware. Brugere bør bruge AEAD-cifre, når det er muligt.
Følgende AEAD-cifre anbefales. Kompatible Shadowsocks-implementeringer skal understøtte AEAD_CHACHA20_POLY1305. Implementeringer til enheder med hardware-AES-acceleration bør også implementere AEAD_AES_128_GCM og AEAD_AES_256_GCM.
Navn | Alias | Nøglestørrelse | Salt størrelse | Ikke størrelse | Tagstørrelse |
AEAD_CHACHA20_POLY1305 | chacha20-ietf-poly1305 | 32 | 32 | 12 | 16 |
AEAD_AES_256_GCM | aes-256-gcm | 32 | 32 | 12 | 16 |
AEAD_AES_128_GCM | aes-128-gcm | 16 | 16 | 12 | 16 |
Vær sød at henvise til IANA AEAD register til navneskema og specifikation.
Nøgleafledning
Hovednøglen kan indtastes direkte fra brugeren eller genereres fra en adgangskode.
HKDF_SHA1 er en funktion, der tager en hemmelig nøgle, et ikke-hemmeligt salt, en infostreng og producerer en undernøgle, der er kryptografisk stærk, selvom den hemmelige inputnøgle er svag.
HKDF_SHA1(nøgle, salt, info) => undernøgle
Infostrengen binder den genererede undernøgle til en specifik applikationskontekst. I vores tilfælde skal det være strengen "ss-subkey" uden anførselstegn.
Vi udleder en per-session undernøgle fra en foruddelt hovednøgle ved hjælp af HKDF_SHA1. Salt skal være unikt gennem hele den foruddelte hovednøgles levetid.
Autentificeret kryptering/dekryptering
AE_encrypt er en funktion, der tager en hemmelig nøgle, en ikke-hemmelig nonce, en besked og producerer chiffertekst og et autentificeringsmærke. Nonce skal være unik for en given nøgle i hver påkaldelse.
AE_encrypt(key, nonce, message) => (chiffertekst, tag)
AE_decrypt er en funktion, der tager en hemmelig nøgle, ikke-hemmelig nonce, chiffertekst, et autentificeringsmærke og producerer en original besked. Hvis der manipuleres med noget af inputtet, vil dekrypteringen mislykkes.
AE_decrypt(nøgle, nonce, chiffertekst, tag) => besked
TCP
En AEAD-krypteret TCP-stream starter med et tilfældigt genereret salt for at udlede per-session-undernøglen, efterfulgt af et vilkårligt antal krypterede bidder. Hver chunk har følgende struktur:
[krypteret nyttelastlængde][længdetag][krypteret nyttelast][nyttelasttag]
Nyttelastlængden er et 2-byte big-endian usigneret heltal med et loft på 0x3FFF. De højeste to bit er reserveret og skal sættes til nul. Nyttelast er derfor begrænset til 16*1024 – 1 bytes.
Den første AEAD kryptering/dekryptering operation bruger en tælle nonce startende fra 0. Efter hver kryptering/dekryptering operation øges nonce med én, som om det var et usigneret lille endian heltal. Bemærk, at hver TCP-chunk involverer to AEAD-krypterings-/dekrypteringsoperationer: en for nyttelastlængden og en for nyttelasten. Derfor øger hver del nonce to gange.
TCP
En AEAD-krypteret TCP-stream starter med et tilfældigt genereret salt for at udlede per-session-undernøglen, efterfulgt af et vilkårligt antal krypterede bidder. Hver chunk har følgende struktur:
[krypteret nyttelastlængde][længdetag][krypteret nyttelast][nyttelasttag]
Nyttelastlængden er et 2-byte big-endian usigneret heltal med et loft på 0x3FFF. De højeste to bit er reserveret og skal sættes til nul. Nyttelast er derfor begrænset til 16*1024 – 1 bytes.
Den første AEAD kryptering/dekryptering operation bruger en tælle nonce startende fra 0. Efter hver kryptering/dekryptering operation øges nonce med én, som om det var et usigneret lille endian heltal. Bemærk, at hver TCP-chunk involverer to AEAD-krypterings-/dekrypteringsoperationer: en for nyttelastlængden og en for nyttelasten. Derfor øger hver del nonce to gange.
