KeyProtection.Builder.SetRandomizedEncryptionRequired(Boolean) Méthode
Définition
Important
Certaines informations portent sur la préversion du produit qui est susceptible d’être en grande partie modifiée avant sa publication. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.
Définit si le chiffrement à l’aide de cette clé doit être suffisamment aléatoire pour produire des texte chiffrés différents pour le même texte en clair à chaque fois.
[Android.Runtime.Register("setRandomizedEncryptionRequired", "(Z)Landroid/security/keystore/KeyProtection$Builder;", "", ApiSince=23)]
public Android.Security.Keystore.KeyProtection.Builder SetRandomizedEncryptionRequired(bool required);[<Android.Runtime.Register("setRandomizedEncryptionRequired", "(Z)Landroid/security/keystore/KeyProtection$Builder;", "", ApiSince=23)>]
member this.SetRandomizedEncryptionRequired : bool -> Android.Security.Keystore.KeyProtection.BuilderParamètres
- required
- Boolean
Retours
- Attributs
Remarques
Définit si le chiffrement à l’aide de cette clé doit être suffisamment aléatoire pour produire des texte chiffrés différents pour le même texte en clair à chaque fois. La propriété de chiffrement formelle requise est une indistinguishabilité sous l’attaque en texte clair choisi (IND-CPA). Cette propriété est importante, car elle atténue plusieurs classes de faiblesses en raison desquelles le texte chiffré peut fuiter des informations sur le texte en clair. Par exemple, si un texte en clair donné produit toujours le même texte chiffré, un attaquant peut voir les texte chiffrés répétés et être en mesure de déduire quelque chose sur le texte en clair.
Par défaut, IND-CPA est obligatoire.
Quand IND-CPA est nécessaire : la transformation qui n’offre pas IND-CPA, comme les chiffrements symétriques utilisant le mode BCE ou le chiffrement RSA sans remplissage, sont interdites ; dans les transformations qui utilisent un IV, comme les chiffrements symétriques dans les modes de bloc GCM, CBC et CTR, les IV fournies par l’appelant sont rejetées lors du chiffrement, pour s’assurer que seules les IV aléatoires sont utilisées avant de désactiver cette exigence, tenez compte des approches suivantes à la place : Si vous générez un IV aléatoire pour le chiffrement, puis initialisez un chiffrement à l’aide du chiffrement IV, la solution consiste à laisser le chiffrement générer un IV aléatoire à la place. Cela se produit si le chiffrement est initialisé pour le chiffrement sans iv. Le IV peut ensuite être interrogé via Cipher.getIV() ; Si vous générez un IV non aléatoire (par exemple, un IV dérivé d’un élément non aléatoire, tel que le nom du fichier chiffré, l’ID de transaction ou le mot de passe ou un identificateur d’appareil), envisagez de modifier votre conception pour utiliser un IV aléatoire qui sera ensuite fourni en plus du texte chiffré aux entités qui doivent déchiffrer le texte chiffré ; Si vous utilisez le chiffrement RSA sans remplissage, envisagez de basculer vers des schémas de remplissage qui offrent IND-CPA, tels que PKCS#1 ou OAEP.
Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.