Newsgroup: it.comp.sicurezza.varie
Titolo: criptare pochi byte

esistono tecniche per criptare in modo decentemente sicuro un gruppo di
byte molto limitato, dell'ordine degli 8 o 16 byte?
8 byte in chiaro <----> [black box] <----> 8 byte criptati
il numero di byte criptati deve essere uguale a quelli non criptati e
dovrebbe essere possibile decriptare un singolo byte del gruppo alla
volta.
tanto per informarsi prima di inventarsi un qualche improbabiule
algoritmo.
ciao
-- 
Seti@Home Java Applets
http://maruko.webhop.net/

 alla volta.
Uh ... XOR ? In pratica crei una stringa (chiave) della stessa lunghezza
del buffer da criptare e poi metti in XOR i bytes del buffer con quelli
della chiave, a quel punto puoi volendo decriptare uno qualsiasi dei
bytes senza dover decriptare gli altri. L'algo di XOR non è esattamente
solidissimo ma visto che i dati hanno una dimensione limitata, usando
una chiave della stessa lunghezza dei dati avrai una sicurezza decente
Ciao

 possibile decriptare un singolo byte del gruppo alla volta.
genera un file "chiave" di lunghezza pari a quella del file da crittare e
contenente dati random poi metti in xor sorgente e chiave. e' importante
che i dati nella chiave siano realmente casuali e per questo ti rimango a
ng che trattano crittografia per avere suggerimenti su come ottenere
sequenze ad elevata entropia.
per decrittare una singola porzione del file ti basta fare lo xor tra le
corrispondenti locazioni di chiave e file crittato.
la sicurezza e' assoluta sempre che la chiave non venga persa o non venga
usata per crittare piu' file nel qual caso sarebbe (in teoria) possibile
un attacco per ricavare almeno parte della chiave ( == parte dei file
originali!)
googla "one time pad" per altre informazioni
-- 
a torino siamo piu' fighi: i nostri cantieri sono eventi culturali, mica
dei semplici buchi polverosi da cui esce un rumore assordante!
http://www.comune.torino.it/cantieri/manuale/index.htm

algoritmo.
Servono un po' di informazioni. Per esempio, la stazione trasmittente
e quella ricevente sono sicure? Sono connesse in tempo reale? C'e' un
solo ricevente, o un solo trasmittente, o e' molti-a-molti?
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

piu' info:
il file di pochi byte e' una sorta di ticket che viene assegnato a N
client. In esso ci sono delle informazioni che permettono ai client di
accedere a determinati servizi. Quindi, l'obiettivo e' impedire che il
client capisca cosa alterare nel file in modo da ottenere un determinato
servizio.
Il file viene inviato ai client gia' criptato e quindi non ci sono
problemi sulla sicurezza della trasmissione. Il mio nemico e' il client
non uno nel mezzo.
Le info devono risiedere sul ticket per forza, se non fosse cosi' non
avrei il problema. Inoltre, potrebbe essere impossibile incrociare i
dati dell'utilizzo del ticket con un database in realtime e questo, a
mio avviso, e' il punto piu' debole in quanto impone di credere che il
file inviato dal client sia integro. Da qui la necessita' di rendergli
perlomeno la cosa difficile.
Io avevo pensato si' ad uno XOR ma con qualche rotazione/swap sulla
chiave (oppure una chiave diversa per ogni client) in modo da impedire
che il confronto tra N ticket porti all'individuazione di eventuali aree
del file costanti.


 determinato servizio.
Beh, problema gia' risolto, mi pare, dall'autenticazione digest.
Una parte della chiave e' un hash di un identificativo del client (ip o
altro), l'altra un numero random.
Incrociato con un database dovrebbe garantirti una buona sicurezza.
Occhio ad invalidare correttamente il ticket!
-- 
HappyCactus - Linux User #209744 - 
http://pngstego.sourceforge.net
 
 
www.google.com
 - 
groups.google.com
/* Ci sono 10 categorie di persone al mondo: quelle che capiscono */
/* il sistema binario e quelle che non lo capiscono.              */

servizio.
E' possibile ingrassare il file? Per esempio 24 byte invece di 8? In
questo modo potresti mettere:
	[  8 byte flag   ]
	[ 16 byte MD5    ]
Gli 8 byte flag possono anche essere mandati in chiaro, il server fa
un controllo se 8 byte flag + 16 byte secret danno 16 byte MD5.
Se riescono a sfondare un MD5, si puo' pensare a uno SHA-160.


 Se riescono a sfondare un MD5, si puo' pensare a uno SHA-160.
Beh .. MD5 potrebbe essere criptato insieme con il resto del file
cosě "sfondarlo" dovrebbe essere un'attimo piů difficile, inoltre per
quanto riguarda la chiave di codifica per lo XOR potresti generare
un digest (SHA-1 o quant'altro) dei dati del cliente ed usarlo come
chiave di codifica/decodifica del ticket
Ciao
-- 
* ObiWan
DNS "fail-safe" for Windows 2000 and 9X clients.
http://ntcanuck.com
408 XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm

questo modo potresti mettere:
purtroppo no.


purtroppo no.
Puoi fornire i dettagli di come sono fatti quegli otto byte?


Puoi fornire i dettagli di come sono fatti quegli otto byte?
in che senso? cerchi forse delle sequenze di bit?
i dettagli non li so ancora. lo spazio a disposizione e' quello, i dati
che ci vanno dentro non li ho ancora definiti, probabilmente ci sara' un
qualche id che identifica il servizio e magari un campo che determina la
scadenza del ticket....


 >purtroppo no.
Hmmm ... è per caso un "badge" o "qualcosa di simile" ;-) ??


