Re: Basic question about RSA

William L. Bahn wrote:
I don't understand what you mean by saying that you never want to
encrypt raw message material. What's the alternative?

You "RSA Encrypt" padded data, usually padded with OAEP first. Why not
just clear up the wording. You exponentiate OAEP padded data with the
public key to encrypt.

I am using "message" as a generic label to keep the discussion
simple - but I can see how doing so can create confusion - and
didn't want to throw in a lot of system-level stuff involving
symmetric keys and hashes and message digests.

Yes, why involve "proper" crypto, it may confuse it.

You don't just do (m^d mod N)^e' mod N' to "sign and encrypt" with raw
messages 'm'. That's totally insecure. While it may work
mathematically it's weak against active adversaries.

Is there anything *conceptually* wrong with using an adequate
assymetric encryption algorithm as described? For instance, if we
had one that was as fast an symmetric algorithms and that didn't
expose the keys no matter how much material was encrypted.

Think about active attackers.

From a practical standpoint, I certainly understand that signing
a message by encrypting it with the private key using RSA is
extremely slow. IIRC, there are larger issues associated with
providing a lot of cipher text that has been RSA-encrypted - but
I'm not sure I'm remembering that correctly.

There is more than just speed issues with the system as described.

In practice - and I'm building this up as I type so please
correct me - if Alice wants to send Bob a message that is both
confidential and authenticated, one way is to first generate a
message digest and sign the digest using her private key. She
then appends the signed digest to the original message. She then
selects a symmetric key and encrypts the extended message with
the symmetric key. She then encrypts the symmetric key with Bob's
public key. She then sends the encrypted symmetric key and
message to Bob who first decrypts the symmetric key. Then, using
the symmetric key, he decrypts the remainder of the message. He
then separates and unsigns the message digest from the original
message. He can then generate a message digest of the original
message and compare it to the one that was unsigned. Of course,
Alice and Bob have to agree on this protocol in all of its fine
details, but that can be done over an open channel.

That sounds ok but isn't what you described and you still lack padding.
Even exponentiating random symmetric keys can lead to security
problems.

Tom

.

Relevant Pages

  • Re: Where to store private key
    ... There are, however, some known techniques which are ... However being quite new to security I still don't ... > Rijndael class to encrypt the data. ... >> uses underlying symmetric key encryption based on user principal ...
    (microsoft.public.dotnet.security)
  • Re: Encryption of messages between embedded system and PC?
    ... that will allow you to encrypt strings, ... No other party, not even the PC, can decrypt data ... The answer is "pieces of each frame ... frame using the symmetric cipher and the symmetric key of the cipher, ...
    (comp.arch.embedded)
  • Re: Java, MSCAPI interoperability - newbie
    ... A good solution (analogous to enveloped email) is to have the two parties have ... Then you can leverage RSA key-exchange protocol very easily. ... data with random symmetric key and encrypt the symmetric key with their local private RSA key ...
    (microsoft.public.platformsdk.security)
  • Re: RSA Encrypt/Decrypt Problems
    ... You can generate a snk for each and replicate the public key part to each ... Then sym encrypt your data with the key and iv and store in the ... You could actually do it with small blocks and only the public rsa key, ... > key) with the symmetric key embedded in the file and encrypted using the ...
    (microsoft.public.dotnet.security)
  • Re: Remote signing of large files
    ... about 'Remote signing of large files': ... the signing of this message digest. ... the encrypt() function. ... of the private key, or that the private key has been compromised.] ...
    (Debian-User)