Newsgroup: it.comp.sicurezza.varie
Titolo: Algoritmo Hardwareabile

Ciao...
Qualcuno saprebbe indicarmi un algoritmo per crittografia, anche non molto
sicuro,
ma abbastanza semplice da poter essere realizzato in harwdware con
componenti
standard, cioe' porte e flipflop? Inoltre dovrebbe lavorare su singole word
e non
su blocchi, cioe' in modo stream.
Grazie, ciao
Luigi

su blocchi, cioe' in modo stream.
Il DES e' stato realizzato apposta per essere realizzato facilmente in
hardware (Xor, shift e incroci di bit). Se non ti interessa la
sicurezza lavori con password da 64 bit (56+8 di parita'), altrimenti
vai sui 128 bit.
Ciao
							Max
Massimo Sanna                               \
E-mail: 
s78...@athena.polito.it
              \
 
fdr...@cclinf.polito.it
              \
ICQ:    20157773                               \
Home:   
http://www.poli.studenti.to.it/~m.sanna
 \	
-------------------------------------------------
"Vedi Bongo, questo e' il progresso! Hai tutto quello che non vuoi, quando non ti serve". 
                                              A. De Curtis
                ------
               | STOP | <-  "CLICK HERE TO SHUTDOWN"
                ------

E' facilissimo: all'uscita dati della eprom che usi per memorizzare le
parole devi implementare la somma esclusiva (XOR) bit per bit di un byte
chiave .. (o piu' di uno in cascata) .. nella decodifica lo stesso circuito
ma con i componenti rovesciati.
   Gli unici flip flop che ti servono sono quelli del full-addler per il
riporto necessari solo per un bit iniziale (o finale) .. con lo XOR??
ebbene si .. c'e' un problema tecnico inerente alla cosa.. te ne accorgi
quando fai lo schema.
 [l'algoritmo con le porte] e' tanto piu sicuro quante chiavi in cascata
metti .. ma gia' con tre o quattro diventa veramente difficile scoprire il
sistema che hai usato.
  ( sempre che tu lavori su parole .. e non bit per bit ovviamente!!! )
   .. se ti resta difficile guardo di farti nei prossimi giorni uno schema
elettrico d'esempio...
 cmq ci sono componenti semicustom della Irix o anche Texas che gia lo fanno
con chiavi multiple .. e costano poche decine di lire l'uno!

sistema che hai usato.
Master, sull'hardware non dico niente, ma fare
	((A XOR B) XOR C) XOR D) ...
equivale a fare
	A XOR (B XOR C XOR D ...)
e quindi, che tu usi una porta o diecimila, il risultato non cambia.
La sicurezza e' sempre la stessa - e si decodifica al massimo in 255
tentativi :-)
Piuttosto, non e' troppo complicato mettere su un piccolo DES usando
le desbox su, credo, 
www.eff.org
. Oppure, se uno usa una EEPROM, usa
l'intera EEPROM come chiave OTP. Finche' non ti fregano la EEPROM, o
la riutilizzi, la cifratura e' inviolabile :-)
Leonardo
".signature": bad command or file name


Potresti darmi qualche sigla?
Grazie ciao.
Luigi

la riutilizzi, la cifratura e' inviolabile :-)
Nel mio caso i tempi mi impediscono di usare memorie (E)EPROM...
forse ci sono delle RAM con tempo di accesso <5nS ma preferirei
farne a meno, se possibile.
Ciao
Luigi

 tentativi :-)
No, perche' "A", "B" e "C" non sono "byte" ma stringhe, fatte ruotare
di un byte a ogni ciclo, e il "periodo" dell'algoritmo se le lunghezze
di queste stringhe sono prime fra loro e' pari a len(A)*len(B)*len(C)...
invece che a quello di una sola "chiave".
Esempio:
unsigned char LameCrypt(unsigned char ch) {
  static char k1[] = "KeyWorkd123"; /* 17 Byte, primo */
  static char k2[] = "AssolutamenteSegretaYeppaYeah"; /* 29 Byte, primo */
  static char k3[] = "NonTeLaDicoMancoMortoStramazzatoAlSuoloMAInoNoN";
                    /* 47 byte, come sopra */
  static char *x1 = k1, *x2 = k2, *x3 = k3;
  if (*x1++ == '\0') x1 = k1;
  if (*x2++ == '\0') x2 = k2;
  if (*x3++ == '\0') x3 = k3;
  return (ch ^ *x1 ^ *x2 ^*x3);
  };
Equivale a un brutale XOR con una stringa lunga 17*29*47 = 23171 byte.
Considerato che implementare "un passo" (ovvero lo xor con una stringa)
di questa funzione in hardware richiede:
- Un contatore
- Una PROM/ROM/EPROM abbastanza veloce da sputare fuori i byte alla
  stessa velocita' del blocco da crittare
- Tante porte XOR quanti sono i bit della nostra "parola"
Ovvero per lavorare in "seriale" questo significa che possiamo
implementare facilmente questo encoder hardware con:
- Un contatore (con un circuito di sincronismo che lo tenga
  in linea con la seriale).
