Pages:
Author

Topic: brainwallets da password (Read 3769 times)

legendary
Activity: 1948
Merit: 2097
October 29, 2016, 11:24:12 AM
#46
Dunque se ricordo bene nei logaritmi discreti si usa un "adattamento" dell'algoritmo che individua un gruppo ciclico
relativo ad una certa base modulare.... non e' uguale all'algoritmo usato per la fattorizzazione, ma il nocciolo
e' sempre l'individuazione di un gruppo ciclico, cosa che permette di evitare la memorizzazione degli elementi gia' setacciati...

Allora, riguardando bene:
nella scelta dei parametri a' e b' necessari per passare da un elemento

                                   Y = aP + bQ  al successivo elemento Y'= a'P + b'Q

si usa effettivamente una specie di quadrato (ogni elemento Y viene raddoppiato in Y+Y=2Y , almeno se si trova in una certa parte dello spazio, il che equivale ad elevare alla seconda). La scelta dei parametri (a',b')  è ovviamente deterministica ma soprattutto dipende solo dai valori (a,b) dell'elemento precedente.

Quindi si simula solo la classica passeggiata casuale nello spazio di tutti gli elementi della curva.  

Si può quindi non tenere traccia di tutti gli elementi Y=aP+bQ generati poichè si sa che a un certo punto si deve entrare in un "sottogruppo" ciclico della curva ellittica (la parte chiusa della lettera rho, anche se non è propriamente un sottogruppo nel senso matematico del termine; non appena si genera una collisione gli elementi per forza iniziano a ripetersi a causa del modo univoco con cui viene generato un elemento a partire dal precedente).
L'entrata nel ciclo (o la sua "chiusura", se si immagina visivamente la lettera rho greca) è causata quindi da una prima collisione (vedi paradosso dei compleanni, che avviene in media dopo rad(n) passi), prima collisione però (e qui c'è il punto importante) che non è necessario che sia rilevata (quindi non c'è necessità di memorizzare enormi montagne di dati!). A partire da quella prima collisione si genera quindi (a causa del metodo deterministico) sempre la stessa sequenza di elementi (che formano appunto un ciclo); da notare che il ciclo è una sottosequenza del percorso effettuato per arrivare alla prima collisione, quindi il ciclo stesso non è costituito da più di rad(n) punti.

Per rilevare una qualsiasi ripetizione tra due elementi (percorrendo il ciclo si deve tornare ogni volta sugli stessi elementi, non serve individuare il primo elemento che si ripete, quello che ha chiuso il ciclo!) è sufficiente usare un buffer con pochissimi dati in memoria; i dati vengono aggiornati di tanto in tanto mediante un algoritmo che non impatta in maniera sostanziale sul lavoro computazionale complessivo fino a che non si realizza una collisione anche all'interno del buffer di memoria (collisione che deve arrivare per forza quando si è dentro un ciclo, si registra così una collisione utilizzabile dal punto di vista pratico per ricavare la chiave privata).

L'algoritmo di rilevazione della collisione all'interno del buffer nel caso migliore trova la collisione appena si è entrati nel ciclo, nel caso peggiore impiega un numero di iterazioni ulteriori pari alla lunghezza del ciclo stesso

L'algoritmo è il seguente (tratto da https://maths-people.anu.edu.au/~brent/pd/rpb231.pdf):

Quote
2.1.3 Floyd’s Cycle-finding Algorithm
In order to minimise the storage requirement, a collision-detection algorithm can be applied with a
small penalty in the running time. Collision-detection algorithms do not exploit the group structure and are
generic. In Pollard’s paper, Floyd’s algorithm is applied. It compares each pair of Yi and Y2i for i > 1.
Floyd’s algorithm is based on the following fact.

Theorem 2.3 (Knuth (1997)). For a periodic se-quence Y0, Y1, Y2 · · ·, there exists an i > 0 such that
Yi = Y2i  and the smallest such i lies in the range µ <= i <= µ + λ.

Floyd’s algorithm uses only a small constant amount of storage. The best running-time requires µ
iterations and the worst takes µ + λ iterations.
legendary
Activity: 1948
Merit: 2097
October 29, 2016, 11:08:45 AM
#45
...
-->                 (a-A) = (B-b)x              mod n (dove n è l'ordine della curva)
                         x = (a-A)(B-b)^-1      mod n
...

Come calcola (B-b)^-1 ?

Per trovare l'inverso di un numero mod n si può usare l'algoritmo di Euclide che si usa di solito per trovare il MCD tra 2 numeri (se poi dal punto di vista dell'implementazione nel calcolatore ci sono dei modi più efficienti non lo so).

Ad esempio:   n = 31  
Qual è l'inverso di 7 modulo 31?

Il problema può essere riscritto così:   7 * s = 1  mod 31  

Ora 7 e 31 sono coprimi, e si può quindi dimostrare che esistono s e t tali che 7s + 31t = 1 (mod 31)

Se riesco a trovare i 2 numeri "s" e "t"  tali che 7s + 31t = 1 (mod 31), allora ho finito, infatti in tal caso

7s = 1 (mod 31) e  s è l'inverso di 7.


L'algoritmo euclideo  (https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm) permette, dati due numeri
 a e b, di trovare il loro MCD mediante una combinazione lineare:

a*s + b*t = MCD(a,b)  (e nel nostro caso MCD(a,b) = 1 poichè sicuramente ogni numero è coprimo con n che è primo!)

Questo è lo pseudocodice:

Quote
function inverse(a, n)
    t := 0;     newt := 1;    
    r := n;     newr := a;    
    while newr ≠ 0
        quotient := r div newr
        (t, newt) := (newt, t - quotient * newt)
        (r, newr) := (newr, r - quotient * newr)
    if r > 1 then return "a is not invertible"
    if t < 0 then t := t + n
    return t
 
      
legendary
Activity: 2506
Merit: 1120
October 29, 2016, 10:40:26 AM
#44
...
-->                 (a-A) = (B-b)x              mod n (dove n è l'ordine della curva)
                         x = (a-A)(B-b)^-1      mod n
...

Come calcola (B-b)^-1 ?
legendary
Activity: 3318
Merit: 2962
October 29, 2016, 07:55:32 AM
#43

Il pollard roh funziona su un altro principio, un percorso sui quadrati fino alla chiusura di un "circolo" quadratico
(di qui il nome roh che indica appunto questa convergenza circolare che graficamente assomiglia alla lettera greca roh)
e per questo non necessita la memorizzazione. Ma sfrutta una proprieta' delle forme quadratiche modulari.


Hai ragione, Baby Giants - Pollard - Pollard Roh ... quante distinzioni!

E dire che avevo linkato anche il file http://www.mat.uniroma2.it/~geo2/pollardro.pdf con la spiegazione  Roll Eyes

EDIT: @gbianchi sei sicuro che i moduli quadratici non si usino solo nella fattorizzazione dei numeri primi ma non nel problema del logaritmo discreto?

Io ho guardato qui a pag.7

https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiLt--qg4DQAhUJcRQKHfaHDToQFgghMAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Bjsessionid%3D8EF3BF1FB7E6DA875FF3D8F4904BC0AD%3Fdoi%3D10.1.1.114.5683%26rep%3Drep1%26type%3Dpdf&usg=AFQjCNHbmP8spzOswu9cJWbePXZZmMBspA

e viene descritto il metodo così come lo ho spiegato io, senza quadrati... Anche in questo caso si forma la pho greca.


Dunque se ricordo bene nei logaritmi discreti si usa un "adattamento" dell'algoritmo che individua un gruppo ciclico
relativo ad una certa base modulare.... non e' uguale all'algoritmo usato per la fattorizzazione, ma il nocciolo
e' sempre l'individuazione di un gruppo ciclico, cosa che permette di evitare la memorizzazione degli elementi gia' setacciati...

legendary
Activity: 1948
Merit: 2097
October 29, 2016, 07:29:24 AM
#42

Il pollard roh funziona su un altro principio, un percorso sui quadrati fino alla chiusura di un "circolo" quadratico
(di qui il nome roh che indica appunto questa convergenza circolare che graficamente assomiglia alla lettera greca roh)
e per questo non necessita la memorizzazione. Ma sfrutta una proprieta' delle forme quadratiche modulari.


Hai ragione, Baby Giants - Pollard - Pollard Roh ... quante distinzioni!

E dire che avevo linkato anche il file http://www.mat.uniroma2.it/~geo2/pollardro.pdf con la spiegazione  Roll Eyes

EDIT: @gbianchi sei sicuro che i moduli quadratici non si usino solo nella fattorizzazione dei numeri primi ma non nel problema del logaritmo discreto?

Io ho guardato qui a pag.7

https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiLt--qg4DQAhUJcRQKHfaHDToQFgghMAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Bjsessionid%3D8EF3BF1FB7E6DA875FF3D8F4904BC0AD%3Fdoi%3D10.1.1.114.5683%26rep%3Drep1%26type%3Dpdf&usg=AFQjCNHbmP8spzOswu9cJWbePXZZmMBspA

e viene descritto il metodo così come lo ho spiegato io, senza quadrati... Anche in questo caso si forma la rho greca.
legendary
Activity: 3318
Merit: 2962
October 29, 2016, 07:24:59 AM
#41


Pollards Rho Algorithm: This algorithm due to Pollard is a randomized version of the baby step giantstep algorithm It has roughly the same expected running time (radq(n/2) steps) as the baby-step giant-step algorithm, but is superior in that it requires a negligible amount of storage
[/quote]

Il pollard roh funziona su un altro principio, un percorso sui quadrati fino alla chiusura di un "circolo" quadratico
(di qui il nome roh che indica appunto questa convergenza circolare che graficamente assomiglia alla lettera greca roh)
e per questo non necessita la memorizzazione. Ma sfrutta una proprieta' delle forme quadratiche modulari.

legendary
Activity: 1948
Merit: 2097
October 29, 2016, 06:04:30 AM
#40
Se cerco due chiavi che portino allo stesso indirizzo mi quadra il dover memorizzare i dati ma se cerco una chiave che associata ad un altro indirizzo (noto) porta al public address che senso ha memorizzare i tentativi falliti?
Come possono essere utili alla soluzione del problema?

Se pensi a un brute force attack allora hai ragione tu. Ma nel caso di ECDSA non avrebbe senso, ci sono 2^256 chiavi!

Si tratta di affrontare il problema del logaritmo discreto, per risolvere il quale ci sono algoritmi che hanno bisogno in media di 2^128 operazioni, quindi in tal caso ha ragione gbianchi, serve anche un po' di memoria per lo stoccaggio dati (ma neanche così tanta se l'algoritmo è buono).

Il problema del logaritmo dicreto è: dati P e Q, trova x tale che

                                                          xP = Q

Nel caso di bitcoin, x è la chiave privata, P è il punto G (fissato) della curva ellittica secp256k1, Q la chiave pubblica.
In sostanza, per quante volte devo sommare G con se stesso per ottenere la chiave privata Q?

G + G + .... + G = Q     dove x è il numero di addendi del primo membro (la chiave privata).

Ora l'algoritmo di Pollard (inizialmente studiato per la fattorizzazione dei numeri primi http://www.ams.org/journals/mcom/1978-32-143/S0025-5718-1978-0491431-9/S0025-5718-1978-0491431-9.pdf  e poi adattato al caso del logaritmo discreto di ECDSA) consiste in questo caso nel trovare 2 coppie di numeri (A,B) e (a,b) tali che:

                                                  aP+bQ=AP+BQ

Se trovi queste due coppie di valori numerici allora è fatta, hai trovato anche x (la chiave privata).

Infatti:
                      aP+bQ   =  AP+BQ
                      aP+bxP  =  AP+BxP
                      (a+bx)P = (A+Bx)P
                      (a-A)P    = (B-b)xP

-->                 (a-A) = (B-b)x              mod n (dove n è l'ordine della curva)
                         x = (a-A)(B-b)^-1      mod n

Tradotto:  bisogna impostare una sequenza (a,b) di numeri pseudo-casuali, si otterrà una sequenza di punti della forma aP+bQ;  mi fermo quando trovo un'altra coppia di (a,b) che produce un punto già calcolato in precedenza, cioè quando nella mia lista ci sono 2 volte lo stesso punto: è questa la collisione trovata (di qui l'applicazione del paradosso del compleanno http://www.mat.uniroma2.it/~geo2/pollardro.pdf), che non è tra due chiavi della stessa chiave pubblica (-> indirizzo bitcoin).

Chiamo le due coppie di numeri che producono lo stesso punto (a,b) e (A,B) e con il ragionamento precedente ricavo così la chiave privata x che costituisce il collegamento tra P e Q (cioè tra G e la chiave pubblica).

EDIT:

Da qui (http://residentrf.ucoz.ru/_ld/0/34_Digital_Signatu.pdf pag. 27) capisco che in realtà l'algoritmo Pollard Rho non occupa troppo spazio/memoria:
Quote
Baby Step Giant Step Algorithm: This algorithm is a time memory trade-off of the method of exhaustive search.
It requires storage for about radq(n) points, and its running time is roughly radq(n) steps in the worst case

Pollards Rho Algorithm: This algorithm due to Pollard is a randomized version of the baby step giantstep algorithm It has roughly the same expected running time (radq(n/2) steps) as the baby-step giant-step algorithm, but is superior in that it requires a negligible amount of storage
legendary
Activity: 1981
Merit: 1039
October 29, 2016, 05:59:39 AM
#39
forse per produrre una rainbow table oppure per avventurarsi in un bruteforce multi-hash su tutta la blockchain, l'esempio di Andersen comunque non si riferiva ai computer quantistici ma a potenze che già adesso sarebbero disponibili ( tipo botnet ) e che potrebbero crackare una chiave in 2-3 anni.
legendary
Activity: 2506
Merit: 1120
October 29, 2016, 02:17:20 AM
#38
...Una domanda e una considerazione:

1) ma allora qual è il senso dell'articolo "Ultimate physical limits to computation", se in realtà sarà fisicamente possibile effettuare quel tipo di calcolo? Il limite fisico è solo sulla dimensione dello stoccaggio dei dati ma non sulla potenza di calcolo?
...
Non capisco a cosa serva memorizzare le chiavi private in un attacco bruteforce. Io immagino: prova la chiave, funziona? no? allora chiave++ e via senza memorizzare nulla.



Nella ricerca di collisioni (ossia nella categoria di problemi analoghi al paradosso dei compleanni) bisogna
memorizzare gli elementi "gia' setacciati" proprio per poter verificare le collisioni.
Se cerco due chiavi che portino allo stesso indirizzo mi quadra il dover memorizzare i dati ma se cerco una chiave che associata ad un altro indirizzo (noto) porta al public address che senso ha memorizzare i tentativi falliti?
Come possono essere utili alla soluzione del problema?
legendary
Activity: 3318
Merit: 2962
October 28, 2016, 06:51:32 PM
#37
...Una domanda e una considerazione:

1) ma allora qual è il senso dell'articolo "Ultimate physical limits to computation", se in realtà sarà fisicamente possibile effettuare quel tipo di calcolo? Il limite fisico è solo sulla dimensione dello stoccaggio dei dati ma non sulla potenza di calcolo?
...
Non capisco a cosa serva memorizzare le chiavi private in un attacco bruteforce. Io immagino: prova la chiave, funziona? no? allora chiave++ e via senza memorizzare nulla.



Nella ricerca di collisioni (ossia nella categoria di problemi analoghi al paradosso dei compleanni) bisogna
memorizzare gli elementi "gia' setacciati" proprio per poter verificare le collisioni.
legendary
Activity: 2506
Merit: 1120
October 28, 2016, 04:42:47 PM
#36

In caso di ingenti quantità di BTC puoi minarti il blocco che la contiene o affidarti ad un miner che dia questo servizio.


Come è possibile minarsi il blocco da soli? O si possiede l'hardware adatto (cioè si è un miner), ma praticamente quasi nessuno soddisfa questa condizione!
La seconda opzione è quella di affidarsi a un servizio terzo, ma allora la questione della sicurezza e soprattutto del meccanismo trustless di funzionamento del protocollo bitcoin va a farsi benedire...
Stiamo parlando dell'eventualità che cracchino una chiave da 256 bit in meno di 10-60 minuti quindi lo sforzo dovrebbe essere mirato ad importi considerevoli dove immagino possa convenire anche solo affittare potenza di calcolo necessaria a minare un blocco e poi ti tieni anche il premio e le revenue. Al miner mandi solo il merkle da processare che poi contenga la tua transazione e altre non lo sa proprio.
Un miner potrebbe offrire il servizio e non affideresti i tuoi BTC a lui ma solo la transazione che oggi e' pubblica. Se lui cracca sha e ti fotte i soldi almeno sai chi e' stato e potrebbe avere dei BTC depositati a garanzia presso un escrow.
legendary
Activity: 1948
Merit: 2097
October 28, 2016, 01:18:41 PM
#35

In caso di ingenti quantità di BTC puoi minarti il blocco che la contiene o affidarti ad un miner che dia questo servizio.


Come è possibile minarsi il blocco da soli? O si possiede l'hardware adatto (cioè si è un miner), ma praticamente quasi nessuno soddisfa questa condizione!
La seconda opzione è quella di affidarsi a un servizio terzo, ma allora la questione della sicurezza e soprattutto del meccanismo trustless di funzionamento del protocollo bitcoin va a farsi benedire...
legendary
Activity: 2506
Merit: 1120
October 28, 2016, 12:16:31 PM
#34
...Una domanda e una considerazione:

1) ma allora qual è il senso dell'articolo "Ultimate physical limits to computation", se in realtà sarà fisicamente possibile effettuare quel tipo di calcolo? Il limite fisico è solo sulla dimensione dello stoccaggio dei dati ma non sulla potenza di calcolo?
...
Non capisco a cosa serva memorizzare le chiavi private in un attacco bruteforce. Io immagino: prova la chiave, funziona? no? allora chiave++ e via senza memorizzare nulla.

...
per come il Bitcoin è progettato finché non viene speso un indirizzo con il conseguente inserimento nella blockchain della chiave pubblica e la signature, si dovrebbe essere abbastanza quantum-proof già adesso.
2) come notava già 3 anni Vitalik Buterin --> https://bitcoinmagazine.com/articles/bitcoin-is-not-quantum-safe-and-how-we-can-fix-1375242150 c'è anche il problema del tempo di conferma delle transazioni.
In sostanza, poichè nel momento in cui decidi di spendere i tuoi bitcoin sei costretto a esporre la tua chiave pubblica e la tua transazione prima di essere confermata rimane per un po' di tempo sospesa (da pochi secondi a delle ore), l'unica protezione che rimane in quel momento è quella data da ECDSA, non da RIPEMD160. Ovviamente si fa affidamento sul fatto che nessuno, a maggior ragione in un lasso di tempo così esiguo, sia in grado di violare questa protezione.


In caso di ingenti quantità di BTC puoi minarti il blocco che la contiene o affidarti ad un miner che dia questo servizio.
legendary
Activity: 1948
Merit: 2097
October 28, 2016, 12:03:53 PM
#33
sì qualcuno dice entro una trentina d'anni ma già esiste una post-quantum cryptography con svariati algoritmi già pronti e studi a riguardo.

https://en.wikipedia.org/wiki/Post-quantum_cryptography

http://www.etsi.org/images/files/ETSIWhitePapers/QuantumSafeWhitepaper.pdf


per come il Bitcoin è progettato finché non viene speso un indirizzo con il conseguente inserimento nella blockchain della chiave pubblica e la signature, si dovrebbe essere abbastanza quantum-proof già adesso.

Una domanda e una considerazione:

1) ma allora qual è il senso dell'articolo "Ultimate physical limits to computation", se in realtà sarà fisicamente possibile effettuare quel tipo di calcolo? Il limite fisico è solo sulla dimensione dello stoccaggio dei dati ma non sulla potenza di calcolo?

