diff for duplicates of <1533320921.4337.479.camel@linux.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 8bfc119..79ca807 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,9 +5,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > > > > > Udit Agarwal <udit.agarwal@nxp.com> wrote: > > > > > -> > > > > > +===== +> > > > > > +========== > > > > > > +Secure Key -> > > > > > +===== +> > > > > > +========== > > > > > > + > > > > > > +Secure key is the new type added to kernel key ring service. > > > > > > +Secure key is a symmetric type key of minimum length 32 @@ -29,7 +29,7 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > > backend > > > > > pluggable? > > > > -> > > > TPM 1.2 didn't support symmetric keys. For this reason, the TPM +> > > > TPM 1.2 didn't support symmetric keys. For this reason, the TPM > > > > "unseals" the random number, used as a symmetric key, and returns > > > > the > > > > "unsealed" data to the kernel. @@ -37,9 +37,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > Does anyone know if CAAM or TPM 2.0 have support for symmetric > > > > keys? > > > -> > > It depends what you mean by "support". The answer is technically +> > > It depends what you mean by "support". The answer is technically > > > yes, -> > > it's the TPM2_EncryptDecrypt primitive. However, the practical +> > > it's the TPM2_EncryptDecrypt primitive. However, the practical > > > answer > > > is that symmetric keys are mostly used for bulk operations and the > > > TPM @@ -50,9 +50,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > encryptor/decryptor > > > based in software. > > > -> > > > If they have symmetric key support, there would be no need for +> > > > If they have symmetric key support, there would be no need for > > > > the -> > > > symmetric key ever to leave the device in the clear. The device +> > > > symmetric key ever to leave the device in the clear. The device > > > > would unseal/decrypt data, such as an encrypted key. > > > > > > > > The "symmetric" key type would be a generic interface for @@ -82,11 +82,11 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > and that's more like a bulk case because the TPM isn't going to keep up > with the number of unseal operations required. -Agreed. Yet there are a couple of reasons for having this sort of +Agreed. Yet there are a couple of reasons for having this sort of indirection. By having the "encrypted" key encrypted/decrypted by a "trusted" key, the "trusted" key could be updated without impacting -the "encrypted" key. This could be used, for example, for key -migration. Another reason would be to define a single "trusted" key +the "encrypted" key. This could be used, for example, for key +migration. Another reason would be to define a single "trusted" key sealed to a set of PCRs, which could be used to encrypt/decrypt multiple symmetric keys. @@ -96,8 +96,8 @@ key. This discussion is the result of Udit Agarwal's posting a "secure" key patch. Before defining a new key type, whether it is called "secure" or "symmetric", we need to understand how the this new key type is -going to be used. Will it have a similar ability to impose conditions -on the key release as the TPM? Will it have symmetric key support, so +going to be used. Will it have a similar ability to impose conditions +on the key release as the TPM? Will it have symmetric key support, so that the symmetric key never needs to be released from the HW? Mimi diff --git a/a/content_digest b/N1/content_digest index c08f6b7..bf95ef6 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,7 +6,7 @@ "ref\01533311338.4140.3.camel@HansenPartnership.com\0" "From\0Mimi Zohar <zohar@linux.ibm.com>\0" "Subject\0Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.\0" - "Date\0Fri, 03 Aug 2018 18:28:41 +0000\0" + "Date\0Fri, 03 Aug 2018 14:28:41 -0400\0" "To\0James Bottomley <James.Bottomley@hansenpartnership.com>" David Howells <dhowells@redhat.com> " Udit Agarwal <udit.agarwal@nxp.com>\0" @@ -31,9 +31,9 @@ "> > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:\n" "> > > > > Udit Agarwal <udit.agarwal@nxp.com> wrote:\n" "> > > > > \n" - "> > > > > > +=====\n" + "> > > > > > +==========\n" "> > > > > > +Secure Key\n" - "> > > > > > +=====\n" + "> > > > > > +==========\n" "> > > > > > +\n" "> > > > > > +Secure key is the new type added to kernel key ring service.\n" "> > > > > > +Secure key is a symmetric type key of minimum length 32\n" @@ -55,7 +55,7 @@ "> > > > > backend\n" "> > > > > pluggable?\n" "> > > > \n" - "> > > > TPM 1.2 didn't support symmetric keys. \302\240For this reason, the TPM\n" + "> > > > TPM 1.2 didn't support symmetric keys. For this reason, the TPM\n" "> > > > \"unseals\" the random number, used as a symmetric key, and returns\n" "> > > > the\n" "> > > > \"unsealed\" data to the kernel.\n" @@ -63,9 +63,9 @@ "> > > > Does anyone know if CAAM or TPM 2.0 have support for symmetric\n" "> > > > keys?\n" "> > > \n" - "> > > It depends what you mean by \"support\".\302\240\302\240The answer is technically\n" + "> > > It depends what you mean by \"support\". The answer is technically\n" "> > > yes,\n" - "> > > it's the TPM2_EncryptDecrypt primitive.\302\240\302\240However, the practical\n" + "> > > it's the TPM2_EncryptDecrypt primitive. However, the practical\n" "> > > answer\n" "> > > is that symmetric keys are mostly used for bulk operations and the\n" "> > > TPM\n" @@ -76,9 +76,9 @@ "> > > encryptor/decryptor\n" "> > > based in software.\n" "> > > \n" - "> > > > \302\240If they have symmetric key support, there would be no need for\n" + "> > > > If they have symmetric key support, there would be no need for\n" "> > > > the\n" - "> > > > symmetric key ever to leave the device in the clear. \302\240The device\n" + "> > > > symmetric key ever to leave the device in the clear. The device\n" "> > > > would unseal/decrypt data, such as an encrypted key.\n" "> > > > \n" "> > > > The \"symmetric\" key type would be a generic interface for\n" @@ -108,11 +108,11 @@ "> and that's more like a bulk case because the TPM isn't going to keep up\n" "> with the number of unseal operations required.\n" "\n" - "Agreed. \302\240Yet there are a couple of reasons for having this sort of\n" + "Agreed. Yet there are a couple of reasons for having this sort of\n" "indirection. By having the \"encrypted\" key encrypted/decrypted by a\n" "\"trusted\" key, the \"trusted\" key could be updated without impacting\n" - "the \"encrypted\" key. \302\240This could be used, for example, for key\n" - "migration. \302\240Another reason would be to define a single \"trusted\" key\n" + "the \"encrypted\" key. This could be used, for example, for key\n" + "migration. Another reason would be to define a single \"trusted\" key\n" "sealed to a set of PCRs, which could be used to encrypt/decrypt\n" "multiple symmetric keys.\n" "\n" @@ -122,10 +122,10 @@ "This discussion is the result of Udit Agarwal's posting a \"secure\" key\n" "patch. Before defining a new key type, whether it is called \"secure\"\n" "or \"symmetric\", we need to understand how the this new key type is\n" - "going to be used. \302\240Will it have a similar ability to impose conditions\n" - "on the key release as the TPM? \302\240Will it have symmetric key support, so\n" + "going to be used. Will it have a similar ability to impose conditions\n" + "on the key release as the TPM? Will it have symmetric key support, so\n" "that the symmetric key never needs to be released from the HW?\n" "\n" Mimi -0bf806cdfb33ed08c1667dd35fb1aec5451deb241334d470bd4b0a9c011c1b53 +6fdfec96068516febe11f323c71537b219d67721bbc2780766f1dfa7a3b62c53
diff --git a/a/1.txt b/N2/1.txt index 8bfc119..be3f5bb 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -5,9 +5,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > > > > > Udit Agarwal <udit.agarwal@nxp.com> wrote: > > > > > -> > > > > > +===== +> > > > > > +========== > > > > > > +Secure Key -> > > > > > +===== +> > > > > > +========== > > > > > > + > > > > > > +Secure key is the new type added to kernel key ring service. > > > > > > +Secure key is a symmetric type key of minimum length 32 @@ -29,7 +29,7 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > > backend > > > > > pluggable? > > > > -> > > > TPM 1.2 didn't support symmetric keys. For this reason, the TPM +> > > > TPM 1.2 didn't support symmetric keys. ?For this reason, the TPM > > > > "unseals" the random number, used as a symmetric key, and returns > > > > the > > > > "unsealed" data to the kernel. @@ -37,9 +37,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > Does anyone know if CAAM or TPM 2.0 have support for symmetric > > > > keys? > > > -> > > It depends what you mean by "support". The answer is technically +> > > It depends what you mean by "support".??The answer is technically > > > yes, -> > > it's the TPM2_EncryptDecrypt primitive. However, the practical +> > > it's the TPM2_EncryptDecrypt primitive.??However, the practical > > > answer > > > is that symmetric keys are mostly used for bulk operations and the > > > TPM @@ -50,9 +50,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > encryptor/decryptor > > > based in software. > > > -> > > > If they have symmetric key support, there would be no need for +> > > > ?If they have symmetric key support, there would be no need for > > > > the -> > > > symmetric key ever to leave the device in the clear. The device +> > > > symmetric key ever to leave the device in the clear. ?The device > > > > would unseal/decrypt data, such as an encrypted key. > > > > > > > > The "symmetric" key type would be a generic interface for @@ -82,11 +82,11 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > and that's more like a bulk case because the TPM isn't going to keep up > with the number of unseal operations required. -Agreed. Yet there are a couple of reasons for having this sort of +Agreed. ?Yet there are a couple of reasons for having this sort of indirection. By having the "encrypted" key encrypted/decrypted by a "trusted" key, the "trusted" key could be updated without impacting -the "encrypted" key. This could be used, for example, for key -migration. Another reason would be to define a single "trusted" key +the "encrypted" key. ?This could be used, for example, for key +migration. ?Another reason would be to define a single "trusted" key sealed to a set of PCRs, which could be used to encrypt/decrypt multiple symmetric keys. @@ -96,8 +96,13 @@ key. This discussion is the result of Udit Agarwal's posting a "secure" key patch. Before defining a new key type, whether it is called "secure" or "symmetric", we need to understand how the this new key type is -going to be used. Will it have a similar ability to impose conditions -on the key release as the TPM? Will it have symmetric key support, so +going to be used. ?Will it have a similar ability to impose conditions +on the key release as the TPM? ?Will it have symmetric key support, so that the symmetric key never needs to be released from the HW? Mimi + +-- +To unsubscribe from this list: send the line "unsubscribe linux-security-module" in +the body of a message to majordomo at vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N2/content_digest index c08f6b7..130e797 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,24 +4,10 @@ "ref\01533306238.4140.1.camel@HansenPartnership.com\0" "ref\01533307535.4337.415.camel@linux.ibm.com\0" "ref\01533311338.4140.3.camel@HansenPartnership.com\0" - "From\0Mimi Zohar <zohar@linux.ibm.com>\0" - "Subject\0Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.\0" - "Date\0Fri, 03 Aug 2018 18:28:41 +0000\0" - "To\0James Bottomley <James.Bottomley@hansenpartnership.com>" - David Howells <dhowells@redhat.com> - " Udit Agarwal <udit.agarwal@nxp.com>\0" - "Cc\0zohar@linux.vnet.ibm.com" - jmorris@namei.org - serge@hallyn.com - denkenz@gmail.com - linux-integrity@vger.kernel.org - keyrings@vger.kernel.org - linux-security-module@vger.kernel.org - linux-kernel@vger.kernel.org - sahil.malhotra@nxp.com - ruchika.gupta@nxp.com - horia.geanta@nxp.com - " aymen.sghaier@nxp.com\0" + "From\0zohar@linux.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.\0" + "Date\0Fri, 03 Aug 2018 14:28:41 -0400\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote:\n" @@ -31,9 +17,9 @@ "> > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:\n" "> > > > > Udit Agarwal <udit.agarwal@nxp.com> wrote:\n" "> > > > > \n" - "> > > > > > +=====\n" + "> > > > > > +==========\n" "> > > > > > +Secure Key\n" - "> > > > > > +=====\n" + "> > > > > > +==========\n" "> > > > > > +\n" "> > > > > > +Secure key is the new type added to kernel key ring service.\n" "> > > > > > +Secure key is a symmetric type key of minimum length 32\n" @@ -55,7 +41,7 @@ "> > > > > backend\n" "> > > > > pluggable?\n" "> > > > \n" - "> > > > TPM 1.2 didn't support symmetric keys. \302\240For this reason, the TPM\n" + "> > > > TPM 1.2 didn't support symmetric keys. ?For this reason, the TPM\n" "> > > > \"unseals\" the random number, used as a symmetric key, and returns\n" "> > > > the\n" "> > > > \"unsealed\" data to the kernel.\n" @@ -63,9 +49,9 @@ "> > > > Does anyone know if CAAM or TPM 2.0 have support for symmetric\n" "> > > > keys?\n" "> > > \n" - "> > > It depends what you mean by \"support\".\302\240\302\240The answer is technically\n" + "> > > It depends what you mean by \"support\".??The answer is technically\n" "> > > yes,\n" - "> > > it's the TPM2_EncryptDecrypt primitive.\302\240\302\240However, the practical\n" + "> > > it's the TPM2_EncryptDecrypt primitive.??However, the practical\n" "> > > answer\n" "> > > is that symmetric keys are mostly used for bulk operations and the\n" "> > > TPM\n" @@ -76,9 +62,9 @@ "> > > encryptor/decryptor\n" "> > > based in software.\n" "> > > \n" - "> > > > \302\240If they have symmetric key support, there would be no need for\n" + "> > > > ?If they have symmetric key support, there would be no need for\n" "> > > > the\n" - "> > > > symmetric key ever to leave the device in the clear. \302\240The device\n" + "> > > > symmetric key ever to leave the device in the clear. ?The device\n" "> > > > would unseal/decrypt data, such as an encrypted key.\n" "> > > > \n" "> > > > The \"symmetric\" key type would be a generic interface for\n" @@ -108,11 +94,11 @@ "> and that's more like a bulk case because the TPM isn't going to keep up\n" "> with the number of unseal operations required.\n" "\n" - "Agreed. \302\240Yet there are a couple of reasons for having this sort of\n" + "Agreed. ?Yet there are a couple of reasons for having this sort of\n" "indirection. By having the \"encrypted\" key encrypted/decrypted by a\n" "\"trusted\" key, the \"trusted\" key could be updated without impacting\n" - "the \"encrypted\" key. \302\240This could be used, for example, for key\n" - "migration. \302\240Another reason would be to define a single \"trusted\" key\n" + "the \"encrypted\" key. ?This could be used, for example, for key\n" + "migration. ?Another reason would be to define a single \"trusted\" key\n" "sealed to a set of PCRs, which could be used to encrypt/decrypt\n" "multiple symmetric keys.\n" "\n" @@ -122,10 +108,15 @@ "This discussion is the result of Udit Agarwal's posting a \"secure\" key\n" "patch. Before defining a new key type, whether it is called \"secure\"\n" "or \"symmetric\", we need to understand how the this new key type is\n" - "going to be used. \302\240Will it have a similar ability to impose conditions\n" - "on the key release as the TPM? \302\240Will it have symmetric key support, so\n" + "going to be used. ?Will it have a similar ability to impose conditions\n" + "on the key release as the TPM? ?Will it have symmetric key support, so\n" "that the symmetric key never needs to be released from the HW?\n" "\n" - Mimi + "Mimi\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -0bf806cdfb33ed08c1667dd35fb1aec5451deb241334d470bd4b0a9c011c1b53 +8a317cb5f4a6907424f58425e7762c3748d97d9340c50ea86ef784b51deb9748
diff --git a/a/1.txt b/N3/1.txt index 8bfc119..0a1df4f 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -5,9 +5,9 @@ On Fri, 2018-08-03 at 08:48 -0700, James Bottomley wrote: > > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote: > > > > > Udit Agarwal <udit.agarwal@nxp.com> wrote: > > > > > -> > > > > > +===== +> > > > > > +========== > > > > > > +Secure Key -> > > > > > +===== +> > > > > > +========== > > > > > > + > > > > > > +Secure key is the new type added to kernel key ring service. > > > > > > +Secure key is a symmetric type key of minimum length 32 diff --git a/a/content_digest b/N3/content_digest index c08f6b7..66cb577 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -6,7 +6,7 @@ "ref\01533311338.4140.3.camel@HansenPartnership.com\0" "From\0Mimi Zohar <zohar@linux.ibm.com>\0" "Subject\0Re: [PATCH v2 1/2] security/keys/secure_key: Adds the secure key support based on CAAM.\0" - "Date\0Fri, 03 Aug 2018 18:28:41 +0000\0" + "Date\0Fri, 03 Aug 2018 14:28:41 -0400\0" "To\0James Bottomley <James.Bottomley@hansenpartnership.com>" David Howells <dhowells@redhat.com> " Udit Agarwal <udit.agarwal@nxp.com>\0" @@ -31,9 +31,9 @@ "> > > > On Thu, 2018-08-02 at 17:14 +0100, David Howells wrote:\n" "> > > > > Udit Agarwal <udit.agarwal@nxp.com> wrote:\n" "> > > > > \n" - "> > > > > > +=====\n" + "> > > > > > +==========\n" "> > > > > > +Secure Key\n" - "> > > > > > +=====\n" + "> > > > > > +==========\n" "> > > > > > +\n" "> > > > > > +Secure key is the new type added to kernel key ring service.\n" "> > > > > > +Secure key is a symmetric type key of minimum length 32\n" @@ -128,4 +128,4 @@ "\n" Mimi -0bf806cdfb33ed08c1667dd35fb1aec5451deb241334d470bd4b0a9c011c1b53 +f8ceddad301bbba7d48c5caf0cc8e67fde2c2afec12d7d1582956627fda8dff7
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.