abbattere RSA / ECB / OAEPWITHSHA-256ANDMGF1PADDING

Question

abbattere RSA / ECB / OAEPWITHSHA-256ANDMGF1PADDING

#1 da (1 voti)

1

Quindi Java ha una modalità chiamata RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING . Cosa significa?

RFC3447 , Standard di crittografia a chiave pubblica (PKCS) n. 1: RSA Specifiche di crittografia Versione 2.1 , sezione 7.1.2 Operazione di decrittografia afferma che Hash e MGF sono entrambe opzioni per RSAES-OAEP-DECRYPT. MGF è la sua funzione, definita in Sezione B.2.1 MGF1 e che ha anche l'opzione "Hash".

Forse l'opzione "Hash" in RSAES-OAEP-DECRYPT e MGF1 dovrebbero essere uguali o forse non lo sono, non è chiaro per me. Se lo sono, suppongo che quando hai RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING ciò significa che sha256 dovrebbe essere usato per entrambi. Ma se non dovessero essere uguali allora si potrebbe usare sha256 per RSAES-OAEP-DECRYPT e, per esempio, sha1 usato per MGF1. E se questo è il caso, a quale funzione si suppone che debba essere usato sha256? E quale algoritmo hash dovrebbe essere usato per l'altra funzione?

E cosa significa ECB in questo contesto? ECB è una modalità di cifratura a blocchi simmetrica. Codice elettronico. Forse dovrebbe significare come Java si occupa di testo in chiaro che sono più grandi del modulo? Come forse divide il testo in pezzi grandi come il modulo e poi li cripta con RSA e li concatena insieme? Sto solo indovinando ..

java cryptography rsa pkcs1

posta neubert 22.08.2015 - 20:19

fonte

1 risposta

Leggi altre domande sui tag java cryptography rsa pkcs1

Sarebbe possibile avere un osservatorio javascript, un sandboxing più severo e un CSP più severo (Content Security Policy) per Tor? Caratteristiche di sicurezza attraverso lo standard ISO 25023

score 1 · Accepted Answer

Citando link ,

The default for OAEP is to use SHA-1 for MGF1. Note that the hash chosen doesn't have that much impact on the security of OAEP, so mostly it will be left to this default.

We can easily test this by testing it against "OAEPPadding" and OAEPParameterSpec:
// --- we need a key pair to test encryption/decryption
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(1024); // speedy generation, but not secure anymore
KeyPair kp = kpg.generateKeyPair();
RSAPublicKey pubkey = (RSAPublicKey) kp.getPublic();
RSAPrivateKey privkey = (RSAPrivateKey) kp.getPrivate();

// --- encrypt given algorithm string
Cipher oaepFromAlgo = Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
oaepFromAlgo.init(Cipher.ENCRYPT_MODE, pubkey);
byte[] ct = oaepFromAlgo.doFinal("owlstead".getBytes(StandardCharsets.UTF_8));

// --- decrypt given OAEPParameterSpec
Cipher oaepFromInit = Cipher.getInstance("RSA/ECB/OAEPPadding");
OAEPParameterSpec oaepParams = new OAEPParameterSpec("SHA-256", "MGF1", new MGF1ParameterSpec("SHA-1"), PSpecified.DEFAULT);
oaepFromInit.init(Cipher.DECRYPT_MODE, privkey, oaepParams);
byte[] pt = oaepFromInit.doFinal(ct);
System.out.println(new String(pt, StandardCharsets.UTF_8));
The code will fail with a padding related exception if you substitute "SHA-256" for the MGF1 as parameter.

The reason why the extended algorithm is needed at all is compatibility with other Cipher algorithms. Code written for e.g. "RSA/ECB/PKCS1Padding" doesn't use any parameters, let alone OAEP parameters. So without the longer string OAEP cannot function as drop in replacement.

The mode of operation "ECB" doesn't mean anything in this context, it should have been "None" or it should have been left out completely. You can only encrypt a single block using the RSA implementation of the SunRSA provider.