Sunt nou în criptografie,
Da, putem vedea asta cum folosești terminologia.
Sunt nou în criptografie, încerc să proiectez un mediu pipeline securizat pentru transferul rapid de mesaje.
Un alt cuvânt pentru „conductă” este „canal”, iar transferul de mesaje este cunoscut și sub denumirea de „transport”. Deci aveți nevoie de un canal securizat pentru securitatea nivelului de transport. TLS, așa cum sugerează și numele, este doar asta.
Pentru a reduce dimensiunea cheii, intenționez să criptez mesajele cu chei de sesiune AES (pentru o sesiune sau o epocă) și în cadrul fiecărei sesiuni, plănuiesc să criptez fiecare mesaj cu chei ușoare precum DES.
Deci, conform acestui text, criptați mesajele atât cu AES, cât și cu DES? DES folosește chei de 56 de biți (deși sunt stocate de obicei în 64 de biți / 8 octeți, inclusiv biții de paritate). Deci da, cheile sunt într-adevăr „ușoare”, dar cifrul în sine cu siguranță nu este. Triple DES, oarecum sigur, este mai lent decât AES și nu este cel mai ușor cifru; în plus, necesită chei de 168/192 de biți.
Criptografii moderni își dau ochii peste cap când cuvintele „DES” sunt mormăite pentru orice protocol sau hârtie nouă. Un cifr modern (stream) ușor - așa cum se menționează în comentarii - are de obicei mult mai sens.
Dar o problemă fundamentală cu care mă confrunt este cum să fac acest canal rezistent la atacul DOS?
Deși ați putea încerca să efectuați un număr minim de operații în avans - de ex. validarea unui MAC peste un contor de mesaje - rezistența împotriva atacurilor DOS este de obicei realizată la un nivel inferior; odată ce trebuie să efectuați criptarea / decriptarea poate fi și el.
Trebuie să șterg unele mesaje sau să ofer o cronologie pentru toate mesajele din canal după care va arde, de exemplu: Time to live?
Ai putea folosi TTL.Dar TTL pare interesant în principal dacă veți redirecționa mesaje, de exemplu - și nu știm dacă protocolul dvs. este conceput pentru a face asta.