wrote:

bingo.
la difficolta' sta nel fatto che potrebbe non esserci la connessione con
un db e quindi il ticket dovrebbe "funzionare" anche standalone.
Mi rendo conto che non esiste un sistema infallibile e mi accontento di
rendere le cose almeno difficili.


 accontento di rendere le cose almeno difficili.
beh, seguendo il discorso di cui sopra... supponiamo di memorizzare
nel badge soltanto un "digest" univoco, a quel punto tutto il resto delle
info verranno ricavate dal DB usando come chiave di accesso quella
memorizzata sul badge stesso ... uh .. potrei dire fesserie, ma siccome
non ho chiara la situazione (tutti gli estremi) ..


non ho chiara la situazione (tutti gli estremi) ..
il badge deve dire di se' quello che non posso reperire dal db (facciamo
finta che il db non ci sia). qui il motivo della criptazione, devo
rendere difficile che qualcuno faccia dire al badge qualcosa che in
origine non diceva.
piu' precisamente utilizzo tag RFID, chip di prossimita', chiamali come
vuoi. Hanno un codice univoco inalterabile e una memoria limitata
(dipende dal modello). I blocchi possono essere letti, scritti e messi
in sola lettura.
Leggo delle info dal tag, le processo e le aggiorno sul tag. Se le
leggessi e basta mi basterebbe mettere le info in sola lettura. Se
avessi piu' spazio mi basterebbe separare le info statiche da quelle
dinamiche, purtroppo su cosi' pochi byte devo mixarle per ottimizzare lo
spazio e tutti i byte devono rimanere in lettura e scrittura.
Quindi la situazione e' analoga a qualla che avrei usando un file, ecco
perche' ho omesso tutti questi dettagli.
facendo xor con chiave variabile da tag a tag e magari variabile anche
dopo ogni operazione probabilmente riuscirei ad ottenere qualche
risultato. Sempre che non esistano tecniche specifiche per queste
casistiche, ma non sembra.


 casistiche, ma non sembra.
Si, direi chiave variabile (una per tag) della stessa lunghezza del
buffer dati (8 bytes in questo caso) e composta da dati random
in questo caso avresti "quasi" un OTP e visto che la key avrà una
lunghezza pari a quella dei dati usando XOR non dovresti avere
enormi problemi di sicurezza .. anche se in teoria uno potrebbe
leggere il contenuto del TAG, farlo passare sul tuo lettore e poi
ripristinare il contenuto precedente ... il che è difficilmente solubile
dato che se uno ripristina un precedente contenuto valido...


lo so :-(
cerchero' di poter permettermi di mettere blocchi in sola lettura....


 cerchero' di poter permettermi di mettere blocchi in sola lettura....
Beh .. se hai "dietro" un database potresti semplicemente scrivere
nel database l'ultima "stringa valida" per quel TAG, a questo punto
se un ripristina il contenuto precedente il TAG non sarà più valido...


scadenza del ticket....
Okay. Allora facciamo cosi'.
Ogni blocco di byte e' associato ad una ulteriore chiave univoca, che e'
l'indirizzamento dell'unita' (sono 64 bit, mi pare?).
Si prende quel blocco, si unisce ad un secret, se ne fa l'MD5... ed ecco
che hai una crypto key di 128 bit da usare come XOR per il buffer.
Con questo, due chiavi con uguali dati, avranno pero' contenuto "fisico"
diverso.
===
Rimane il problema di fare in modo che la stessa chiave, cambiando anche
solo un bit, cambi potentemente il proprio contenuto.
Divido gli otto byte in due gruppi di quattro che chiamo A e B:
[A][B]
Definisco <A,B> come "lo XOR di B con gli ultimi 4 byte del MD5 ottenuto
da A". In PHP,
		$c = xor(b, md5(a));
Vale quindi:
	B = <A, B> XOR MD5(A)
La mia stringa criptata e'
[ A XOR <A,B> ][ <A, B> ]
Per decifrare la stringa
[ C ][ D ]
calcolo innanzitutto C XOR D... questo e' A XOR <A,B> XOR <A,B> e dunque
e' A. Avendo A, ho md5(A), mentre D e' <A, B>. Quindi
	B = D XOR MD5(C XOR D)
Avendo sia A che B, ho la mia stringa originaria. Cambiando un bit, ogni
altro bit dovrebbe cambiare con una probabilita' del 50%.
Oppure mi sono fumato l'impossibile e non funziona un caz - ma questo fa
parte dei rischi di chi mi sta a da' retta. Io prove unn'ho fatte.
===
Infine mi rimane il problema del replay attack. Che succede se uno legge
la mia chiave, la salva su una memoria separata, poi dopo che io ho dato
il via al trituramento della chiave la ripristina dal backup rifacendole
una verginita'?
L'unica speranza e' che il lettore disponga di una memoria oppure che il
troskino disponga di un contatore di scritture.
Leonardo
-- 
Tre cose sono da temere nel campo I.T.:
Un sysadmin con un cacciavite in tasca;
Un amministratore con un libro in mano;
Un utente con una grande idea in testa.

parte dei rischi di chi mi sta a da' retta. Io prove unn'ho fatte.
ho metabolizzato e ricontrollato, dovrebbe andare...
post in keep per quando ne avro' bisogno.
grazie
