Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Andrew Zaborowskiwrote: > Without overhauling akcipher you could modify pkcs1pad so that sign > takes the hash as input, adds the DER struct in front of it to build > the signature, and the verify operation could at most check that the > DER string matches the hash type and return the hash. But I think > RFC2437 suggests that you rather compare the signatures, not the > hashes. Whilst that is true about what RFC2437 shows, I wonder how strict it wants to be about that rather than it just being a convenient way of describing the algorithm. The advantage of doing it the way the RFC suggests is that you get to use the EMSA-PKCS1-V1_5-ENCODE operation twice, thereby saving code and only having one place for bugs to occur instead of two - but you can argue this either way. That said, I would be okay with it returning just the message hash with the padding stripped off, providing the padding is validated in the crypto layer, if that's necessary. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Hi David, On 23 February 2016 at 11:55, David Howellswrote: > Andrew Zaborowski wrote: > >> AIUI Tadeusz is proposing adding the hashing as a new feature. Note >> though that the hash paremeter won't make sense for the encrypt, >> decrypt or verify operations. > > The hash parameter is necessary for the verify operation. From my > perspective, I want a verify operation that takes the signature, the message > hash and the hash name and gives me back an error code. >From the certificates point of view yes, but the akcipher API only has the four operations each of which has one input buffer and out output buffer. Without overhauling akcipher you could modify pkcs1pad so that sign takes the hash as input, adds the DER struct in front of it to build the signature, and the verify operation could at most check that the DER string matches the hash type and return the hash. But I think RFC2437 suggests that you rather compare the signatures, not the hashes. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Andrew Zaborowskiwrote: > AIUI Tadeusz is proposing adding the hashing as a new feature. Note > though that the hash paremeter won't make sense for the encrypt, > decrypt or verify operations. The hash parameter is necessary for the verify operation. From my perspective, I want a verify operation that takes the signature, the message hash and the hash name and gives me back an error code. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Tadeusz Strukwrote: > > Ummm... Possibly. Is that how it's used? > > > > warthog>git grep pkcs1pad -- Documentation > > warthog1> > > Yes, no docs. Sorry. Can I suggest you at least stick a quick usage summary in the banner comment at the top of the file? > > Anyway, the problem I have with this is that I want to get that knowledge > > out of the asymmetric key in-software public key subtype. It knows "rsa", > > "dsa", "ecdsa", ... because that's all the OIDs tell it. > > Rigth, for now the public_key would need to build the full algorithm string as > follows: > > vsprintf(name, "pkcs1pad(%s, %s)", pkey_algo_name[sig->pkey_algo], > hash_algo_name[sig->pkey_hash_algo]); Does this apply to anything other than RSA? > Do you plan to add more padding schemes later? No plans to, but one never knows. I'm *assuming* that OID_rsaEncryption and OID_sha256WithRSAEncryption, for example, must implicitly specify the padding scheme (RFC4055 suggests I'm right in this assumption). We might have to suppose RSASSA-SSP at some point. > Yes, I can start woring on a subsequent patch based on your changes in > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa > Is that ok with you? Sure. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Hi, On 22 February 2016 at 23:28, David Howellswrote: > Tadeusz Struk wrote: > >> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template >> that we already have. Looks like the two do the same padding now. I think that'd be a good thing to do. >> Should we merge then and pass the hash param as a separate template param, >> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"? > > Ummm... Possibly. Is that how it's used? Currently it only does the padding and doesn't care about the hash. The input is expected to be the entire DigestInfo struct. AIUI Tadeusz is proposing adding the hashing as a new feature. Note though that the hash paremeter won't make sense for the encrypt, decrypt or verify operations. Also note that TLS 1.0 uses the padding to sign data that is not a DigestInfo structure and even for 1.2 there are situations where you'll be hashing the data yourself over some time and then you'll want the algorithm to only do the padding and RSA signing. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
On 02/22/2016 02:28 PM, David Howells wrote: > Tadeusz Strukwrote: > >> I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template >> that we already have. Looks like the two do the same padding now. >> Should we merge then and pass the hash param as a separate template param, >> e.g the public_key would allocate "pkcs1pad(rsa, sha1)"? > > Ummm... Possibly. Is that how it's used? > > warthog>git grep pkcs1pad -- Documentation > warthog1> Yes, no docs. Sorry. > > Anyway, the problem I have with this is that I want to get that knowledge out > of the asymmetric key in-software public key subtype. It knows "rsa", "dsa", > "ecdsa", ... because that's all the OIDs tell it. Rigth, for now the public_key would need to build the full algorithm string as follows: vsprintf(name, "pkcs1pad(%s, %s)", pkey_algo_name[sig->pkey_algo], hash_algo_name[sig->pkey_hash_algo]); Do you plan to add more padding schemes later? > > I guess if I have to, I can stoop to converting "rsa" to "pkcs1pad(rsa, > sha1)". > > Can you do me a really quick merge? -rc5 is already out, and I want to get it > to James pronto - plus I have things that are pending on this change being > made. Yes, I can start woring on a subsequent patch based on your changes in http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-rsa Is that ok with you? > > Oh - and how does the padding template find the algorithm DER encoding string > to use? I have wondered whether it should be stored in with the hash > algorithm, but it probably makes more sense to keep it with the rsa module. We can put everything into the crypto/rsa-pkcs1pad.c This is where all the padding logic should be, I think. Thanks, -- TS -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] akcipher: Move the RSA DER encoding to the crypto layer
Tadeusz Strukwrote: > I wonder if this should be merged with the crypto/rsa-pkcs1pad.c template > that we already have. Looks like the two do the same padding now. > Should we merge then and pass the hash param as a separate template param, > e.g the public_key would allocate "pkcs1pad(rsa, sha1)"? Ummm... Possibly. Is that how it's used? warthog>git grep pkcs1pad -- Documentation warthog1> Anyway, the problem I have with this is that I want to get that knowledge out of the asymmetric key in-software public key subtype. It knows "rsa", "dsa", "ecdsa", ... because that's all the OIDs tell it. I guess if I have to, I can stoop to converting "rsa" to "pkcs1pad(rsa, sha1)". Can you do me a really quick merge? -rc5 is already out, and I want to get it to James pronto - plus I have things that are pending on this change being made. Oh - and how does the padding template find the algorithm DER encoding string to use? I have wondered whether it should be stored in with the hash algorithm, but it probably makes more sense to keep it with the rsa module. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html