- Una PROM/EPROM/ROM di 1xN, dove N e' il numero di bit della chiave
  (che puo' facilmente essere qualche migliaio) in grado di essere letta
  in un tempo 1/B dove B e' il bit-rate della nostra porta.
- Una porta XOR
Se di questi "cosi" ne mettiamo 5 "in serie", usando chiavi con
un numero di bit diverso e sempre "numero primo" di diciamo 8-10mila
bit... abbiamo un "periodo" del crypter di 
10000 ** 5 = 100000000000000000000 di bit (non so come leggerlo :-)
Il decodificatore inoltre e' esattamente identico al codificatore
(basta che sia composto degli stessi "stadi" con la stessa lunghezza
di chiavi e aventi la stessa chiave, in qualsiasi ordine siano gli 
stadi il risultato e' lo stesso).
Se le chiavi sono random (di quelle DAVVERO random) un attacco brute
force e' quasi impossibile (= difficile), e' comunque possibile 
(= facile) scoprire come decrittare i primi "n" byte di una sequenza
avendo la possibilita' di fare un attacco "feed in - see out"
(basta spararci dentro una sequenza di zeri... ).
Per questo, non capendo il tipo di applicazione che deve farne
Luis non mi sono permesso di suggerire questa soluzione: e' comunque
attaccabile in modo abbastanza semplice con determinate premesse
e comunque ha dei problemini implementativi non da poco (basta
MOLTO poco e uno degli stadi va fuori sequenza, e si puo' reinstaurare
la comunicazione solo con un bel reset del tutto).
Ciao,
-- 
Andrea

 farne a meno, se possibile.
Parlando di "bit" e per ordini di grandezza ragionevoli:
PROM = Contatore Johnson con alcune uscite connesse e altre no :)
Riprendendo il mio post precedente:
Uno stadio fatto con un JC a 10-50 uscite (sempre primi e sempre
diversi tra loro), 10 stadi in serie ==> Il periodo del pattern
usato per lo "XOR" e' di 11*13*17*19*23... == Molto grande.
Nota che il periodo di propagazione tra ingresso e uscita
per N stadi, se le porte XOR sono messe in modo inteligente,
e' pari a log2(N)X+Y dove N e' il numero degli stadi, X il
tempo di propagazione di ua porta XOR e Y il tempo di 
aggiornamento dei contatori (che sono attivati in parallelo
dallo stesso clock, quindi contane uno solo).
Ovviamente e ancora: dipende dall'applicazione, non ci farei
una chiave hardware per un programma o una trasmissione via 
etere della linea di uno sportello Bancomat :)
Ciao,
-- 
Andrea

semplicemente ridicola.
   Stiamo sullo stesso pianeta? ;-)  .. base luna chiama terra. base luna
chiama terra..
 Se intendevo fare lo xor di una costante il full-adler cosa ci sta a fare?
 mi sono spiegato male io?? .. mah .. non mi sembrava ..
  cmq ..gia' ti avevo detto che ci sono integrati che fanno lo XOR di chiavi
.. algoritmo
valido esattamente come il DES se non migliore forse .. dipende dai punti di
vista e dai
metodi applicativi.
  La texas ne fa di spettacolari .. nel senso che costano 10 lire l'uno! o
forse meno.
  Se vuoi la sicurezza .. c'e' un integrato che genera un numero a piacere
di chiavi sulla
base di un algoritmo che crea numeri random secondo uno schema che a
tutt'oggi non mi
spiego .. infatti lasciato lavorare per oltre una 10 giorni questo produce
un serie di numeri
casuali .. VERAMENTE casuali .. nel senso che non ho trovato in 240 giorni
un punto di
ripetizione.  Si chiama TX 3148-sc-B  ed e' quello che viene oggi
maggiormente usato per
le chiavi hardware (professionali) da mettere come protezione ai programmi.
  Se poi vuoi un circuito solo porte che lo fa .. senza startelo a postare
..su 'Elettronica digitale' ..della Jackson .. spiega come fare con gli
esempietti..
  Per dire la verita su praticamente TUTTI i libri di elettronica digitale
ci trovi un esempio che fa al caso tuo! .. e' un caso standard ..le
codifiche si fanno di regola.. non tanto per la sicurezza quanto per
adattare un certo tipo di dati alle proprie esigenze d'uscita.
ps:
   .. non vuoi usare le RAM ?? .. perche'??  la tua religione non te lo
permette? .. hi hi hi

> ((A XOR B) XOR C) XOR D) ...
 ;-)) ..eh no!! quello che dici tu e bit su bit di un bit!
    io dico funzione di bit per bit di un byte o piu' se la parola e' piu'
lunga!!
  mi sembra un pochettino abbastanza parecchio di molto diverso.
    black hacker ha pubblicato anche un giusto programmino .. io sono stato
piu' abulico
   nella definizione!

10000 ** 5 = 100000000000000000000 di bit (non so come leggerlo :-)
"un mostrilione" ;-)



La mia religione e' evitare le complicazioni, e ho l'impressione
che una RAM mi complicherebbe molto le cose: dove trovo RAM da 5 nS?
Oltretutto dual-port, se voglio scriverla senza dover aggiungere
dei multiplexer che allungherebbero troppo i tempi di propagazione...
E se la trovassi, ho l'impressione che da sola costerebbe piu' di
tutto il resto. Quindi, niente RAM!
Al limite, PROM bipolari, se proprio non posso farne a meno.
Luigi

Al limite, PROM bipolari, se proprio non posso farne a meno.
  Ma sul costo delle ram non sono d'accordo .. poi dipende ovviamente da
quante te ne servono .. ma devi fare una produzione in serie?.. sul fatto
che siano un attimo piu' difficili da gestire magari si.. cmq ci sono della
C-RAM gia' interfacciate con tutto che praticamente usi come delle ram-card
.. l'unica cosa che devi immettere sono i dati, un po' di corrente, e
chiaramente il segnale scrivo/leggo.
 Sulla velocita' devo controllare.. non sono sicuro! .. ma poi scusa ..
 non ce l'hai l'IC master??.. controlla su quello .. altrimenti compralo ..
per queste cose e' un toccasana!

 sicuro,
un XOR!
-- 
(o-  ________________________________________________________________
//\  Luca Di Taranto                             dita...@zappami.tin
V_/_ to email me, please, remove "zappami" and add ".it" after ".tin"