Re: Not enough salt for high speed server connection

From: Ernst Lippe (ernstl-at-planet-dot-nl_at_ignore.this)
Date: 07/07/03 

Date: Mon, 07 Jul 2003 18:35:46 +0200

On Sun, 06 Jul 2003 16:22:25 +0000, ds wrote:

> Since the applications do not have to connect to any outside standard,
> they are free to be of any design the management approves. The
> information is considered quite sensitive so strength of encryption is
> considered more important than speed.
>
> We had a blue sky meeting with the management and decided that a large
> amount of random salt should be used in the encryption algorithm to
> blind the sensitive data.

How is this salt used? And why do you need a large amount?
In many protocols random numbers are used as IV's, but
in most cases IV's are much smaller than the messages themselves.
What are the security requirements for the salt? Should
it be non-repeating or simply non-predictable for an attacker?
Is the security of your system compromised when the attacker
can determine the value afterward, or is it sufficient when
future values are unpredictable?

> This sounded like a reasonable approach but
> guaranteeing the quality of the salt is proving to be difficult since
> these applications are expected to run cross platform.
What are those platforms? On most Unix systems you could simply
use /dev/urandom.
 
> A simple prototype was developed that harvests high resolution timer
> discrepancies real time. Statistics were done on different pentium
> platforms using very large samples.

In general, it is not wise to rely on a single entropy source.
For example, an attacker might be able to influence these
timings by manipulating the load on the system.
Did you think of using the Intel RNG that is built-in on some
of their processors? Also most operating systems have
a lot of counters that you could use as well.

How did you transform these measurements? I hope that you
looked at Yarrow, because that is a very solid design.
 
> As you would expect the machines with higher clock speeds were able to
> produce much larger amounts of high quality salt then the slower
> machines. Since random salt generation is the limiting factor in
> encryption speed the disparity proved to be more of a problem then it
> might seem.
>
> My personal opinion was that we should upgrade the hardware so that
> salt generation would be uniformly generated by all machines involved
> with sensitive data. Budgetary constraints prevailed and we were
> asked to develop a tiered application instead.
>
> Ended up developing 4 tiers of connection hierarchy ON, MM, TT and
> W&S. The lowest tier machines W&S can not generate enough salt on
> their own so we have to halt the connection from the faster machines
> and do a remix of some of the salt (Wait & Stir). We tested the
> system and it worked well in beta although it naturally assumed a top
> down network flow with the fastest ON tier machines communicating
> critical data first.

How do you process this entropy from other machines? I hope that
you have taken some precautions against fake messages.

> Now everything would have been fine and the system would have passed
> final approval two months early and I would be on my way to the bank
> but. For final approval testing someone in their infinite wisdom
> decided to have the president of the company connected to a W&S
> server!

Are the servers not sufficiently secure that you could store
the state of the entropy pool between reboots? This
is a common approach on several systems.

Even when you are not comfortable with this it should be possible to
collect a few hundred bits of secure entropy on any computer in a
limited amount of time. Once you have collected these you could
generate random numbers by using these bits as the key for a strong
block cipher and use it to encrypt a counter. As long as you don't use
more values than the square root of the maximum value of the counter
(e.g. for a 16 byte block size this is 2^64) this should be secure for
most purposes. (One important exception would be if you would use
this for generating keys). An attacker would only be able to predict
future values when the key has been compromised, and if you use a
strong block cipher like AES, this is probably the least of your
worries.

Your story is a nice instance of Murphy's law.

greetings,

Ernst Lippe

Relevant Pages

  • Not enough salt for high speed server connection
    ... they are free to be of any design the management approves. ... guaranteeing the quality of the salt is proving to be difficult since ... As you would expect the machines with higher clock speeds were able to ...
    (sci.crypt)
  • Re: How to encrypt/decrypt a file
    ... Modified to use random IV value (and random salt). ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... However random IV (in addition to password's salt) is better and more secure solution anyway. ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... Mitch's sample doesn't use have salt that I was talking about, but a password salt is not redundand... ... get a cryptographically random salt (different for each encryption invocation) ... The question is, from a security perspective, should the IV also be derived from a RNGCryptoServiceProvider ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... That salt that Mitch used in his sample is a kind of savior :-). ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
Loading