per come il Bitcoin è progettato finché non viene speso un indirizzo con il conseguente inserimento nella blockchain della chiave pubblica e la signature, si dovrebbe essere abbastanza quantum-proof già adesso.
2) come notava già 3 anni Vitalik Buterin --> https://bitcoinmagazine.com/articles/bitcoin-is-not-quantum-safe-and-how-we-can-fix-1375242150 c'è anche il problema del tempo di conferma delle transazioni.
In sostanza, poichè nel momento in cui decidi di spendere i tuoi bitcoin sei costretto a esporre la tua chiave pubblica e la tua transazione prima di essere confermata rimane per un po' di tempo sospesa (da pochi secondi a delle ore), l'unica protezione che rimane in quel momento è quella data da ECDSA, non da RIPEMD160. Ovviamente si fa affidamento sul fatto che nessuno, a maggior ragione in un lasso di tempo così esiguo, sia in grado di violare questa protezione.

legendary
Activity: 1981
Merit: 1039
October 28, 2016, 10:37:30 AM
#32
sì qualcuno dice entro una trentina d'anni ma già esiste una post-quantum cryptography con svariati algoritmi già pronti e studi a riguardo.

https://en.wikipedia.org/wiki/Post-quantum_cryptography

http://www.etsi.org/images/files/ETSIWhitePapers/QuantumSafeWhitepaper.pdf


