Secure Hash di un payload molto breve - è possibile?

Question

Secure Hash di un payload molto breve - è possibile?

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)

5

Sto cercando di verificare l'integrità di un payload molto piccolo, circa 64 byte, che verrà memorizzato in un codice QR. Devo verificare che il carico utile non sia stato generato o modificato da un utente malintenzionato. L'aggiunta di un hash sicuro alla fine del payload userà un sacco del mio spazio utile. Speravo di crittografare l'intero carico utile con una chiave privata asimmetrica e quindi tentare la decrittazione con la chiave pubblica. Se la decrittografia ha esito positivo, si presume che il carico utile sia valido e che i dati possano essere letti.

Domande:

Dato un payload così piccolo, una chiave asimmetrica sarebbe troppo corta e quindi troppo facilmente hackerata attraverso un attacco di forza bruta?
Un'implementazione sicura dell'aggiunta di un hash o di un riempimento casuale, non mi lascia praticamente nessun carico utile utilizzabile per i dati reali?
Se 64 byte sono troppo piccoli, qual è una dimensione di payload estremamente piccola e realistica che potrei usare? (Voglio mantenere le dimensioni fisiche del codice QR il più piccolo possibile)

hash aes rsa

posta user3091170 11.05.2015 - 12:58

fonte

3 risposte

Leggi altre domande sui tag hash aes rsa

Come dovrei documentare la mia infrastruttura a chiave pubblica? Perché i token CSRF vengono utilizzati così spesso?

score 3 · Answer 1

Le chiavi asimmetriche sono davvero preziose solo se una di queste deve essere resa pubblica (anche se "pubblica" può significare cose diverse in contesti diversi).

Se si generano e si verificano codici in privato, si può semplicemente utilizzare un segreto privato come parte di un HMAC con un ragionevole algoritmo di hashing.

Se lo spazio è un vantaggio, puoi anche usare i primi X byte dell'output HMAC risultante, con la consapevolezza che ogni byte che rimuovi riduce leggermente la tua protezione.

Se i codici devono essere verificati o generati in pubblico, prima di tutto riconoscere che anche un risultato correttamente valido può essere sovvertito da qualche altro aspetto della catena del software, ma idealmente si può fare la parte pubblica (generazione di validazione ) utilizzando una chiave pubblica e la parte privata utilizzando la chiave privata.

score 2 · Answer 2

L'uso della crittografia simmetrica o asimmetrica in questo caso dipende molto dal caso d'uso e non dagli aspetti di sicurezza. Come viene generato il codice? il richiedente codice può avere un segreto comune tra se stesso e il generatore di codice? Se lo fanno, puoi utilizzare HMAC per verificare il mittente e l'integrità. In caso contrario, puoi utilizzare la crittografia asimmetrica per utilizzare la firma del messaggio. Non puoi usare la crittografia asimmetrica come la descrivi perché funziona in modo opposto.

I was hoping to encrypt the entire payload with an asymmetric private key, and then attempt decryption with the public key

Proprio l'opposto ... Nella crittografia asimmetrica la chiave pubblica viene utilizzata per crittografare, la chiave privata per decifrare. Ma nel tuo caso la crittografia non è necessaria: hai bisogno di una firma digitale per verificare il mittente e l'integrità del messaggio. Ciò avviene firmando con la chiave privata del mittente e verificando il messaggio con la chiave pubblica.

Adding a secure hash at the end of the payload will use up alot of my payload space

Puoi troncare l'hash. Ad esempio, utilizzare solo i primi 32 bit dell'uscita SHA-1. Ciò aumenterà la possibilità di una collisione e renderà più facile la bruteforce, ma è necessario considerare quanto è critico per il tuo caso d'uso. ANY WAY: anche con la crittografia asimmetrica è necessario inviare la firma insieme al messaggio.

Given such a small payload, would an asymmetric key be too short, and therefore too easily hacked through a brute force attack?

Non vedo la relazione. L'unica cosa a cui posso pensare sono gli attacchi di replay. Una volta che qualcuno vede il tuo codice QR, può usarlo così com'è. Per mitigare gli attacchi di riproduzione è necessario aggiungere un nonce casuale alla richiesta di codice e includerlo nell'output. Ad esempio HMAC il payload concatenato con il nonce.

score 1 · Answer 3

Risponderò in ordine:

quasi certamente sì, le firme asimmetriche in generale occupano più spazio rispetto alle controparti simmetriche - RSA richiede una certa quantità di padding e una dimensione minima della chiave per essere sicuri;
se usi un HMAC i requisiti minimi per un HMAC sicuro - un codice di autenticazione dei messaggi basato sull'hash o un hash con chiave - sarebbero circa 64 bit / 8 byte - qualcosa di meno ti metterà in una zona di pericolo - dipende dal resto del sistema se questo rischio può essere mitigato (maggiore è la dimensione del tag di autenticazione, meglio è);
che ti lascia 64 - 8 = 56 byte per un carico utile con un MAC sicuro - puoi far crescere il tuo codice QR se ne hai bisogno di più.

Per le firme la soluzione migliore è ISO / IEC 9796-2 che definisce le firme RSA che forniscono il recupero dei messaggi - ma attenzione che ci sono punti deboli noti . 64 * 8 = 512 bit di RSA è tuttavia troppo corto.

Per un MAC è comune usare i byte più a sinistra - cioè i byte con l'indice meno significativo nella maggior parte degli ambienti di programmazione - come valore del tag di autenticazione. In molte API puoi specificare la dimensione del tag di autenticazione.

Si noti che è necessario un hash con chiave altrimenti un utente malintenzionato può semplicemente sostituire insieme il valore di hash e . A causa di come la chiave è mescolata in un output più piccolo e può essere usato un metodo hash meno sicuro.