Re: questions about RNGs and FIPS 140

2010-09-07 Thread Thierry Moreau

Ben Laurie wrote:

On 27/08/2010 19:38, Joshua Hill wrote:

The fact is that all of the approved deterministic RNGs have places that
you are expected to use to seed the generator.  The text of the standard
explicitly states that you can use non-approved non-deterministic RNGs
to seed your approved deterministic RNG.


This is nice.


It's an even better situation if you look at the modern deterministic RNGs
described in NIST SP800-90. (You'll want to use these, anyway.  They are
better designs and last I heard, NIST was planning on retiring the other
approved deterministic RNGs.) Every design in SP800-90 requires that your
initial seed is appropriately large and unpredictable, and the designs all
allow (indeed, require!) periodic reseeding in similarly reasonable ways.


Given that we seem to have agreed that unpredictable is kinda hard,
I'm amused that SP800-90 requires it. If it is a requirement then I
wonder why NIST didn't specify how to generate and validate such a seed?



Well, I find SP800-90 Annex C (Entropy and Entropy Sources) quite clear 
about the requirements. If nothing is approved, we may guess it's 
because no unpredictable phenomenon has been shown (convincingly) to be 
compliant.


In terms of solution documentation requirements, I see four stages:
1) unpredictable phenomenon,
2) sensor technology,
3) digitalization,
4) conditioning.

I separate 2 and 3 while NIST seems to merge them. I see them separate 
since the sensor technology is seldom developed with the entropy 
collection application in mind (the unpredictable phenomenon is not 
engineered: it just exists). The digitalization refers to the 
algorithmic processing taking raw A-to-D (analog to digital) data and 
giving some discrete measurement of the unpredictable phenomenon. This 
measurement is basically a convenient intermediate representation using 
a physical characteristic that is better understood, for analysis 
purposes, than the raw A-to-D data.


The digitalization algorithm may be the same as for pre-existing uses of 
the sensor technology, in which case an after-the-fact certification is 
challenging.


NIST seems to favor very well defined algorithms for affixing the NIST 
approved mark. The, the digitalization algorithm for a given pair 
unpredictable phenomenon,sensor technology may be challenging.


I released (a few days ago) a specification document for digitalization 
and conditioning algorithms for PUDEC, Practical Use of Dice for Entropy 
Collection, see http://www.connotech.com/doc_pudec_algo.html


Incidentally, another difficulty is that confidence in the entropy 
collection function is difficult to support with boot time / run time 
testing. IIRC, the statistical testing at boot time had to be dropped 
from the FIPS140 requirements because false failures (intrinsic to 
statistical testing) were not manageable in an operational context.


Obviously, there are other considerations to NIST approval because it 
would become a procurement specification for the US Federal government.





Cheers,

Ben.




Regards,

--
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-09-05 Thread Ben Laurie
On 27/08/2010 19:38, Joshua Hill wrote:
 The fact is that all of the approved deterministic RNGs have places that
 you are expected to use to seed the generator.  The text of the standard
 explicitly states that you can use non-approved non-deterministic RNGs
 to seed your approved deterministic RNG.

This is nice.

 It's an even better situation if you look at the modern deterministic RNGs
 described in NIST SP800-90. (You'll want to use these, anyway.  They are
 better designs and last I heard, NIST was planning on retiring the other
 approved deterministic RNGs.) Every design in SP800-90 requires that your
 initial seed is appropriately large and unpredictable, and the designs all
 allow (indeed, require!) periodic reseeding in similarly reasonable ways.

Given that we seem to have agreed that unpredictable is kinda hard,
I'm amused that SP800-90 requires it. If it is a requirement then I
wonder why NIST didn't specify how to generate and validate such a seed?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-27 Thread Thomas
Hello.

Am Donnerstag 26 August 2010 12:25:55 schrieb Jerry Leichter:
[...]
  4) What about VMs?
  Rolling back a deterministic RNG on those systems gives the same
  values unless/until you re-seed with something new to this iteration
 
 I'm not sure what you mean by rolling back.  Yes, if you restart any
 deterministic RNG with a previously-used internal state, it will
 generate the same stream it did before.  This is true whether you are
 in a VM or not.

