Re: RSA keys, encryption and PGP-like cryptosystems




cwill wrote:
Can someone please help me understand (or confirm that I do understand) the
relationship between RSA keys and encryption keys in PGP-like cryptosystems?

By PGP-like crypto systems, I mean crypto systems that generate a random
encryption key, encrypt the plaintext with it, encrypt the random key with
the users RSA key and append that result to the file. First, do I have that
right? Is that what PGP does? (Assuming I'm not using conventional
encryption.)


That's the way a lot of cryptosystems work. I'm pretty sure PGP works
this way. RSA is slow compared to AES, but makes key management
easier. This way, you can generate a session key for AES and encrypt it
under the intended persons public key. You only have to deal with RSA
being slow for a small amount of data.


I understand that there are lots of components to a cryptosystem, and any
one of those parts can compromise security. In this case I want to confine
my thoughts to issues with the random number generator.

Yep, a big lock doesn't get you anything if you have a plastic chain.


If I use PGP to encrypt files and I don't want to use conventional
encryption, I first have to generate an RSA key for myself. I keep the
private part private and anyone can use the public part to encrypt messages
to me. Generating the private key is the first use of the random number
generator in this case, and a problem with the random number generator can
compromise the cryptosystem (e.g. if output of the random nunmber generator
could be predicted, an attack might recreate the computer environment that
existed when I generated the keypair and reproduce the private key). Without
commenting on the probablility of such an attack, is this a possibility to
be concerned with?


Yes, that is a real attack which has caused a lot of breaks in the real
world. Generating bad random numbers is one of the easiest ways to
collapse your security. Most modern operating systems provide means of
getting good random numbers by looking at things like keyboard timings,
mouse timings, hard disk interrupts, etc.

For an interesting example, look at David Wagner's break of SSL. An
early version of Netscape SSL used the time of day, process ID, and
parent process ID to generate keys. These are highly predictable (you
can just look at the time the connection was made for time of day, for
example). So even though SSL was using strong crypto, the attacker
could just guess what key was being generated.

See: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html


If that really is a problem (i.e. a particular PGP or other product version
is vulnerable to that type of attack) one possible solution is to generate
RSA keys separately, perhaps on another device with a "known good" random
number generator.


There are a number of companies that sell hardware devices that do
random number generation. It's not required for most people, as most
modern operating systems have ways of doing it, but for some users,
they do it all in specialized hardware.


But even with our fixed RSA key, we still have a problem with the
cryptosystem because of the random number generator. At least I think. That
problem being, the random number generator is still used to create the
actual encryption key, so if an attacked can bypass the RSA key encryption
by recreating the actual encryption key, the cryptosystem is still
compromised. Right?


Yep, he has a choice of attacking either RSA, or AES. If the random
number generator for either one of them is bad, he can get the message.


Is all of this mostly correct. Please tell me that I am at least thinking
about the right issues as I begin to learn about the security of
cryptosystems.


Yep, it's correct. There are even attacks called side channel attacks
where if an attacker can get a program to execute on your machine while
you are doing encryption, he can look at cache use and determine the
key. There are other side channel attacks where he can look and see how
much time encryption is taking and determine the key as well. All these
are sophisticated and generally require the attacker to be able to run
software on your machine (remote timing is possible though).

-Matt

.



Relevant Pages

  • Re: hiding a counter
    ... encryption scheme has this 'flaw'. ... However, the public key can, provably, also be used for decryption. ... cryptosystems try to address, namely, that, in order to communicate ... A brute force attack would still ...
    (comp.unix.programmer)
  • [Full-disclosure] Practical malleability attack against CBC-Encrypted LUKS partitions
    ... The most popular full disk encryption solution for Linux is LUKS, which provides an easy to use encryption layer for block devices. ... This article demonstrates how this can be used to inject a full remote code execution backdoor into an encrypted installation of Ubuntu 12.04 created by the alternate installer. ... This attack is known as evil maid attack and it has been demonstrated against Truecrypt. ...
    (Full-Disclosure)
  • RE: AES-256 encryption
    ... but brute-force attack against the cyphertext won't ... if the password used for encryption is a week password (like ... Need to secure your web apps NOW? ... buy it or download a solution FREE today! ...
    (Pen-Test)
  • Re: [Full-disclosure] Python ssl handling could be better...
    ... million and one attack scenarios where what you have is an observer, ... thereby only glimpsing NEW sessions at that point ... between authentication, encryption, and authentication + encryption. ...
    (Full-Disclosure)
  • Re: Question: storing a secret shared key with minimal storage
    ... > I'd like to make an automatic setup of harddisks, ... > storage media with minimal storage space - eg. a smartcard with only a ... it creates quite a penalty for a bad RSA key guess, ... You also need to be aware that disk encryption is not as easy as it at first ...
    (sci.crypt)