I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

On Thu, 08 May 2008 12:01:27 -0700, Albert wrote:

I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

Is it not the case that both RSA keys can be used for encryption
or decryption? That is, is it not true that something encrypted with a
given RSA private key can only be decrypted with its corresponding public
key, and something encrypted with a given public key can only be
decrypted with its corresponding private key?

Correct.

Any suggestion/comments?

 I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

First of all is this secure?

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Pubkeybreaker <pubkeybrea... at (no spam) aol.com> wrote:
I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key
(so other can decrypt) and keep private the public key (so only me
can encrypt).

Impossible.  Once someone has the private key, they can both encrypt
and decrypt.  It is impossible to "keep private" the public key since
it is trivially constructible from the private key.

Very well possible, if the public key doesn't follow a known pattern.
Less efficient, though.

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Yes.

With most implementations, but if he implements RSA himself, he could
select one exponent randomly (instead of a fixed one, as most
implementations do it), and calculate the other from it.

Regards,
Ertugrul.

--http://ertes.de/

I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key
(so other can decrypt) and keep private the public key (so only me
can encrypt).

Impossible. Once someone has the private key, they can both encrypt
and decrypt. It is impossible to "keep private" the public key since
it is trivially constructible from the private key.

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Yes.

I'm trying to use RSA algorithm in .NET. My needs are somehow
the inverse of the normal usage. I want to distribute the
private key (so other can decrypt) and keep private the public
key (so only me can encrypt).

Impossible.  Once someone has the private key, they can both
encrypt and decrypt.  It is impossible to "keep private" the
public key since it is trivially constructible from the private
key.

Very well possible, if the public key doesn't follow a known
pattern. Less efficient, though.

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Yes.

With most implementations, but if he implements RSA himself, he
could select one exponent randomly (instead of a fixed one, as most
implementations do it), and calculate the other from it.

Thanx Ertugurl, finally someone who really understand ecnryption. This
is exactly what I thought, but seeing a lot of people opposing it I
started to doubt myself.

Probably I will not use RSA directly as suggested by Joe, but the
important thing is to exactly understand what's going on behind the
scenes.
This question convinced me for 2 things:
- A lot of people claim to have knowledge on ecnryption but they know
only the surface of it...ecnrypt this, sign this other, etc...but do
not really know what's going on...and most of the material found in
net is not good.

- Very similar to this case is TCP/IP and routing. There are like
thousand of tools and protocols and standards and commands and all
this shit that are based on a very simple concept of TCP/IP packets
and knowledge of binary numbers. And there are millions of admins that
do not understand them...

Thanx Ertugurl, finally someone who really understand ecnryption. This
is exactly what I thought, but seeing a lot of people opposing it I
started to doubt myself.

According to Albert <Albert.Tollk... at (no spam) gmail.com>:

Thanx Ertugurl, finally someone who really understand ecnryption. This
is exactly what I thought, but seeing a lot of people opposing it I
started to doubt myself.

The human being who sometimes post here under the pseudonym of
"Pubkeybreaker" happens to be one of the top experts on RSA on this
planet. This means that his counsel should not be dismissed so easily.
If you have the impression either him or you did not fully understand
RSA, then it is most probably you.

"RSA" is a catch-all name which describes several things:

-- A mathematical mechanism which is usually described as a
"trapdoor permutation".

-- An asymmetric encryption protocol.

-- A digital signature protocol.

The core operation of RSA is the following: there is a (usually) big
integer, denoted "n", which is not prime. There are also two other
integers, "d" and "e", which are so that for all integers x between 0
(inclusive) and n (exclusive) then (x^e)^d = x mod n.

This function which, from x, computes x^e mod n is thus a permutation of
the space of integers from 0 to n-1. The inverse permutation is the
function which computes y^d mod n from y.

We call this a "trapdoor" permutation because computing x^e mod n
requires only knowledge of x, n and e; there is no need to know d.
Moreover, provided that some conditions are met (explained below), then
it is not feasible to compute the inverse permutation with only the
knowledge of n and e (i.e., given n, e and y^e mod n, nobody knows how
to compute y).

The conditions for RSA to be a trapdoor permutation (i.e. to realize
that infeasibility) are roughly the following:

-- The prime factors of n are not known by those who must not know the
trapdoor (i.e. those people for which computing the inverse permutation
is infeasible). In particular, this means that n must have been chosen
randomly "with sufficient uniformity" among the set of composite
integers which are the product of at least two large enough prime
numbers. Here, "large enough" means "at least 512 bits" and "with
sufficient uniformity" means that a great number of primes were usable.
A proper modulus generation procedure is no easy task; many real-life
systems were broken due to a suboptimal random choice.

-- e must be such that there exist no matching value of d which is small.
Note that for given values of n and e, there are several values of d
which realize the "(x^e)^d = x mod n" property. The precise notion of
"small" is not known, but attacks have been found when the length of
d is less than the third of the length of n. To be on the safe side,
the length of d is usually roughly equal to that of n.

-- The input values x must be part of a space which is not "too
special". It is not easy to characterize that property; a first easy
remark is that if the space is too small then it can be search
exhaustively. In plain words, if you use the trapdoor permutation as a
rough encryption function, and you encrypt either "yes" or "no", then an
attacker would just have to encrypt "yes" and "no" himself, and see
which encrypted word matches what was sent.

