Dovresti usare SecureRandom.getInstance () con o senza un fornitore?

Question

Dovresti usare SecureRandom.getInstance () con o senza un fornitore?

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

1

Quindi, sono nuovo della crittografia e stavo imparando circa SecureRandom e tutti i modi in cui definisce le implementazioni con o senza provider.

Quando ho cercato alcuni siti per informazioni, si dice di non usare i provider perché se il provider è obsoleto o non disponibile in un sistema, allora l'applicazione deve essere pronta a gestire un'eccezione.

Tuttavia, molti dicono che usare i provider per correre il rischio di scegliere una cattiva implementazione come quella bloccante.

Nei documenti Java, leggo che quando si specifica un particolare provider anche se il framework ha provider con priorità più alta che offrono la stessa implementazione, andrà solo al provider menzionato per ottenere l'implementazione. Però non sembra interessante.

Quindi, dovresti user getInstance() con i fornitori o no? Che è migliore?

java random cryptography

posta Daisetsu 05.10.2018 - 08:25

fonte

2 risposte

Leggi altre domande sui tag java random cryptography

Attacco MageCart su Newegg Utilizzo di ECC come RSA, per crittografare / decriptare

score 3 · Answer 1

Questa è una domanda inerente alla fiducia di un'API crittografica e non è propriamente specifica per SecureRandom. Formulerò ancora la mia risposta attorno a SecureRandom in quanto rappresenta un buon esempio illustrativo.

Di chi ti fidi di più, le persone che hanno scritto il codice dell'API e lo hanno documentato, o commenti casuali sul web? Gli sviluppatori hanno fatto delle scelte in modo da non doverle fare, perché hanno una migliore comprensione delle sfide e dei problemi rispetto all'utente comune delle loro API. Per motivi di flessibilità delle loro API, gli sviluppatori hanno permesso agli utenti di ignorare le loro decisioni di implementazione. Dovresti farlo solo se sei sicuro di sapere meglio di loro.

SecureRandom prova a utilizzare la migliore fonte disponibile, di solito quella fornita dal sistema operativo. Poiché non disponi dell'esperienza necessaria per effettuare una scelta migliore (altrimenti non dovresti fare la tua domanda), dovresti eseguire il rollback con l'impostazione predefinita e gestire le eccezioni in modo appropriato (ad esempio rifiutando di fornire un servizio non sicuro).

score 0 · Answer 2

Non specificare un fornitore. Sicuramente non hardcode un provider. Se non è presente, la tua applicazione semplicemente non funzionerà.

L'unico motivo per configurare un provider è quando i valori casuali di un'implementazione specifica di un provider offrono proprietà che non sono presentate da quelle predefinite. Anche allora, dovresti chiederti se quel particolare non dovrebbe essere usato altrove, nel qual caso potresti mettere il provider casuale in cima alla lista.

Ci sono luoghi in cui questo non è possibile: un problema notevole potrebbe essere la velocità del RNG. Ad esempio, potrei immaginare di voler utilizzare una smart card o un generatore di numeri casuali di un TPM per generare chiavi longeve. Questo tipo di generatore di numeri casuali non è qualcosa che si desidera utilizzare per ciascuna sessione TLS. Ora questo sarebbe un buon caso per specificare sia l'algoritmo che il provider.

Anche in questo caso, inserirò la scelta utilizzando un file di configurazione (firmato) anziché la codifica della soluzione in codice sorgente. La ricompilazione di una soluzione solo a scopo di aggiornamento hardware non è generalmente considerata OK (specialmente non quando si tratta di Java / bytecode).

Si noti che gli algoritmi software sono deterministici e devono essere seminato dal sistema operativo. Quindi non puoi evitare di bloccare se il generatore di numeri casuali del sistema blocca quando fornisce il seme. Quindi puoi scegliere qualsiasi tipo di fornitore di software, ma continuerai a bloccare il sistema fino a quando non sarà disponibile più entropia.