Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

Michael Hammer <> Thu, 23 January 2014 23:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 077391A0449 for <>; Thu, 23 Jan 2014 15:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NroVwkMYPaBZ for <>; Thu, 23 Jan 2014 15:19:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DD0771A035C for <>; Thu, 23 Jan 2014 15:19:04 -0800 (PST)
Received: from ([fe80::149d:c2e1:8065:2a47]) by ([::1]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 15:19:04 -0800
From: Michael Hammer <>
To: "" <>
Thread-Topic: [dsfjdssdfsd] Any plans for drafts or discussions on here?
Thread-Index: AQHPFik7i/q5nfCSa0yR/K7nGCDgcJqOvseAgAArLACAAqUWgIAAqIaAgAEY5AD//3wacIAApM6A//+D2yA=
Date: Thu, 23 Jan 2014 23:19:03 +0000
Message-ID: <>
References: <> <> <> <> <03f201cf17ee$e34ccbf0$a9e663d0$> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_011F_01CF184E.72EE4F90"
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2014 23:19:07 -0000

Hmmm...  that makes it sound rather subjective.
If we don't have objective measures, 
then who is to say that one's randomness is better or worse than another?

Understand that user data input may or may not have good entropy.
But, hope that would be the only source of any output entropy, 
given good encryption algorithms and random keys.

Was thinking in terms of how an app with access to alternate random sources,

some which might be from OS or from some software, might choose one over

Michael Hammer
Principal Engineer
Mobile: +1 408-202-9291
500 Yosemite Drive Suite 120
Milpitas, CA 95035 USA

-----Original Message-----
From: Krisztián Pintér [] 
Sent: Thursday, January 23, 2014 2:38 PM
To: Michael Hammer
Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

Michael Hammer (at Thursday, January 23, 2014, 9:49:32 PM):
> This may get off-topic, but are there good software tools for testing 
> entropy, that could help applications determine if the underlying 
> system is giving them good input?

disclaimer: i'm no expert, it is just what i gathered. (i'm pretty much
interested in randomness.)

short answer: no

long answer: in some situations yes. if you are handed a bunch of data, all
you can do is to try different techniques to put an upper limit on the
entropy. for example you can calculate the shannon entropy assuming
independent bits. then you can hypothesize some interdependence, and see if
you can compress the data. you can apply different lossless compression
methods. the better compression you find puts an upper limit on the entropy.
but never a lower limit.

you can only do better if you have an idea about the process that created
the data. for example you might assume that it is mostly thermal noise. you
can assume that thermal noise has some frequency distribution, or energy or
whatever, etc. within this assumption, you can determine the entropy content
by measurements. but at this point, you are pretty much prone to two errors:
1, what if your assumption is wrong and 2, what if your physical model
overestimates the unpredictability of the given system. example for the
former: the signal might be largely controllable by an external EM
interference, and then you measure not noise, but attacker controlled data.
example for the latter: a smartass scientist might come up with a better
physical model for thermal noise.

it is also important to note that entropy is observer dependent. we actually
talk about the entropy as seen by the attacker. but it is not
straightforward to assess what is actually visible to an attacker and what
is not. observation methods improve with time.