per come il Bitcoin è progettato finché non viene speso un indirizzo con il conseguente inserimento nella blockchain della chiave pubblica e la signature, si dovrebbe essere abbastanza quantum-proof già adesso.
legendary
Activity: 1948
Merit: 2097
October 28, 2016, 10:30:30 AM
#31
le necessità di spazio di bruteforce per i 128 bit di entropia varrebbe la stessa risposta che Bonwick diede per giustificare i "soli" 128bit di indirizzamento del filesystem ZFS  Grin

Quote
« Anche se ci piacerebbe che la legge di Moore potesse continuare per sempre, la meccanica quantistica impone alcuni limiti fondamentali sul calcolo computazionale e sulla capacità di memorizzazione di una qualsiasi unità fissa. In particolare è stato dimostrato che un chilo di materia confinata in un litro di spazio può effettuare al massimo 1051 operazioni al secondo su al massimo 1031 bit di informazioni (vedere Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)). Un pool di storage a 128 bit completamente riempito dovrebbe contenere 2128 blocchi (nibble) = 2137 bytes = 2140 bits; quindi lo spazio minimo richiesto dovrebbe essere (2140 bit) / (1031 bits/kg) = 136 miliardi di kg.

Con il limite dei 1031 bit/kg, l'intera massa di un computer dovrebbe essere sotto forma di energia pura. Secondo l'equazione E=mc2, l'energia residua dei 136 miliardi di kg è di 1,2x1028 J. La massa dell'oceano è circa 1,4x1021 kg. Occorrerebbero 4.000 J per aumentare la temperatura di 1 kg di acqua per 1 grado Celsius e circa 400.000 J per bollire 1 kg di acqua ghiacciata. La fase di vaporizzazione richiede altri 2 milioni di J/kg. L'energia richiesta per bollire l'oceano è circa 2,4x106 J/kg * 1,4x1021 kg = 3,4x1027 J. Quindi, riempire uno storage a 128 bit dovrebbe richiedere più energia che bollire gli oceani. »

