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 t
Hello,
Next time, please do a reply-all so CC's aren't dropped.
It seems you jumped halfway in, missing some background info, I'll try to
clarify some things.
On Thu, April 12, 2007 23:28, David Wagner wrote:
> Yes, Satyam Sharma is 100% correct. Unpadded RSA makes no sense. RSA is
> not secur
On Thu, April 12, 2007 23:13, Satyam Sharma wrote:
> But timing attacks are not exclusive to RSA / asymmetric
> cryptosystems. Such (side channel / timing / power measurement / bus
> access) attacks are possible against AES, etc too.
True, but those are often easier to protect, or are less vulnera
Indan Zupancic wrote:
>On Thu, April 12, 2007 11:35, Satyam Sharma wrote:
>> 1. First, sorry, I don't think an RSA implementation not conforming to
>> PKCS #1 qualifies to be called RSA at all. That is definitely a *must*
>> -- why break strong crypto algorithms such as RSA by implementing them
>>
On 4/13/07, Indan Zupancic <[EMAIL PROTECTED]> wrote:
On Thu, April 12, 2007 21:57, Satyam Sharma wrote:
> Of course, I'd rather code to the PKCS#1 RSA Cryptography Standard
> than an entry-level Wikipedia page :-) Timing attacks are particularly
> problematic on smart cards (too slow, and with p
On Thu, April 12, 2007 21:57, Satyam Sharma wrote:
> Of course, I'd rather code to the PKCS#1 RSA Cryptography Standard
> than an entry-level Wikipedia page :-) Timing attacks are particularly
> problematic on smart cards (too slow, and with predictable operation
> times, if not using constant-time
> There are some other better reasons for the bloat in the GNU MP lib,
> though. Tasos' code uses the rsa_cipher() as a dual-purpose primitive.
> Feed it the plaintext (p), public exponent (e) and public modulus (n),
> and you get the ciphertext (c = p^e mod n). Feed it the ciphertext,
> private e
Hello,
On Thu, April 12, 2007 20:38, Satyam Sharma wrote:
> There are some other better reasons for the bloat in the GNU MP lib,
> though. Tasos' code uses the rsa_cipher() as a dual-purpose primitive.
> Feed it the plaintext (p), public exponent (e) and public modulus (n),
> and you get the ciphe
Hi Indan,
On 4/12/07, Indan Zupancic <[EMAIL PROTECTED]> wrote:
I prefer clear, simple code that is easily audited to be correct or at least
not cause problems, which is small enough to not add much bloat. I don't care
about "very slow" or merely "slow" code. RSA/DSA isn't used as a symmetric bl
On Thu, April 12, 2007 16:20, Satyam Sharma wrote:
> Of course, once an infrastructure is indeed merged into the kernel, it
> better already have (or quickly develop) some users for itself. If it
> doesn't, it does end up as rot. If it does, that pretty much solves
> the maintenance problem there i
> Firstly, I'd like to steer clear of all the RSA-in-kernel-or-userspace
> / MPI-in-kernel-or-userspace arguments. True, MPI / RSA / (PKI? that
> even requires some knowledge of ASN.1 etc to parse certificates) do
> add a lot of bloat to the kernel. That said, I don't see any other
> reason to _no
On Thu, April 12, 2007 10:34, Tasos Parisinos wrote:
> I didn't have time to read the pdf but i will. As for erasing ram it usually
> means to also
> scramble it and there are chips that advertise that can do this in 1 cycle.
> Well reaching the bus
> or ram
> to probe it is another thing. Most d
> Perhaps, with that in mind, it's better to not merge the bare RSA version
> either,
> as it might give false hope for more, because it looks like most
> implementations
> should be done in user space (either because that's better anyway, or because
> of
> legal reasons).
Before merging anythi
On Thu, April 12, 2007 11:35, Satyam Sharma wrote:
> Firstly, I'd like to steer clear of all the RSA-in-kernel-or-userspace
> / MPI-in-kernel-or-userspace arguments. True, MPI / RSA / (PKI? that
> even requires some knowledge of ASN.1 etc to parse certificates) do
> add a lot of bloat to the kernel
Hello,
I understand and i agree, thing is that i dont decide about which parts are
given GPL.
While the RSA module is given standalone, it can be still used by others to
develop
their own signing and authenticating mechanisms. For example some will decide
to do
hashing of code with md5 while
On Wed, April 11, 2007 12:14, Tasos Parisinos wrote:
If you are a vendor of a smart phone, a router, or worst, a point of sale
terminal you care about three things. The first is that the end user can't open
the device to probe it or alter it in a way that would create fraud. For example
a salesma
Hi,
On Wed, April 11, 2007 12:14, Tasos Parisinos wrote:
> If you are a vendor of a smart phone, a router, or worst, a point of sale
> terminal you care about three things. The first is that the end user can't
> open
> the device to probe it or alter it in a way that would create fraud. For
> ex
Hello to everybody
-
Firstly i want to thank everybody for reviewing this code and posting all your
usefull comments
-
Secondly i would like to give a generic (as possible) example of use of this
module. More and more nowadays Linux has started to be ported and running in a
wide variet
Indan Zupancic wrote:
On Fri, April 6, 2007 23:30, Bill Davidsen wrote:
Tasos Parisinos wrote:
The main purpose behind the creation of this module was to create the
cryptographic infrastructure to develop an in-kernel system of signed
modules.
Although this functionality c
On Fri, April 6, 2007 23:30, Bill Davidsen wrote:
> Tasos Parisinos wrote:
>> The main purpose behind the creation of this module was to create the
>> cryptographic infrastructure to develop an in-kernel system of signed
>> modules.
>>
>> Although this functionality can be achieved using userland
Tasos Parisinos wrote:
Andi Kleen wrote:
Tasos Parisinos <[EMAIL PROTECTED]> writes:
From: Tasos Parisinos <[EMAIL PROTECTED]>
This patch adds module rsa.ko in the kernel (built-in or as a kernel
module) and offers an API to do fast modular exponentiation, using the
Montgomery algorithm, th
Hi!
> >What kind of applications are we talking about here? I'd like to hack
> >hardware I own.
>
> payment systems, EMV terminals, mobile phone applications
I'd like to hack my cell phone, thank you. (Plus, cellphones do not
contain physical security).
What kind of applications are we talking about here? I'd like to hack
hardware I own.
payment systems, EMV terminals, mobile phone applications
Tasos Parisinos
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
Hi!
> >>The best environment to deploy such functionality is
> >>in updating by remote,
> >>executable code (programs, libs and modules) on
> >>embedded devices running
> >>Linux, that have some form of kernel physical
> >>security, so one can't
> >
> >How would that physical security look lik
> Please read the thread i gave you for some details for things you ask
I don't see much useful information in the thread. It's the
same high level handwaving from you there as in this.
> Have in thought that we mostly talk here about embedded devices
> that run Linux in a very restricted environ
Andi Kleen wrote:
The main purpose behind the creation of this module was to create the
cryptographic infrastructure to develop an in-kernel system of signed
modules.
So how do you plan to close the various interfaces that allow access to kernel
memory?
I would suggest to discuss the hi
> The main purpose behind the creation of this module was to create the
> cryptographic infrastructure to develop an in-kernel system of signed
> modules.
So how do you plan to close the various interfaces that allow access to kernel
memory?
I would suggest to discuss the high level design first
Andi Kleen wrote:
Tasos Parisinos <[EMAIL PROTECTED]> writes:
From: Tasos Parisinos <[EMAIL PROTECTED]>
This patch adds module rsa.ko in the kernel (built-in or as a kernel
module) and offers an API to do fast modular exponentiation, using the
Montgomery algorithm, thus the exponentiation i
Tasos Parisinos <[EMAIL PROTECTED]> writes:
> From: Tasos Parisinos <[EMAIL PROTECTED]>
>
> This patch adds module rsa.ko in the kernel (built-in or as a kernel
> module) and offers an API to do fast modular exponentiation, using the
> Montgomery algorithm, thus the exponentiation is not generic
From: Tasos Parisinos <[EMAIL PROTECTED]>
This patch adds module rsa.ko in the kernel (built-in or as a kernel module)
and offers an API to do fast modular exponentiation, using the Montgomery
algorithm, thus the exponentiation is not generic but can be used only when
the modulus is odd, such
30 matches
Mail list logo
