Re: [PATCH 05/28] Remove MPILIB_EXTRA
On Wed, 18 Jun 2014, Borislav Petkov wrote: This oneliner is neither part of v3.16-rc1 nor part of linux-next. It applies cleanly to next-20140618. Should I hope that Jiri Kosina wants to take it for trivial (CC-ed)? Yeah, he will. It's not in my queue of patches to be processed though, so I guess I wasn't CCed on the initial submission. Paul, if you want me to pick it up, please bounce it to triv...@kernel.org as well. Thanks, -- Jiri Kosina SUSE Labs -- 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] [CRYPTO] kconfig: Corrected a typo
On Thu, 17 Oct 2013, Siddharth Goel wrote: Corrected a typo in option description in Kconfig Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=60848 Signed-off-by: Siddharth Goel siddharth98...@gmail.com --- crypto/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index 69ce573..84698cf 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1084,7 +1084,7 @@ config CRYPTO_SERPENT Keys are allowed to be from 0 to 256 bits in length, in steps of 8 bits. Also includes the 'Tnepres' algorithm, a reversed - variant of Serpent for compatibility with old kerneli.org code. + variant of Serpent for compatibility with old kernel.org code. Automatic conversion of kerneli - kernel is not correct, it's not a typo. Please google for kerneli in LKML archives. -- Jiri Kosina SUSE Labs -- 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: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Wed, 25 Sep 2013, James Bottomley wrote:
I don't get this. Why is it important that current kernel can't
recreate the signature?
The thread model is an attack on the saved information (i.e. the suspend
image) between it being saved by the old kernel and used by the new one.
The important point isn't that the new kernel doesn't have access to
K_{N-1} it's that no-one does: the key is destroyed as soon as the old
kernel terminates however the verification public part P_{N-1} survives.
James,
could you please describe the exact scenario you think that the symmetric
keys aproach doesn't protect against, while the assymetric key aproach
does?
The crucial points, which I believe make the symmetric key aproach work
(and I feel quite embarassed by the fact that I haven't realized this
initially when coming up with the assymetric keys aproach) are:
- the kernel that is performing the actual resumption is trusted in the
secure boot model, i.e. you trust it to perform proper verification
- potentially malicious userspace (which is what we are protecting against
-- malicious root creating fake hibernation image and issuing reboot)
doesn't have access to the symmetric key
--
Jiri Kosina
SUSE Labs
--
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 03/18] asymmetric keys: separate the length checking of octet string from RSA_I2OSP
On Mon, 26 Aug 2013, Pavel Machek wrote:
Due to RSA_I2OSP is not only used by signature verification path but
also used
in signature generation path. So, separate the length checking of octet
string
because it's not for generate 0x00 0x01 leading string when used in
signature
generation.
Reviewed-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Lee, Chun-Yi j...@suse.com
+static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
+{
+ unsigned x_size;
+ unsigned X_size;
+ u8 *X = NULL;
Is this kernel code or entry into obfuscated C code contest? This is not
funny.
The small x is the input integer that will transfer to big X that is
a octet sting.
Sorry for I direct give variable name to match with spec, maybe I need
use big_X or
Having variables that differ only in case is confusing. Actually
RSA_I2OSP is not a good name for function, either.
If it converts x into X, perhaps you can name one input and second output?
The variable naming is according to spec, and I believe it makes sense to
keep it so, no matter how stupid the naming in the spec might be.
Otherwise you have to do mental remapping when looking at the code and the
spec at the same time, which is very inconvenient.
Would a comment next to the variable declaration, that would point this
fact out, be satisfactory for you?
--
Jiri Kosina
SUSE Labs
--
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] Fix requr typo on crypto/Kconfig
On Sun, 28 Mar 2010, Gilles Espinasse wrote: Signed-off-by: Gilles Espinasse g@free.fr I have condensed all your three patches into one larger one and applied it. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- 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
[PATCH -next] crypto: ghash - put proper .data section in place
Lbswap_mask, Lpoly and Ltwo_one should clearly belong to .data section, not .text. Signed-off-by: Jiri Kosina jkos...@suse.cz --- arch/x86/crypto/ghash-clmulni-intel_asm.S |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S b/arch/x86/crypto/ghash-clmulni-intel_asm.S index 5958498..24f84e1 100644 --- a/arch/x86/crypto/ghash-clmulni-intel_asm.S +++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S @@ -19,6 +19,8 @@ #include linux/linkage.h #include asm/i387.h +.data + .align 16 .Lbswap_mask: .octa 0x000102030405060708090a0b0c0d0e0f -- 1.5.6 -- 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 3/7] crypto: testmgr: fix warning
On Mon, 19 Oct 2009, Felipe Contreras wrote:
crypto/testmgr.c: In function ?test_cprng?:
crypto/testmgr.c:1204: warning: ?err? may be used uninitialized in this
function
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
crypto/testmgr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6d5b746..1f2357b 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1201,7 +1201,7 @@ static int test_cprng(struct crypto_rng *tfm, struct
cprng_testvec *template,
unsigned int tcount)
{
const char *algo = crypto_tfm_alg_driver_name(crypto_rng_tfm(tfm));
- int err, i, j, seedsize;
+ int err = 0, i, j, seedsize;
u8 *seed;
char result[32];
As it is not obvious to me immediately why/whether tcount couldn't be zero
(which would cause uninitialized use of 'err'), I am not merging this
through trivial tree. Herbert?
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
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