Quindi c'è un proprio un limite fisico anche ben calcolato ...
Ma quando si parla invece di "qubit" e di computer quantici, valgono sempre gli stessi limiti? A me sembrava di aver capito che teoricamente dovrebbe essere possibile costruire dei computer quantici nel futuro che risolvano chiavi a 128 bit senza usare una quantità di energia del genere, ma potrei aver capito male io.
legendary
Activity: 1981
Merit: 1039
October 28, 2016, 10:14:40 AM
#30
le necessità di spazio di bruteforce per i 128 bit di entropia varrebbe la stessa risposta che Bonwick diede per giustificare i "soli" 128bit di indirizzamento del filesystem ZFS  Grin

Quote
« Anche se ci piacerebbe che la legge di Moore potesse continuare per sempre, la meccanica quantistica impone alcuni limiti fondamentali sul calcolo computazionale e sulla capacità di memorizzazione di una qualsiasi unità fissa. In particolare è stato dimostrato che un chilo di materia confinata in un litro di spazio può effettuare al massimo 1051 operazioni al secondo su al massimo 1031 bit di informazioni (vedere Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)). Un pool di storage a 128 bit completamente riempito dovrebbe contenere 2128 blocchi (nibble) = 2137 bytes = 2140 bits; quindi lo spazio minimo richiesto dovrebbe essere (2140 bit) / (1031 bits/kg) = 136 miliardi di kg.

Con il limite dei 1031 bit/kg, l'intera massa di un computer dovrebbe essere sotto forma di energia pura. Secondo l'equazione E=mc2, l'energia residua dei 136 miliardi di kg è di 1,2x1028 J. La massa dell'oceano è circa 1,4x1021 kg. Occorrerebbero 4.000 J per aumentare la temperatura di 1 kg di acqua per 1 grado Celsius e circa 400.000 J per bollire 1 kg di acqua ghiacciata. La fase di vaporizzazione richiede altri 2 milioni di J/kg. L'energia richiesta per bollire l'oceano è circa 2,4x106 J/kg * 1,4x1021 kg = 3,4x1027 J. Quindi, riempire uno storage a 128 bit dovrebbe richiedere più energia che bollire gli oceani. »
legendary
Activity: 1948
Merit: 2097
October 28, 2016, 10:01:21 AM
#29
@Jack Liver

Grazie per il link.
In pratica la sicurezza dipenderebbe dal fatto che, insieme ai bit, si riduce parallelamente in maniera drastica anche la platea dei possibili attaccanti (allora la cosa ha un senso). Inoltre non avevo considerato il problema dello spazio di archiviazione dei dati, stavo pensando solo alla potenza computazionale necessaria.


@gbianchi :   mi sa che hai proprio centrato il punto. Ho trovato il seguente principio di crittografia:
Quote
La chiave deve essere di una dimensione minima da rendere inutile un potenziale attacco a forza bruta e quindi sicuro il messaggio a meno di furto della chiave o di debolezze strutturali dell'algoritmo. La pratica di rendere pubbliche le specifiche degli algoritmi deriva dall'accettazione del principio di Kerckhoffs formulato da Auguste Kerckhoffs nel 1880 e conosciuto anche come massima di Shannon. Questo principio afferma che bisogna dare per scontato che l'attaccante conosca perfettamente l'algoritmo crittografico e che quindi la sicurezza del messaggio deve dipendere unicamente dalla bontà della chiave.

