| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <003201c77dd3$95b22500$0864a8c0@scs1> Date: Fri, 13 Apr 2007 16:56:42 +0300 From: "Tasos Parisinos" <t.parisinos@...ensis.com> To: "Indan Zupancic" <indan@....nu>, "David Wagner" <daw-usenet@...erner.cs.berkeley.edu> Cc: <linux-kernel@...r.kernel.org>, "Satyam Sharma" <satyam.sharma@...il.com> Subject: Re: [PATCH resend][CRYPTO]: RSA algorithm patch Hello again As i formerly stated there was some 'management' mixup (and don't want to believe that it had to do with my code and crypto competence :), anyway no offence about that, really) about what to submit and what not. Now things are getting a lot clearer and i think that we will be able to submit all the patches in order to have: The rsa module patch as is now with the following additions 1. Padding as PKCS#1 specificates 2. Crypto API glue code And another patch that will be the code authenticating mechanism. These two will be a complete binary authenticating mechanism to be used in embedded Linux much the way it was described on a previous post of mine. The above will take some time as they will be reworked significantly based on the experience gathered through this discussion If this code organization is done, should this go in crypto as rsa module + binary signing module or should be made as one unique module for code authentication (hiding the rsa implementation inside it) and putting it somewhere else (not in crypto)? ----- Sharma really made a point about excluding padding from this module and leaving it to userspace or other in-kernel code. It should be added in the module, as it is the only to be used anyway be everyone. Also Indan is right, this module was supposed to be a simple mpi implementation to do modexp using the montgomery algorithm to be used for binary authentication, but if it is to turn it into real RSA it should have padding and crypto API glue code. ----- Indan has said: I don't see this happening soon. But a good start would be if someone who cares about this sets up a mailing list or website to collect all users and information. I think that this is a nice idea, so i will try setup such a spot to be able to discuss and share code. ----- I created this code taking Indan's way of looking at things. Not porting something like the whole gmp but just re-implementing only the needed mpi code. This as a result can be a clear and robust and really easy to audit, basis for future implementations and addons. The drawback is that it does not provide generic mpi functions to be used in other places as well. The question is: If a full mpi kernel lib would be big and complex and randomly used then it is better to have distinct little modules, implementing their own needed mpi functionality, isn't that so? When there will be lots of them modules depending heavily on mpi calculations then those could be reworked to reach that point and in that case you would have less complexity and code size. ------- There was also big discussion about implementing CRT to do modexp with the private key. In my view although this could be implemented in the RSA module in order for it to be generic it is susceptible to timing and other attacks and i would personally would not use it neither i would keep such keys on a plain filesystem on an embedded device on the market. That is why there is only the implementation of the montgomery exponentiation in my patch to be used with public keys and exponents to authenticate code on embedded devices as described in detail in a previous message. Excluding the use of private keys and CRT also makes code a lot simpler. I tell you again this module is not created for PC security. It is created to address a specific need on embedded devices. Whether it will be used by a PC user to cipher/decipher data on his disk is ok with me but really in that case there is no added security anyway. The question there is: Create a generic and complex RSA module to be used by anyone even on PCs (where it could be done easily (and much with the same safety) on userland) or create a cut-down and specific authenticating mechanism (using RSA) to authenticate code, that would be able to be used by all Linux embedded users at first (and for naive and unsafe usage in PC world)? Bye for now Tasos Parisinos - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists