Lascia che io sia più specifico
La quantità di voci relative ad alcuni nuovi post dell’account Q, è aumentato ultimamente. C’è un “uragano” di opinioni su questo argomento.
Veder riapparire la notifica di telegram, del canale Q Alerts, dopo diversi mesi, a seguito della decisione da parte della corte suprema sull’aborto, è stata un’altra emozione indescrivibile.
Questo ha comportato, nelle ore successive e nei giorni successivi, una tempesta di opinioni, per lo più insostenibili su salts, tripcodes, ecc., che sono sorte perché c’è un vuoto di fatti concreti e questo viene amplificato da un marasma di confusione e scarsa comprensione (forse con qualche “aiuto” intenzionale da parte di alcune persone con un interesse acquisito nel crearle).
In questo articolo, esporrò ciò che ho trovato durante le mie ricerche, ponendo dei limiti intorno a ciò che non so, al fine di aiutare le persone, almeno a capire le domande per le quali non ci sono risposte sufficienti.
Iniziamo con lo sfondo del recente evento.
Il 24 giugno, la sera della sentenza Roe contro Wade, della Corte Suprema, alcuni Anons hanno notato che era apparso un nuovo post sulla board di 8kun – dove Q era noto per pubblicare i suoi “drops” – fino a quando ha smesso di farlo, nel dicembre del 2020.
Il post sembra avere lo stesso tripcode che “lui” aveva usato in precedenza.
C’era e c’è, incertezza e scetticismo sull’autenticità dei nuovi post e non ho intenzione, in questo articolo, di parlare dei vari collegamenti di conferme, o sui delta zero, ma metterò in evidenza alcuni fatti ed esporrò alcune domande.
Nella guerra dell’informazione in cui ci troviamo, ci sono là fuori, molti gruppi politici e media dell’opposizione, che si stanno attivamente impegnando nello screditare sia Q che gli Anons, al fine di confondere le acque, minare la credibilità, iniettare false narrazioni, distrarre e dividere la comunità.
Puoi vederli impegnati quotidianamente, se sai come individuarli.
La tecnica di “sovrapporre” un mucchio di spazzatura incoerente, propaganda e false narrazioni, su quella che, in realtà, è una narrativa minacciosa e veritiera – al fine di affondarla – è una tattica di guerra dell’informazione ben nota. In questo tipo di battaglia, trovare e mantenere la narrativa autentica è davvero difficile e non molti possono gestire il processo, senza diventare “black pilled“.
Vi garantisco che quel tipo di guerra sta accadendo, il che, di per sé, suggerisce che c’è qualcosa che diverse “parti”, considerano Q estremamente minaccioso.
Niente è come sembra e molti di voi stanno seguendo i tipi sbagliati di influencer, senza rendersi conto della natura della guerra che si sta svolgendo intorno a noi.
Non entrerò nel merito di chi potrebbero essere le mele marce, ma Jordan Sather ha una lista degna di considerazione.
In ogni caso, ci sono molte altre persone che concentrano la loro attenzione su questi argomenti e vi assicuro che ci sono Anons che fanno un lavoro straordinario, sia di analisi dei fatti, che di divulgazione per la massa.
Concentriamoci su ciò che mi interessa al momento.
Quello che sappiamo dal 24 giugno è questo: qualcuno ha pubblicato un messaggio sulla board di 8kun qresearch, usando l’handle Q e la password che (supponiamo), era stata utilizzata prima per accedere a quell’account.
Poco dopo, qualcuno, ha avuto accesso alla board projectdcomms – quella che viene chiamata board privata di Q – ed ha cancellato quello che si ritiene fosse un “post fake“, di qualcuno di nome “B“.
Quel messaggio non aveva tripcode; è stato presumibilmente messo lì da un infiltrato nello staff amministrativo di 8kun, che ha avuto accesso come admin su 8kun, nel maggio del 2021.
Qualunque sia la verità di questa situazione, quel post rimase intatto su quella board, fino al 24 giugno 2022.
Fino a quando non è stato improvvisamente cancellato.
Da qualcuno.
Tutto quello che possiamo dire – a seguito delle dichiarazioni di Ron Watkins [CodeMonkeyZ] e assumendo un comportamento onorevole da parte dello staff amministrativo di 8kuns e un design sicuro per l’autenticazione del servizio stesso – è che: “qualcuno con la password corretta ha effettuato l’accesso e ha intrapreso queste due azioni”.
Se il sistema 8kun è progettato correttamente, anche gli amministratori non possono sapere se ci sono due password distinte, utilizzate per questi due scopi.
Parliamo ora in generale, per arrivare ad alcuni punti di interesse.
Come funziona un accesso al server di 8kun
I server 8kun hanno un database utente per l’autenticazione, che contiene tre informazioni che vengono confrontate al momento del login:
- un nome utente U (supponiamo per questo esempio, U = “Q”)
- una stringa casuale univoca di lettere e numeri S chiamata “salt” (che è diversa per ogni utente) e
- un valore hash crittografico H, che è una funzione crittografica, H = f (password, salt), dove “f” significa solo “qualche funzione di” e f (password, salt), significa “qualche funzione che coinvolge la password e il salt”.
Presumiamo, per il momento, che il sistema di autenticazione in 8kun utilizzi un hash SHA-256 per le password. In questo modo viene generata una stringa di base 16, da 32 caratteri per la password di un determinato utente.
Presumo che il server 8kun conservi in un database: il nome dell’utente, l’hash della sua password in combinazione con un salt casuale a N cifre e il valore del salt stesso.
Potrebbe mantenere un’altra cosa a cui arriverò più tardi, ma NON conserva la password dell’utente, in nessuna parte del server, né per effettuare confronti, nè per qualsiasi altro scopo (solo l’hash viene conservato per sicurezza).
Per questo motivo – ovvero il fatto che la password non sia conservata sul server – i valori salt non possono essere modificati, fino al momento in cui l’utente accede e fornisce nuovamente la password.
L’intera linea della teoria della “rotazione del salt per hackerare un tripcode, bla bla bla“, cade a pezzi su questo punto.
Se il salt fosse stato cambiato mentre Q era offline, allora l’hash non si sarebbe potuto rigenerare (dipende sia dalla password che dal salt), perché non c’era una password disponibile per ricalcolare l’hash. Se la modifica salt fosse stata fatta comunque, Q non sarebbe in grado di autenticarsi di nuovo in futuro, perché l’hash sarebbe sbagliato.
Informazioni su Tripcodes
Sul sistema 8kun – al fine di mostrare agli altri partecipanti che un determinato utente è stato “autenticato“, in qualche modo, dal server, in modo tale che un certo numero di post futuri possa essere attribuito collettivamente a quello stesso particolare utente, nel tempo e su più linee – viene utilizzato un indicatore visivo chiamato: “tripcode“.
È semplicemente una stringa di 10 lettere e numeri.
Il tripcode dice, in teoria:
“potremmo non sapere chi sia questa persona anonima, ma ha usato la stessa password per accedere ogni volta e lo stesso utente ha scritto questo post, quello e quell’altro, che hanno tutti lo stesso tripcode. Il tutto per garantire che sia sempre la stessa voce e quella di nessun altro. Quando vedi il tripcode, sai che è la stessa persona”.
È una firma, in sostanza.
Il tripcode viene calcolato come una funzione dell’hash della password dell’utente, il che lo rende, quindi, anche indirettamente dipendente dal valore salt assegnato a quell’utente.
Spiegherò più avanti perché non è significativo.
Può anche essere una funzione di altre informazioni, come gli indirizzi IP, ma anche questo non ha importanza.
ll tripcode contiene 10 caratteri, ognuno dei quali può, apparentemente, essere una lettera maiuscola o minuscola, o una cifra da 0 a 9. Ciò significa che ci sono 62 possibili simboli tra cui scegliere, in ciascuna delle 10 posizioni e ciò significa che ci sono da 62 a 10 combinazioni di codici di viaggio possibili, supponendo che siano consentiti caratteri ripetuti.
Questo è un numero enormemente grande!
Ciò significa che ci sono 839.299.365.868.340.224 (834 quadrilioni o 8,34 x 10^17) possibili tripcodes.
Poiché, in qualche modo, il viaggio è “calcolato” dall’hash (ignorando per un momento tutte le altre cose da cui potrebbe dipendere) e l’hash è una stringa di 32 caratteri, con 32 posizioni di cifre esa-decimali (quindi 16 possibili scelte di “cifre” in ogni posizione), dobbiamo sapere qualcosa sulla dimensione dello spazio- valore dell’hash.
Con SHA-256, ci sono 3,4 x 10^38 possibili valori di output hash univoci.
Ciò significa che per ogni possibile tripcode, ci sono circa 10^19 (sestilioni) valori hash, potenzialmente corrispondenti. Questo è un numero enorme di potenziali corrispondenze “duplicate”.
A causa della scala di questi numeri, sostengo che non importa (significativamente) come l’hash sia costruito per il resto di questa spiegazione, ne importa quale sia il valore del salt, o quanto sia grande rispetto alla password.
Ci concentreremo solo sul numero di possibili hash per fare il punto della situazione.
Adesso userò la parola, “collisione“.
Poiché ci sono 10 sestilioni di valori hash possibili, per ogni possibile tripcode e poiché il valore hash dipende dalla password dell’utente, più il valore salt assegnato casualmente, ne consegue che ci sono molti possibili valori hash che potrebbero “risultare” nello stesso tripcode.
Ecco, a proposito, un esempio di un hash SHA-256 di una password complicata, per coloro che non hanno familiarità con la materia.
Supponiamo, per il momento, che, indipendentemente dal fatto che venga calcolato il tripcode, le probabilità di ottenere un particolare valore di tripcode siano altrettanto probabili di qualsiasi altro valore (cioè, la distribuzione di probabilità è “piatta”).
Diamo un’occhiata a quanto tempo ci vorrebbe per “forzare” la scoperta di una collisione tripcode, cercando tra un gruppo di valori hash, alla ricerca di una corrispondenza in queste condizioni in qualche modo ideali, solo per avere un’idea di massima.
Se si allineano tutti i codici di viaggio da un lato e tutti i possibili codici hash dall’altro e si tenta di disegnare delle linee, da un tripcode a un sestilione di “collisioni” sul lato hash, si dovrebbe comunque cercare, approssimativamente parlando, circa 10^16 valori hash (circa 100 trilioni), prima di poter trovare un altro valore hash in grado di generare lo stesso tripcode (una collisione).
Questo è un lavoro computazionale enorme, ma non impossibile.
Potendo fare un confronto: ogni microsecondo, potrebbero essere necessari 3,17 x 10^8 anni, per trovare un’altra possibile corrispondenza. Cioè per trovare un altro hash che genera lo stesso tripcode (questo è nell’ordine del 1/10 dell’età dell’Universo).
Se, in qualche modo, hai fatto un milione di confronti di questo tipo, in parallelo, invece di uno alla volta, potresti ridurlo a pochi anni di calcolo continuo, solo per trovare una collisione.
Bene, quindi, sarebbe necessario noleggiare un super-computer NSA, per due anni interi, solo per provare a fare questa cosa stupida.
E allora?
Esiste un modo per farlo, ma, ugualmente, non avrebbe alcuna importanza.
Cosa potresti fare?
Molto semplicemente: se si calcola il tripcode per l’hash di un particolare utente, si salva quel tripcode nel database di autenticazione dell’utente 8kun, insieme all’hash dell’utente.
Se un altro utente genera un tripcode per sè stesso (anche se si tratta di un amministratore di sistema 8kun infiltrato, con accesso al database di autenticazione, che giocherella con i valori di password e salt per trovare una corrispondenza), esiste una regola che dice che: il nuovo tripcode, non può essere uno che è già stato “memorizzato” nel database.
È sufficiente controllare, per vedere se ne esiste già uno con quel valore.
Se non fosse un amministratore di sistema 8kun a farlo, sarebbe necessario rubare (esfiltrare) il database, o il file di autenticazione, per funzionare al di fuori di 8kun.
Questo semplice passaggio, memorizzando i tripcodes esistenti, elimina tutti gli imbrogli, anche se pensi che sia computazionalmente possibile “hackerare un viaggio“.
Riassumento: si blocca il tripcode, in modo che nessun altro, anche per caso, o con la forza bruta, possa usarlo.
Non è possibile prevenire, algoritmicamente, una collisione tra tripcode e valori hash, ma è possibile RILEVARE quando si verificano e semplicemente rifiutare i duplicati.
Questa è una soluzione, molto semplice ed elegante, che mina molte teorie sulla “falsificazione” o l’”hackeraggio” dei tripcodes.
Si potrebbero avere un sacco di problemi computazionali, ma, comunque, questo non avrebbe minimamente importanza.
È questo ciò che è attualmente in uso nel codice sorgente di 8kun?
Non lo so.
Ma fino a quando qualcuno non mi mostra il codice sorgente attuale, non vedo alcuna necessità nel “discutere” su persone che affermano che Q non sia più autentico.
Mostrami il codice sorgente e risparmiami le chiacchiere.
WWG1WGA
Gli aspetti tecnici di questo articolo sono estratti da un signor nessuno che ha avuto esperienze di vita interessanti in una serie di aree legate alla tecnologia.
