Quale sarebbe la dimensione della chiave per un'immagine usata come chiave?

La modifica più recente indica che le immagini sono generate in modo procedurale, pertanto le dimensioni della chiave saranno limitate dalla quantità di stato richiesta per generare un'immagine. Il tuo sembra essere parametrizzato da quattro float per le condizioni iniziali (e immagine di output fissa dimensioni, posizione della telecamera, posizione della luce puntiforme, condizioni di convergenza, ecc.)

Questi 128 bit di stato verranno quindi trasformati in un'immagine da un algoritmo che dipende esclusivamente dallo stato fornito, quindi la "chiave" dell'immagine non può contenere più di 128 bit di informazioni. In effetti, penso che intere classi di valori iniziali producano output identici (ad esempio quando tutti e quattro i float sono estremamente piccoli), quindi la dimensione della "chiave" dell'immagine sarà strettamente inferiore a 128 bit.

Non c'è davvero alcun vantaggio nel toccare i 128 bit di stato trasformandolo in un'immagine (e quindi in qualche modo indietro) se si riduce la dimensione della chiave solo facendo così.

Un'immagine è troppo grande per essere utilizzata direttamente come chiave di crittografia, ti consigliamo di eseguirla attraverso una KDF prima.

Dipende anche interamente dall'immagine se avrà abbastanza entropia per essere utile. Potresti avere un'immagine 1000x1000 bianca, ma sarebbe inutile come chiave in quanto non contiene entropia. Le immagini delle fotocamere tendono ad avere una buona quantità di entropia nei bit più bassi, quindi potrebbe essere ok, ma i tuoi utenti dovrebbero capire che non ogni immagine è una buona chiave.

Le immagini come chiavi in generale non sono una grande idea. Le immagini sono solitamente prese per essere condivise e le chiavi sono qualcosa che non vuoi mostrare a tutti. Anche l'uso di un'immagine come chiave mi sembra possa basarsi su sicurezza attraverso l'oscurità (ovvero usi solo un'immagine dalle migliaia che hai sul tuo computer, ma è effettivamente un'entropia molto bassa, probabilmente con meno di 20 bit a meno che tu non abbia un numero folle di immagini).

Sentiti libero di continuare a svilupparlo per amore dell'apprendimento, ma finché non avrai una conoscenza molto migliore della crittografia è meglio lasciare questo tipo di cose agli esperti (vedi Perché non dovremmo lanciare da soli? ).

Qualsiasi criptosistema dovrebbe avere chiavi con keysizes a 128, 192 e 256 bit-of-entropy livelli di sicurezza.

Quindi la domanda ti viene in mente: da dove provengono queste immagini e quanta entropia contengono? Se sono flussi di bit completamente casuali che vengono interpretati come un'immagine, quindi (ignorando la perdita di entropia dai codec di compressione lossy), ottieni log_base2(256x256x256) = 24 bits of entropy per pixel , quindi avresti bisogno rispettivamente di 6/8/11 pixel per 128/192 / Forza di sicurezza a 256 bit.

Se non stai generando immagini completamente casuali e invece permetti alle persone di usare, come, foto, allora non ho idea di come tu possa iniziare a stimare la quantità di entropia in una di quelle.

In conclusione: utilizzare le immagini come materiale chiave sembra una cosa davvero strana da fare e contrasta con la pratica comune che i materiali chiave siano dati completamente casuali da un RNG di forza crittografica.

Inoltre, dalle informazioni nella tua domanda, non sono convinto che la forza bruta sia l'attacco di cui devi preoccuparti; Sarei più preoccupato per l'attacco "accedi al loro laptop e prova ogni immagine sul loro disco rigido"

Dalle immagini posso capire che la dimensione della tua chiave è significativamente inferiore alla dimensione delle immagini (perché altrimenti la maggior parte di esse apparirebbe come una statica colorata casuale).

La tua dimensione della chiave è inferiore o uguale al logaritmo di base 2 del numero totale di immagini diverse che il tuo programma di attrattore caotico può generare. *

Questo è un altro modo per dire che la tua dimensione della chiave è minore o uguale (probabilmente inferiore) della quantità di bit necessaria per specificare tutti gli input del tuo programma caotico attrattore.

Se hai cancellato l'immagine e usi l'hash come chiave crittografica, la tua dimensione della chiave è uguale o inferiore alla dimensione dell'hash.

