Entropy distribution using SSM (source-specific multicast)
Project description
Introduction
------------
This is an experiment with using source specific multicast to distribute
high-quality entropy to consumers. The package contains a single script which
can act as both a sender and receiver.
Installation
------------
# pip install ssmrandom
In order for this to work your network and hosts must be able to support
SSM which in turn requires IGMP v3. For modern Linux and Windows this is
enabled by default. For some network equipment (eg juniper) you must enable
IGMP v3 explicitly (v2 is the default).
Quick Start
-----------
On the entropy producer (using the default multicast group and port):
# ssmrandom send -r /dev/urandom -t 32 -g 232.0.1.100 -p 49999 -L info
On the entropy consumer(s):
# ssmrandom recv -o /var/run/rnd-pipe -g 232.0.1.100 -p 49999 <ip-of-producer>
# rngd --rng-device=/var/run/rnd-pipe --rng-driver=stream --fill-watermark=90% --feed-interval=1
The idiots entropy distribution protocol (IEDP):
------------------------------------------------
Messages are JSON objects with 3 keys:
- v (version): the protocol version - '1.0' for this version
- s (source): identifies the source of the random data, eg the name of a hw device
- d (data): base64-encoded random data
Example
{'s': '/dev/qrandom0','v':'1.0','d': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'}
For security this can be signed, which is the reason for having framing at all.
Security issues
---------------
Collecting and adding external data to your entropy pool is a tricky issue. Adding
multicast to the mix makes it quite hard to analyze. This experiment is trying to
investigate the properties of a system for distributing entropy in an efficient and
way. A couple of issues that are being investigated:
- how much entropy do you have to consume in order to pick a random sample
from the multicast feed?
- how expensive would it be to validate signatures on each json mesage?
- how good is rngtools at picking up bad entropy?
News
====
0.3
----
*Release date: Fri Aug 17 15:12:12 CEST 201*
* support for redundant transmitters
* debian packaging
* + lots of minor fixes and cleanups
0.2
-----
*Release date: Thu Aug 16 11:02:35 CEST 2012*
* First public release
------------
This is an experiment with using source specific multicast to distribute
high-quality entropy to consumers. The package contains a single script which
can act as both a sender and receiver.
Installation
------------
# pip install ssmrandom
In order for this to work your network and hosts must be able to support
SSM which in turn requires IGMP v3. For modern Linux and Windows this is
enabled by default. For some network equipment (eg juniper) you must enable
IGMP v3 explicitly (v2 is the default).
Quick Start
-----------
On the entropy producer (using the default multicast group and port):
# ssmrandom send -r /dev/urandom -t 32 -g 232.0.1.100 -p 49999 -L info
On the entropy consumer(s):
# ssmrandom recv -o /var/run/rnd-pipe -g 232.0.1.100 -p 49999 <ip-of-producer>
# rngd --rng-device=/var/run/rnd-pipe --rng-driver=stream --fill-watermark=90% --feed-interval=1
The idiots entropy distribution protocol (IEDP):
------------------------------------------------
Messages are JSON objects with 3 keys:
- v (version): the protocol version - '1.0' for this version
- s (source): identifies the source of the random data, eg the name of a hw device
- d (data): base64-encoded random data
Example
{'s': '/dev/qrandom0','v':'1.0','d': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'}
For security this can be signed, which is the reason for having framing at all.
Security issues
---------------
Collecting and adding external data to your entropy pool is a tricky issue. Adding
multicast to the mix makes it quite hard to analyze. This experiment is trying to
investigate the properties of a system for distributing entropy in an efficient and
way. A couple of issues that are being investigated:
- how much entropy do you have to consume in order to pick a random sample
from the multicast feed?
- how expensive would it be to validate signatures on each json mesage?
- how good is rngtools at picking up bad entropy?
News
====
0.3
----
*Release date: Fri Aug 17 15:12:12 CEST 201*
* support for redundant transmitters
* debian packaging
* + lots of minor fixes and cleanups
0.2
-----
*Release date: Thu Aug 16 11:02:35 CEST 2012*
* First public release
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
ssmrandom-0.3.tar.gz
(5.8 kB
view details)
File details
Details for the file ssmrandom-0.3.tar.gz
.
File metadata
- Download URL: ssmrandom-0.3.tar.gz
- Upload date:
- Size: 5.8 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | d1f66ff7a6d42d21bdf4862992d582f7f84d99ba8c498381bf2e7c69e4fe675e |
|
MD5 | 6fe3cb8b4354930f14337ab554950974 |
|
BLAKE2b-256 | f52915066d9c2e031378d6c742a38c1f200be733d640d3870405d7a965c3c477 |