Armando47: Difference between revisions
No edit summary |
No edit summary |
||
| Line 28: | Line 28: | ||
**http://axtls.sourceforge.net/ | **http://axtls.sourceforge.net/ | ||
la latenza minima e' data dal blocco di crittazione (16bytes) | la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes). | ||
questo e' tendenzialmente male. d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (128bit, se si usano input ''k'' di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma: | anche la granularita della protezione di errore FEC e' data dal blocco di crittazione (16bytes): e' inutile tentare di preservare l'integrita di blocchi di dati piu piccoli di 128bit, il danneggiamento anche di un solo bit si ripercuoterebbe sul contenuto di tutto il blocco di crittazione. | ||
se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri. | |||
questo e' tendenzialmente male pensando all'uso con messaggi di testo, i linguaggi naturali hanno una loro ridondanza a livello di parola considerevole. per applicazioni non di testo questo vantaggio non esiste, anche se per messaggi molto piu piccoli di 16byte l'overhead dato dal padding e' comunque considerevole. | |||
d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (128bit, se si usano input ''k'' di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma: | |||
# crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco. | # crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco. | ||
# dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard. | # dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard. | ||
alla luce di questo forse ha senso considerare dei block codes diversi da quello di Hadamrd, che e' non-ottimale per ''k'' maggiore di 7. | |||
la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile. | |||
la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi: | la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi: | ||
Revision as of 15:28, 13 June 2012
Device crittografico tascabile
device piccolo ed economico per lo scambio di messagi di testo cifrati su canali audio.
externals
- lcd (grafico? 4x20 caratteri)
- keypad 4x3
- jack audio in
- jack audio out
- ptt
- mini-usb ?
internals
- processore: dspic33fj128gp802
- codifica audio: MFSK
- Sincronizzazione simbolo: TBD
- FEC: Hadamard code
- algoritmo di cifratura: AES-256
la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes).
anche la granularita della protezione di errore FEC e' data dal blocco di crittazione (16bytes): e' inutile tentare di preservare l'integrita di blocchi di dati piu piccoli di 128bit, il danneggiamento anche di un solo bit si ripercuoterebbe sul contenuto di tutto il blocco di crittazione.
se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri.
questo e' tendenzialmente male pensando all'uso con messaggi di testo, i linguaggi naturali hanno una loro ridondanza a livello di parola considerevole. per applicazioni non di testo questo vantaggio non esiste, anche se per messaggi molto piu piccoli di 16byte l'overhead dato dal padding e' comunque considerevole.
d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (128bit, se si usano input k di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma:
- crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco.
- dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard.
alla luce di questo forse ha senso considerare dei block codes diversi da quello di Hadamrd, che e' non-ottimale per k maggiore di 7. la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile.
la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi:
- 2^(8-1) * 16 = 2048 bit nel caso di FEC con input a 8 bit.
- (2 * 2^(4-1)) * 16 = 256 bit nel caso di FEC con input a 4 bit (ogni carattere 2 input).
prendendo il secondo caso, con un alfabeto di 16 toni per simbolo, quindi 4 bit, la latenza sarebbe di 64 simboli, che a 32 simboli per secondo farebbe 2 secondi per 16 caratteri.