Il principio di Kerckhoffs --> https://it.wikipedia.org/wiki/Principio_di_Kerckhoffs è esattamente opposto al principio che stavo seguendo io, detto principio della sicurezza mediante segretezza https://it.wikipedia.org/wiki/Sicurezza_tramite_segretezza

Secondo me però ci sono dei dati personali che non possono essere conosciuti da quasi nessun altro, quindi in questo caso la segretezza avrebbe un suo senso. Sicuramente l'esempio delle età non era dei migliori, forse qualcosa legato al dna?

Io in sostanza vorrei fondere un dato pubblico come la blockchain (accessibile a tutti) con un dato privato (e quindi segreto alla stragrande maggioranza dei possibili attaccanti del mondo), quindi vorrei lavorare con un algoritmo semiprivato/semipubblico, unendo (ammesso che sia possibile) i benefici dei due principi.

In pratica chi mi conosce magari può accedere facilmente al mio dna, ma non ha la potenza computazionale necessaria / le competenze per mettere in piedi un attacco decente, chi non mi conosce non può, nonostante possa essere bravissimo e avere ingenti risorse computazionali, accedere ai miei dati personali.
legendary
Activity: 3318
Merit: 2962
October 28, 2016, 08:20:28 AM
#28

...
Per mantenere alta l'entropia ognuno dovrebbe scegliere per sè un algoritmo personalizzato e andare a pescare i dati che gli interessano, creando così delle specie di "frasi" particolari molto facili per lui da recuperare all'occorrenza.
...




secondo me e' il punto debole del ragionamento.

Magari uno e' convinto di aver scelto un algoritmo "furbo", e poi si scopre
che buona parte delle persone poco avvezze a questo genere di cose
sceglie algoritmi simili (che so, eta' mia + eta' mamma + eta' babbo ovviamente per fare un esempio)

Inomma lasciare in mano all'untente questo genere di scelta puo' abbassare incredibilmente
il livello di entropia della chiave generata.


legendary
Activity: 1981
Merit: 1039
October 28, 2016, 07:30:05 AM
#27
è di solo 80bit se sei uno dei signer che vuole trovare la collisione tra i due indirizzi per fregarsi tutti i fondi, altrimenti è di 160bit come al solito.


Gavin Anderse in questo post spiega bene le difficoltà di questo tipo di attacco:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012198.html

Quote
Mounting a successful brute-force collision attack would require at least
O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin
POW has computed more SHA256 hashes than that). But it also requires
O(2^80) storage, which is utterly infeasible (there is something on the
order of 2^35 bytes of storage in the entire world).  Even assuming
doubling every single year (faster than Moore's Law), we're four decades
away from an attacker with THE ENTIRE WORLD's storage capacity being able
to mount a collision attack.


Pages:
Jump to: