PKCS # 12 è un formato estremamente flessibile, quindi qualsiasi risposta alla tua domanda è relativa a ciò che il produttore di archivi ha deciso fare: quali algoritmi, quali parametri ...
Normalmente, quando si esegue la crittografia basata su password, si finirà con 3DES o AES e l'algoritmo di derivazione della chiave è PBKDF2 con un parametro di costo che non puoi scegliere. Per rendere la storia breve, questo sarà sicuro come queste cose possono essere SE (e questo è un grande "se") la password utilizzata è strong .
Per un caso d'uso specializzato, puoi generare la "password" come una grande chiave reale: prendi il tuo PRNG protetto crittograficamente sicuro (ad esempio /dev/urandom su Linux e MacOS X) e usalo per produrre una sequenza di 24 esadecimali casuali cifre. Questo offrirà 96 bit di entropia e le cose andranno bene. La riservatezza della chiave privata nel file PKCS # 12 verrà mantenuta e l' integrità verrà verificata in modo affidabile.
Un modo semplice per generare una "password" casuale su un sistema Linux è:
(dd if=/dev/urandom bs=16 count=1 2>/dev/null) | sha1sum | cut -b 1-24
Su Windows puoi usare PowerShell:
$rng = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
$buf = New-Object byte[] 12
$rng.GetBytes($buf)
([System.BitConverter]::ToString($buf) -replace "-", "").ToLowerInvariant()
Se vuoi davvero aggiungere un ulteriore livello, il modo ragionevole è non di assemblare un algoritmo di crittografia simmetrica e un MAC te stesso: queste cose sono ingannevolmente difficili, il che significa che è facile fare qualcosa quale funziona , molto più difficile da realizzare qualcosa che sia strong , e molto più difficile da fare per rendere possibile qualcosa che può essere accertato. Invece, utilizzare un protocollo esistente supportato da un'implementazione esistente e ben controllata. Suggerisco GnuPG (il formato OpenPGP implementato da GnuPG supporta sia la crittografia simmetrica che asimmetrica).