That is true.
Luckily /dev/random is re-seeded during run-time. So even if you do
a roll-back of a system and the new input it non-deterministic it will
generate different output immediately.


 RNG's in VM's are a big problem because the unpredictable values
 used in the non-deterministic parts of the algorithms - whether you
 use them just for seeding or during updating as well - are often much
 more predictable in a VM than a real machine.  (For example, disk
 timings on real hardware have some real entropy, but in a VM with an
 emulated disk, that's open to question.)

I really doubt it. Are there papers about it?
It does not matter if there is one physical disk that is shared
between 1000 processes or between 10 VMs each running 100 processes
(assuming a shared random pool).
The entropy is not generated by the disk but by the processes accessing
it in a (hopefully) non-deterministic way. The HDD interrupts are just
the sampling point. Therefore gaining entropy depends on the level of 
abstraction where the sampling point is placed. It can be assumed that
the buffered HDD writing and reading on the host of a VM produce
less entropy than the real read(2) and write(2) calls within the VM
itself.


Bye
Thomas

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-27 Thread Thor Lancelot Simon
On Fri, Aug 27, 2010 at 07:20:06PM +1200, Peter Gutmann wrote:
 
 No.  If you choose your eval lab carefully you can sneak in a TRNG somewhere
 as input to your PRNG, but you can't get a TRNG certified, and if you're
 unlucky you won't be allowed to use a TRNG at all.

I am surprised you'd have trouble with this at any lab.  Isn't there
specific guidance on this in the DTRs?  My 10-years-rusty recollection
is that, specifically, the input used to key the Approved RNG may not
contain provably less entropy than the Approved RNG's output, or words
very close to that in effect.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Steven Bellovin

On Aug 25, 2010, at 4:37 16PM, travis+ml-cryptogra...@subspacefield.org wrote:

 
 3) Is determinism a good idea?
 See Debian OpenSSL fiasco.  I have heard Nevada gaming commission
 regulations require non-determinism for obvious reasons.

It's worth noting that the issue of determinism vs. non-determinism is by no 
means clearcut.  You yourself state that FIPS 140-2 requires deterministic 
PRNGs; I think one can rest assured that the NSA had a lot of input into that 
spec.  The Clipper chip programming facility used a PRNG to set the unit key -- 
and for good reasons, not bad ones.

--Steve Bellovin, http://www.cs.columbia.edu/~smb





-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Jerry Leichter
On Aug 25, 2010, at 4:37 PM, travis+ml-cryptogra...@subspacefield.org  
wrote:


I also wanted to double-check these answers before I included them:

1) Is Linux /dev/{u,}random FIPS 140 certified?
No, because FIPS 140-2 does not allow TRNGs (what they call non- 
deterministic).  I couldn't tell if FIPS 140-1 allowed it, but FIPS  
140-2 supersedes FIPS 140-1.  I assume they don't allow non- 
determinism because it makes the system harder to test/certify, not  
because it's less secure.
No one has figured out a way to certify, or even really describe in a  
way that could be certified, a non-deterministic generator.



3) Is determinism a good idea?
See Debian OpenSSL fiasco.  I have heard Nevada gaming commission
regulations require non-determinism for obvious reasons.


IPS doesn't tell you how to *seed* your deterministic generator.  In  
effect, a FIPS-compliant generator has the property that if you start  
it with an unpredictable seed, it will produce unpredictable values.   
Debian's problem was that it violated the if condition.  The  
determinism of the algorithm that produced subsequent values wasn't  
relevant.



4) What about VMs?
Rolling back a deterministic RNG on those systems gives the same
values unless/until you re-seed with something new to this iteration.


I'm not sure what you mean by rolling back.  Yes, if you restart any  
deterministic RNG with a previously-used internal state, it will  
generate the same stream it did before.  This is true whether you are  
in a VM or not.


RNG's in VM's are a big problem because the unpredictable values  
used in the non-deterministic parts of the algorithms - whether you  
use them just for seeding or during updating as well - are often much  
more predictable in a VM than a real machine.  (For example, disk  
timings on real hardware have some real entropy, but in a VM with an  
emulated disk, that's open to question.)


We had a long discussion on this list a couple of weeks back which  
came to the conclusion that a hidden, instance-specific state, saved  
across reboots; combined with (fairly minimal) entropy at boot time;  
was probably a very good way to go.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: Is determinism a good idea? WAS: questions about RNGs and FIPS 140

2010-08-26 Thread Thierry Moreau

travis+ml-cryptogra...@subspacefield.org wrote:

Hey all,


I also wanted to double-check these answers before I included them:


3) Is determinism a good idea?
See Debian OpenSSL fiasco.  I have heard Nevada gaming commission
regulations require non-determinism for obvious reasons.


Do those sound right?



I guess the more productive question is Since determinism requires a 
PRNG algorithm of some sort, which PRNG properties are needed in a given 
usage context?


In all cases, the PRNG relies on a true random source for seeding.


You refer to IT security clients (SSL fiasco), IT security servers 
(virtualization), and lottery/gaming systems. In IT security nowadays 
large PRNG periods and crypto-strength PRNG algorithm are the norm. As I 
understand the state of the art in lottery/gaming industry (incl. 
standards), it is an accepted practice to use short period (by IT 
security standards) PRNG combined with a form of continuous entropy 
collection: background exercise of the PRNG.


I think the SSL fiasco root cause analysis would remind us of criteria 
that are nowadays well addressed in the IT security sector (assuming 
minimal peer review of the design and implementation).



In a security analysis, you watch for data leaks, either in the source 
of truly unpredictable events, or the present/past PRNG state for the 
deterministic components of your design. If you already need data leak 
protection for private or secret keys, your system design may already 
have the required protections for the PRNG state (except that the PRNG 
state is both long-term -- as a long-term private key or long-term 
symmetric authentication key -- and updated in the normal system 
operations -- as session keys).



So, there is no simple answer. I guess every designs facing actual 
operational demands rely on some determinism because a sudden surge in 
secret random data usage is hard to fulfill otherwise.



Forgive me to remind the PUDEC (Practical Use of Dice for Entropy 
Collection) which mates well with a server system design using PRNG 
determinism after installation (or periodic operator-assisted 
maintenance). This project is still active. See 
http://www.connotech.com/doc_pudec_descr.html . You may see this as a 
bias in my opinions, but I don't see any benefits in misrepresenting 
relevant facts and analyzes.



Regards,


--
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread travis+ml-cryptography
On Thu, Aug 26, 2010 at 06:25:55AM -0400, Jerry Leichter wrote:
 [F]IPS doesn't tell you how to *seed* your deterministic generator.  In  
 effect, a FIPS-compliant generator has the property that if you start it 
 with an unpredictable seed, it will produce unpredictable values.   

That brings up an interesting question... if you have a source of
unpredictable values in the first place, why use a CSPRNG? ;-)

Actually, I know I'm being snarky; I'm aware that they're handy for
stretching your random bits, if you don't have enough for the task.

I suppose some people feel they're also handy for whitening them, so
that if they're not entirely random, the structure isn't completely
obvious from the output alone, but I think that's probably a separate
property that needs to be evaluated independent of the others.

Last I checked Linux /dev/{u,}random uses SHA-1 hash over the pool,
which suggests they had this in mind.  However, it also makes using it
very slow for wiping disks or any other high-bandwidth tasks, at least
when compared to something like Yarrow.

I heard from a colleague that /dev/urandom exists on Android, but
/dev/random does not.  Our best guess is that it's the same as the
standard Linux /dev/urandom, but we're not really sure.  Presumably
they dumped /dev/random because there just weren't enough sources of
unpredicability on that platform.  I'd like to hear from anyone who
knows details.

Also, please do check out the links about RNGs on the aformentioned
page.  Seth Hardy's /dev/erandom looks very interesting, and has
languished in relative obscurity for nearly a decade.

I'll take the rest of my comments to this list:
http://lists.bitrot.info/mailman/listinfo/rng
-- 
It asked me for my race, so I wrote in human. -- The Beastie Boys
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email j...@subspacefield.org to get blacklisted.


pgp9yzKJ9OT7R.pgp
Description: PGP signature


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Alexander Klimov
On Wed, 25 Aug 2010 travis+ml-cryptogra...@subspacefield.org wrote:
 No, because FIPS 140-2 does not allow TRNGs (what they call 
 non-deterministic).
 I couldn't tell if FIPS 140-1 allowed it, but FIPS 140-2 supersedes FIPS 
 140-1.
 I assume they don't allow non-determinism because it makes the system harder
 to test/certify, not because it's less secure.

I guess you misinterpret it. In no place 140-2 does not allow
TRNG.  It says that nondeterministic RNGs should be used
*only* for IVs or to seed deterministic RNGs:

http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf:

  Until such time as an Approved nondeterministic RNG standard
  exists, nondeterministic RNGs approved for use in classified
  applications may be used for key generation or to seed
  Approved deterministic RNGs used in key generation.
  Commercially available nondeterministic RNGs may be used for
  the purpose of generating seeds for Approved deterministic
  RNGs.  Nondeterministic RNGs shall comply with all applicable
  RNG requirements of this standard.

  An Approved RNG shall be used for the generation of
  cryptographic keys used by an Approved security function.  The
  output from a non-Approved RNG may be used 1) as input (e.g.,
  seed, and seed key) to an Approved deterministic RNG or 2) to
  generate initialization vectors (IVs) for Approved security
  function(s).  The seed and seed key shall not have the same
  value.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Perry E. Metzger