Hence, that RSA is a trapdoor permutation does not immediately turn
it into an encryption scheme. The RSA _encryption algorithm_ is
specified in PKCS#1, and it has the following properties:

-- There is a padding scheme, which transforms input _messages_ (i.e.
sequence of bytes with a given maximum size) into input _integers_ (the
"x" value above). That padding scheme includes a number of random bytes,
which makes the space of input values "unspecial enough" for security to
be achieved. A consequence is that two encryptions of the same input
message with the same n and e may not yield the same output integers.

-- The "private key" is defined as containing not only "d" but also
the prime factors of n, because using them allows for a roughly
four times faster decryption.

-- The "public key" is defined to be the n and e integers, and it so
happens that e can be chosen to be quite short, since it is public
anyway, and short exponents are better for performance.

Now you may try to use the trapdoor permutation "in reverse", i.e. have
someone _first_ compute the inverse permutation (with knowledge of d)
then publish it and have other people (using only n and e) perform the
reverse operation. This is the basis of RSA signatures, also described
in PKCS#1. There again, there is some difference between a mathematic
trapdoor permutation, and a cryptographic protocol which implements
digital signatures with security properties usually expected of digital
signatures. In particular, a padding scheme must be defined (_not_ the
same than for encryption, because needs are different). As was the case
for encryption, many early designs and systems were broken due to the
use of padding schemes which were not "good enough" (some did not use
any padding at all...).

If you want to use RSA "in reverse" then most probably you want RSA
signatures, and thirty years of research on that subject have shown that
transforming the RSA trapdoor permutation into a signature scheme with
adequate security is _not_ a trivial operation. Stick to PKCS#1 and you
will live longer and happier.

Otherwise, you _might_ have a novel idea on RSA for a usage mode which
is not a degenerate case of asymmetric encryption or signature. Which
would somehow make you one of the top experts on cryptography since many
have looked for novel usages of RSA, and failed, for the last few
decades. Chances are, however, that what you think about is no more than
some homemade degenerate signature scheme, and probably insecure since
designing a signature scheme is not an easy task. You would not be the
first to try, even in this very newsgroup sci.crypt.

--Thomas Pornin

On May 8, 3:01 pm, Albert <Albert.Tollk... at (no spam) gmail.com> wrote:
I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

Impossible. Once someone has the private key, they can both
encrypt and decrypt. It is impossible to "keep private" the public
key

since it is trivially constructible from the private key.

First of all is this secure?

Trivially insecure.

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Yes.

Pubkeybreaker wrote:
On May 8, 3:01 pm, Albert <Albert.Tollk... at (no spam) gmail.com> wrote:
I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

Impossible. Once someone has the private key, they can both
encrypt and decrypt. It is impossible to "keep private" the public
key

Why? Because it's "public"?

since it is trivially constructible from the private key.

Bollocks (unless the attacker knows the "public" key).

It's the same situation as a RSA signature - keep one key secret, and
let one key be known.

It don't matter what you call them, as long as they are long enough - in
fact the E and D keys are entirely interchangeable, if they are long
enough.


First of all is this secure?

Yes, at least as much as RSA is.

Trivially insecure.

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Yes.


No.

Not without knowing the factorisation of N (absent some other
maybe-attacks we don't know about on RSA).

If an attacker knows or can guess both keys then you are screwed -
otherwise, if he only knows one and can't guess the second, then it's
quantum computing, advances in factorisation, etc.

-- Peter Fairbrother

Pubkeybreaker wrote:
On May 8, 3:01 pm, Albert <Albert.Tollk... at (no spam) gmail.com> wrote:
I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

Impossible. Once someone has the private key, they can both
encrypt and decrypt. It is impossible to "keep private" the public
key

Why? Because it's "public"?

since it is trivially constructible from the private key.

Bollocks (unless the attacker knows the "public" key).

It's the same situation as a RSA signature - keep one key secret, and
let one key be known.

It don't matter what you call them, as long as they are long enough - in
fact the E and D keys are entirely interchangeable, if they are long
enough.

Pubkeybreaker wrote:
On May 8, 3:01 pm, Albert <Albert.Tollk... at (no spam) gmail.com> wrote:
I'm trying to use RSA algorithm in .NET. My needs are somehow the
inverse of the normal usage. I want to distribute the private key (so
other can decrypt) and keep private the public key (so only me can
encrypt).

Impossible. Once someone has the private key, they can both
encrypt and decrypt. It is impossible to "keep private" the public
key

Why? Because it's "public"?

since it is trivially constructible from the private key.

Bollocks (unless the attacker knows the "public" key).

It's the same situation as a RSA signature - keep one key secret, and
let one key be known.

It don't matter what you call them, as long as they are long enough -
in fact the E and D keys are entirely interchangeable, if they are
long enough.

First of all is this secure?

Yes, at least as much as RSA is.

Trivially insecure.

What I want to do is to keep E private and distribute D. Is it
possible that by having D the users can calculate E?

Yes.

No.

Not without knowing the factorisation of N (absent some other
maybe-attacks we don't know about on RSA).