* Questa è la tua esatta dimensione della chiave se il tuo algoritmo di crittografia è qualcosa come "XOR ogni bit dell'immagine con il bit corrispondente del testo in chiaro" (non usare quell'algoritmo per importanti segreti, perché alcune parti del messaggio sono coperte dalle aree grigie delle tue immagini potrebbe essere facilissimo decifrare).

tl; dr - stai proponendo un algoritmo di allungamento della chiave che trasforma 128 bit di input in una chiave molto più grande. Questo non è buono come semplicemente usando una chiave molto più grande della stessa dimensione, anche se non è necessariamente debole come i 128 bit di input. Detto questo, la tua bitmap sembra molto ordinata, il che suggerisce strongmente che è molto più debole di una bitmap generata casualmente.

In base alla risposta di Blender , stai utilizzando solo 128 bit per generare l'immagine. Immagino che tu voglia che l'immagine stessa contenga una chiave più grande dei 128 bit che hai inserito nell'algoritmo che l'ha generata. E potrebbe .

In particolare, quello che stai cercando di fare è creare un algoritmo di allungamento della chiave che tenti di estendere 128 bit di inserire in una chiave molto più grande. Questo non è necessariamente infruttuoso, ma ci sono cose di cui essere a conoscenza:

1. Un algoritmo di allungamento della chiave può essere vulnerabile alla forza bruta dell'input. Ad esempio, anche se qualcuno non fosse in grado di decodificare l'algoritmo di generazione di immagini, potrebbe provare tutti i possibili input $ 2 ^ {128} $ per generare tutte le possibili $ 2 ^ {128} $ di immagini possibili, quindi provare ciascuna. Per evitare questo, è necessario assicurarsi che l'algoritmo di generazione di immagini sia troppo costoso per un tale attacco sia fattibile.

2. L'immagine sembra lontana dalle scale locali a caso. Cioè, chiunque ne guardi alcuni pixel può probabilmente indovinare i pixel vicini con probabilità di successo migliori del random. Ciò significa che l'algoritmo non è pseudo-casuale, anche contro un utente malintenzionato che non può decodificare l'algoritmo di generazione di immagini.

3. La tua immagine sembra lontana dalla casualità su scala globale. Questo è, le forme visualizzate hanno geometria globale, più le immagini sprecano pixel su uno sfondo ben educato. Ciò indebolisce significativamente la pseudo-casualità di nuovo, suggerendo potenzialmente che potrebbe essere facile da interrompere completamente.

4. Non c'è alcun vantaggio reale in un algoritmo di allungamento chiave che produce un'immagine rispetto a qualsiasi altra rappresentazione degli stessi dati. Certo, la chiave allungata sembra carina come un'immagine, ma quella bellezza riflette semplicemente la sua debolezza rispetto a una bitmap generata casualmente.

Questo sito sembra generare bitmap in bianco e nero casuali con dimensioni specificate. Ad esempio, ecco una bitmap $ 250 \ times 250 $ -pixel:
.
Questa bitmap è (dovrebbe essere) casuale in quanto un attaccante che osserva una qualsiasi combinazione dei suoi pixel non dovrebbe avere una migliore più o meno probabilità di indovinare quale potrebbe essere un altro pixel.

Quanta entropia?

Sfortunatamente questo sito non ha MathJax abilitato, quindi è difficile rispondere direttamente alla tua domanda senza sembrare strana. Qui scriverò una risposta come se MathJax fosse disponibile.

L'insieme di immagini RGB generate casualmente di una data lunghezza e larghezza contiene $$ {\ left (n_ \ text {Red} \, n_ \ text {Green} \, n_ \ text {Blue} \ right) } ^ {n_ \ text {width} \, n_ \ text {height}} \, \ text {members} \ , $$ dove:

• $ n_ \ text {Red} $ è il numero di valori possibili per la dimensione " rosso " di un pixel;

• $ n_ \ text {Verde} $ è il numero di valori possibili per la dimensione " verde " di un pixel;

• $ n_ \ text {Blue} $ è il numero di valori possibili per la dimensione " blu " di un pixel;

• $ n_ \ text {width} $ è il numero di pixel nella larghezza; e

• $ n_ \ text {length} $ è il numero di pixel nella lunghezza.

Allora poiché entropy è $ \ log_2 {\ left (n_ \ text {members} \ right)}, $ this'd be $$ \ Begin {align} \ left [\ text {entropy} \ right] & ~ = ~ \ log_2 {\ left ( {\ left (n_ \ testo {rosso} \, n_ \ testo {verde} \, n_ \ testo {blu} \ destra)} ^ {n_ \ text {width} \, n_ \ text {height}} \ right)} \ [5px] & ~ = ~ {n_ \ text {larghezza} \, n_ \ testo {altezza}} \, \ log_2 {\ sinistra (n_ \ testo {rosso} \, n_ \ testo {verde} \, n_ \ testo {blu} \ destra)} \. \ End {align} $$

Nel caso di un'immagine in bianco e nero:

• $ n_ \ text {rosso} = 2, $ poiché ci sono due possibili valori per il canale rosso;

• $ n_ \ testo {verde} = n_ \ testo {blu} = 1, $ poiché i valori dei canali verde e blu sono definiti per uguagliare il canale rosso (in modo tale che tutti i pixel siano neri o bianchi ;

quindi l'entropia sarà $$ \ left [\ text {entropy} \ right] ~ = ~ {n_ \ text {width} \, n_ \ text {height}} \, \ log_2 {\ left (2 \ times 1 \ times 1 \ right)} ~ = ~ {n_ \ text {width} \, n_ \ text {height}} \ ,. $$

Quindi, se riesci a superare i problemi iniziali implicati in troppe chiavi e troppe perdite, e utilizzare KDF dopo, c'è un vantaggio nell'usare queste chiavi per l'autenticazione dopotutto.

La generazione di quella roba deve durare per sempre in relazione a un hash tradizionale, quindi se i parametri iniziali sono trattati come una password, i tempi di attacco della password saranno lenti.

Ma ci sono modi più semplici per farlo. bcrypt() e gli amici scalano bene.