On Thu, 26 Aug 2010 08:14:26 -0700
travis+ml-cryptogra...@subspacefield.org wrote:
 On Thu, Aug 26, 2010 at 06:25:55AM -0400, Jerry Leichter wrote:
  [F]IPS doesn't tell you how to *seed* your deterministic
  generator.  In effect, a FIPS-compliant generator has the
  property that if you start it with an unpredictable seed, it will
  produce unpredictable values.

 That brings up an interesting question... if you have a source of
 unpredictable values in the first place, why use a CSPRNG? ;-)

The rationale is clear, but I'll explain it again.

Say you are deploying a small security device into the field.

It is trivial to validate that an AES or SHA256 implementation on the
device is working correctly and to generate a seed in the factory to
place on the device to give it an operational lifetime of good
enough random numbers.

It is difficult to validate that a hardware RNG is working
correctly. How do you know the bits being put off aren't skewed
somehow by a manufacturing defect? How do you know that damage in the
field won't cause the RNG to become less random?

It is therefore both cheaper and far safer to use a deterministic
algorithm on the field deployable unit coupled with a high quality
seed from a source used only at the factory that you can spend time,
effort and money validating properly.

This same principle applies to things like virtual machines where it
is difficult to know that your hardware is giving you what you expect
but trivial to install a known-good seed at VM creation time.

I would have thought by now that this principle was widely understood.


Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Eric Murray
On Thu, Aug 26, 2010 at 12:13:06PM -0400, Perry E. Metzger wrote:
 It is difficult to validate that a hardware RNG is working
 correctly. How do you know the bits being put off aren't skewed
 somehow by a manufacturing defect? How do you know that damage in the
 field won't cause the RNG to become less random?

FIPS 140-1 did allow non-deterministic HW RNGs.  If you used one
then you had to run a boot-time self-test which, while not even close to an
exhaustive RNG test, would hopefully detect a HW RNG that had failed.


Eric

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread dj


 3) Is determinism a good idea?
 See Debian OpenSSL fiasco.  I have heard Nevada gaming commission
 regulations require non-determinism for obvious reasons.


The Nevada rules don't convincingly demand non determinism. They do say
things that probably unintentionally exclude non determinism.

4. The random number generator and random selection process must be
impervious to influences from outside the device, including, but not
limited to, electro-magnetic interference, electro-static interference,
and radio frequency interference. A gaming device must use
appropriate communication protocols to protect the random number generator
and random selection process from influence by associated equipment which
is conducting data communications with the gaming device.
(Adopted: 9/89. Amended: 11/05; 11/17/05.)


An impossible requirement for a TRNG based on physical processes. This
requirement pretty much demands determinism and in practice is untestable.

Some definitions..

23. “Randomness” is the observed unpredictability and absence of pattern
in a set of elements or events that have definite probabilities of
occurrence.

 and

20. “Random Number Generator” is a hardware, software, or combination
hardware and software device for generating number values that exhibit
characteristics of randomness.

Definitions that both a TRNG and a PRNG can meet. They don't get down to
the nitty gritty of what the observer might know, like the internal state
of a PRNG, that would impact whether the data has 'observed
upredictability'.

14.040 Minimum standards for gaming devices..
[]
2. Must use a random selection process to determine the game outcome of
each play of a game. The random selection process must meet 95 percent
confidence limits using a standard chi-squared test for goodness of fit.
(a) Each possible permutation or combination of game elements which
produce winning or losing game outcomes must be available for random
selection at the initiation of each play.
(b) For gaming devices that are representative of live gambling games, the
mathematical probability of a symbol or other element appearing in a game
outcome must be equal to the mathematical probability of that symbol or
element occurring in the live gambling game. For other gaming devices, the
mathematical probability of a symbol appearing in a position in any game
outcome must be constant. (c) The selection process must not produce
detectable patterns of game elements or detectable dependency upon any
previous game outcome, the amount wagered, or upon the style or method of
play.


Again, a PRNG would meet these requirements. The only specific test
proposed is the Chi-square GOF.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Thierry Moreau

Nicolas Williams wrote:

On Thu, Aug 26, 2010 at 06:25:55AM -0400, Jerry Leichter wrote:

On Aug 25, 2010, at 4:37 PM,
travis+ml-cryptogra...@subspacefield.org wrote:

I also wanted to double-check these answers before I included them:

1) Is Linux /dev/{u,}random FIPS 140 certified?
No, because FIPS 140-2 does not allow TRNGs (what they call non-
deterministic).  I couldn't tell if FIPS 140-1 allowed it, but
FIPS 140-2 supersedes FIPS 140-1.  I assume they don't allow non-
determinism because it makes the system harder to test/certify,
not because it's less secure.

No one has figured out a way to certify, or even really describe in
a way that could be certified, a non-deterministic generator.


Would it be possible to combine a FIPS 140-2 PRNG with a TRNG such that
testing and certification could be feasible?

I'm thinking of a system where a deterministic (seeded) RNG and
non-deterministic RNG are used to generate a seed for a deterministic
RNG, which is then used for the remained of the system's operation until
next boot or next re-seed.  That is, the seed for the run-time PRNG
would be a safe combination (say, XOR) of the outputs of a FIPS 140-2
PRNG and non-certifiable TNG.

factory_prng = new PRNG(factory_seed, sequence_number, datetime);
trng = new TRNG(device_path);
runtime_prng = new PRNG(factory_prng.gen(seed_size) ^ trng.gen(seed_size), 0, 
0);

One could then test and certify the deterministic RNG and show that the
non-deterministic RNG cannot destroy the security of the system (thus
the non-deterministic RNG would not require testing, much less
certification).

To me it seems obvious that the TRNG in the above scheme cannot
negatively affect the security of the system (given a sufficiently large
seed anyways).

Nico


Such implementations may be *certified* but this mode of CSPRNG seeding 
is unlikely to get *NIST*approved*. Cryptographic systems are 
*certified* with by-the-seat-of-the-pant CSPRNG seeding strategies (I 
guess) since crypto systems *are* being certified.


The tough part is to describe something with some hope of acquiring the 
*NIST*approved* status at some point. The above proposal merely shifts 
the difficulty to the TRNG. Practical Use of Dice for Entropy Collection 
is unique because the unpredictable process (shuffling dice) has clear 
and convincing statistical properties.


- Thierry Moreau

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: questions about RNGs and FIPS 140

2010-08-26 Thread Eric Murray
On Thu, Aug 26, 2010 at 11:21:35AM -0500, Nicolas Williams wrote:
 Would it be possible to combine a FIPS 140-2 PRNG with a TRNG such that
 testing and certification could be feasible?

Yes.  (assuming you mean FIPS certification).
Use the TRNG to seed the approved PRNG implementation.


 I'm thinking of a system where a deterministic (seeded) RNG and
 non-deterministic RNG are used to generate a seed for a deterministic
 RNG, which is then used for the remained of the system's operation until
 next boot or next re-seed.  That is, the seed for the run-time PRNG
 would be a safe combination (say, XOR) of the outputs of a FIPS 140-2
 PRNG and non-certifiable TNG.

That won't pass FIPS.  It's reasonable from a security standpoint,
(although I would use a hash instead of an XOR), but it's not FIPS 140
certifiable.

Since FIPS can't reasonably test the TRNG output, it can't
be part of the output.  FIPS 140 is about guaranteeing a certain 
level of security, not maximizing security.

Eric

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


questions about RNGs and FIPS 140

2010-08-25 Thread travis+ml-cryptography
Hey all,

Looking for feedback on this section on RNGs:
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc29
Equations are broken in HTML, but clear in PDF:
http://www.subspacefield.org/security/security_concepts/security_concepts.pdf
I am aware the Renyi entropy link is broken.

I also wanted to double-check these answers before I included them:

1) Is Linux /dev/{u,}random FIPS 140 certified?
No, because FIPS 140-2 does not allow TRNGs (what they call non-deterministic).
I couldn't tell if FIPS 140-1 allowed it, but FIPS 140-2 supersedes FIPS 140-1.
I assume they don't allow non-determinism because it makes the system harder
to test/certify, not because it's less secure.

2) Is CryptGenRandom certified?
Yes - is that because they have a deterministic mode?  Wikipeda makes it sound
like this closed-design system seeds from system timings and other stuff, which
would seem to make it non-deterministic as far as FIPS 140 testing is concerned.

3) Is determinism a good idea?
See Debian OpenSSL fiasco.  I have heard Nevada gaming commission
regulations require non-determinism for obvious reasons.

4) What about VMs?
Rolling back a deterministic RNG on those systems gives the same
values unless/until you re-seed with something new to this iteration.

Do those sound right?
-- 
It asked me for my race, so I wrote in human. -- The Beastie Boys
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email j...@subspacefield.org to get blacklisted.


pgp3mbtjlj8Kf.pgp
Description: PGP signature