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
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
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
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
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
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
> 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
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
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
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
> 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
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
> 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
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
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
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
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 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.
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 anything
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 die in
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 _not_
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
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 block
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
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
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
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
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
in
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
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 secure
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
>
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
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
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
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
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,
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).
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).
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, thus
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 helper
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
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
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
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
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 like? Would it
include
> 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
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
> 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
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
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
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
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 but can
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 is
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:
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
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
60 matches
Mail list logo
