- From: Smith, Ned <ned.smith@intel.com>
- Date: Mon, 13 Nov 2000 10:46:26 -0800
- To: "'hal@finney.org'" <hal@finney.org>, tplambeck@verisign.com, xml-encryption@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One approach could be to hash the contents and return the encrypted hash value. It will always be the same size. Since the possible choices are few, the recipient can easily compare hash values from the set of possible answers. - -Ned Smith - -----Original Message----- From: hal@finney.org [mailto:hal@finney.org] Sent: Monday, November 13, 2000 10:33 AM To: hal@finney.org; tplambeck@verisign.com; xml-encryption@w3.org Subject: RE: Encryption padding These problems will arise any time a small piece of data is encrypted on its own, and the contents comes from a small set of guessable values with different lengths. It's not specific to attribute values. For example: <presidential_vote> Al Gore </presidential_vote> vs <presidential_vote> George Bush </presidential_vote> If you encrypt just element text, this may become something like: <presidential_vote> OC/BBJqbdvM= </presidential_vote> vs <presidential_vote> kXq8QIPZcJl7KEIBdj7pYQ== </presidential_vote> The ciphertext length in this case can provide a strong clue as to the plaintext. Even if you encrypt the whole element that may not help, as the size of the element tags will often be fixed and so you could still have substantially correlation between ciphertext length and plaintext. The use of padding can alleviate this problem. Clearly the encryption transform has to be informed of which nodes to encrypt. Padding information could be considered a parameter to be included in this information. I don't know whether the group would want to create a specification for how this information is provided to the encryption transform. Hal Finney PGP Security > From: Thane Plambeck <tplambeck@verisign.com> > Date: Mon, 13 Nov 2000 10:08:43 -0800 > > Does anyone have a requirement for this kind of > selective encryption of attributes? > > We (VeriSign) don't. It seems to me to add complexity while > also introducing footholds for cryptanalytic attacks, as alluded to > below. The encryption padding (ie length) attack is only one > example. Others include known > plaintext attacks and attacks that employ cryptographic depth > analysis over reused keys. This last category of attacks goes > beyond selective attribute encryption though. > > XML encryption that takes place selectively > inside a particular element, with some attributes > encrypted but where possibly the element content or other > attributes are in the clear, is going to lead to these types of > problems I predict. They're not unsurmountable, but why allow it > unless there is a requirement? > > I would just say don't allow it, unless there is > some strong requirement for it. > > > > Thane Plambeck > tplambeck@verisign.com > http://www.verisign.com > 650 429 5247 direct, Mt View Office > 650 321 4884 home office > 650 323 4928 home office fax -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.3 iQA/AwUBOhA3yxdTablCCzU/EQJG6QCfW/Emx16HFTrJervceOmTzzn7NS4An3LI rjenI50+tyUjEyYKR7371XbZ =V9li -----END PGP SIGNATURE-----
Received on Monday, 13 November 2000 13:47:53 UTC