magnifying unpredictability and common subexpressions
So I'm looking for a minimum cost transformation with _only_ the following characteristic: Given a set of m input bits X, produce a set of n output bits Y such that knowledge of some subset of X and Y gives a minimum knowledge of the remainder (of Y if that makes it simple, but of X would be nice). This is not unlike the all-or-nothing package transform proposed by Rivest; the basic idea is that you have to know all of X in order to know anything about Y - sort of. My first iteration is as follows: Let ^ represent xor. Let p be the exclusive or of all bits of x (i.e. the parity). Let Y = f(X), where f(x) = p ^ x Basically, each bit of Y is the xor of every _other_ bit of x (x was actually xored into p, so by xoring again, it cancels out) However, my problem is that no matter how few bits of X you know, you only have to guess one bit, p, in order to know the bits of Y that correspond to the bits you know of X. Let me be concrete; suppose that I know only bits 0 of X and bit 0 of Y. I can then compute p, and from that I can use any further knowledge of bits of X to compute corresponding bits of Y. Note that p = x[0] ^ y[0]. Then if I know x[1], I can reveal y[1] = p ^ x[1]. And so forth. Obviously I need something more complex. The problem seems to be that the equations for every bit y depend only on x and p; that is, if we know x, we only have to guess p once for the whole array. In a way, this reminds me of an idea I had earlier, whereby this variable p is what I call a common subexpression, a key which unlocks the equation, a sort of trapdoor. Suppose I had written Y = f(X) as follows: y[0] = x[1] ^ x[2] ^ x[3] ^ x[4] y[1] = x[0] ^ x[2] ^ x[3] ^ x[4] y[2] = x[0] ^ x[1] ^ x[3] ^ x[4] ... A novice may have not have realized that each bit of y depends _only_ on x ^ p, and that knowing or guessing p would reveal every bit of Y for each known bit of X, without having to know any other bit of X. Now, what I sometimes wonder is whether the equations and tables in things like DES or SHA-1 are not similar... a table allows for several boolean logic representations, and depending on which you pick for each output bit, it may be possible that a common subexpression like p falls out of the equations, minimizing the amount of unknowns, or the amount of compute power necessary to brute-force it. For a Feistel cipher like DES, one might pick different boolean logic representations in different rounds, to minimize the complexity of the equations you get at the end. This is why I don't try to design ciphers. I could possibly come up with some complicated-looking tables and equations, but I'd have no assurance that a simple common subexpression did not exist. Do I need to resort to a conventional hash like SHA-1? I am not convinced that it is necessary, or that I'd have any more assurance from SHA-1 than I'd have with a randomly-generated set of equations. Does it have to be random? Isn't there a regular structure I could exploit here? It seems like there should be! Randomly-generated equations remind me a bit of the following AI Koan: In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6. What are you doing?, asked Minsky. I am training a randomly wired neural net to play Tic-Tac-Toe, Sussman replied. Why is the net wired randomly?, asked Minsky. I do not want it to have any preconceptions of how to play, Sussman said. Minsky then shut his eyes. Why do you close your eyes?, Sussman asked his teacher. So that the room will be empty. At that moment, Sussman was enlightened. -- URL:http://www.subspacefield.org/~travis/ -- dharma advaita For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpdBhbOliHn7.pgp Description: PGP signature
ECC vs. D/H or RSA
Does anyone have information on: 1) The ECAES weakness that led to ECIES 2) Any known weaknesses of ECIES 3) Relative performance figures between ECC routines like ECIES and D/H (or possibly RSA, though IES is based on EC-DH) I can generate the last if these figures are not available. BTW, I noticed that the latest OpenSSL has some EC functions, including EC-DH IIRC. It does not have ECAES or ECIES though. References: http://en.wikipedia.org/wiki/ECIES http://www.secg.org/download/aid-385/sec1_final.pdf -- URL:http://www.subspacefield.org/~travis/ Tat Tvam Asi For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpvAz1RvHImk.pgp Description: PGP signature
Undocumented Bypass in PGP Whole Disk Encryption
http://it.slashdot.org/article.pl?sid=07/10/04/1639224from=rss Interesting quote: Jon Callas, CTO and CSO of PGP Corp., responded that this [previously undocumented] feature was required by unnamed customers and that competing products have similar functionality. -- URL:http://www.subspacefield.org/~travis/ Tat Tvam Asi For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpUavsYRK20D.pgp Description: PGP signature
Re: 307 digit number factored
On Mon, May 21, 2007 at 04:32:10PM -0400, Victor Duchovni wrote: On Mon, May 21, 2007 at 02:44:28PM -0400, Perry E. Metzger wrote: My take: clearly, 1024 bits is no longer sufficient for RSA use for high value applications, though this has been on the horizon for some time. Presumably, it would be a good idea to use longer keys for all applications, including low value ones, provided that the slowdown isn't prohibitive. As always, I think the right rule is encrypt until it hurts, then back off until it stops hurting... When do the Certicom patents expire? I really don't see ever longer RSA keys as the answer, and the patents are I think holding back adoption... They already expired. Some EC primitives in the latest OpenSSL. But why assume short ECC keys are stronger than long RSA? AFAIK, the only advantage of ECC is that the keys are shorter. The disadvantage is that it isn't as well studied. Although every time I read up on ECC, I understand it, and then within a few days I don't remember anything about it. I think they teflon coated those ideas somehow, because they don't stick. With EECDH one can use ECDH handshakes signed with RSA keys, but that does not really address any looming demise of 1024 bit RSA. Why can't they do something like El-Gamal? I'm not comfortable with RSA somehow. It seems fundamentally more complicated to me than DLP, and it's hard to get right - look at how many things there are in the PKCS for it. -- URL:http://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpBNtfcR3SYr.pgp Description: PGP signature
Re: kernel-level key management subsystem
On Tue, Oct 09, 2007 at 06:08:44PM +1300, Peter Gutmann wrote: how do you want access to the keys controlled? ACLs? Who sets the ACLs? Who can manage them? How are permissions managed? What's the UI for this? Under what conditions is sharing allowed? If sharing is allowed, how do you handle the fact that different apps (with different levels of security) could have access to the same keys? Do you derive keys from a master key? Do you migrate portions of the app functionality into the kernel to mitigate the problems with untrusted apps? How is key backup handled? What about [Another 5 pages of questions] Good stuff. I was hoping perhaps to stimulate a discussion on just these sorts of issues. There's a bit of interrelated stuff here; you can start with requirements, postulate some mechanisms, think about implications of their implementation, which leads to refining requirements. It's sure to be a learning experience. Maybe this isn't the best place to do that, but it seems to me that this group would be one of the best for ironing out the details, and would have a vested interest in any such management interface not suck. Ideally I'd like to be able to develop something for, say, Linux, and possibly integrate it with your open-source co-processor stuff. Once you've got a clear statement of exactly what you want to do (which in its most abstract form is solve an arbitrarily complex key management problem), implementation is almost trivial in comparison. Sure. Maybe that's a good question: what are the idioms in key management? Is there any similar work already that I could read up on? Where can I read up on current HSM functionality, offerings, features, etc.? Computers are useless; they can only give answers. -- Pablo Picasso -- URL:http://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpRDG3MxsVBo.pgp Description: PGP signature
Re: refactoring crypto handshakes (SSL in 3 easy steps)
On Tue, Nov 13, 2007 at 08:35:52AM +0200, [EMAIL PROTECTED] wrote: The extra messages might be irrelevant for cryptography, but they're not irrelevant for security or functionality. E.g. in SSL, you have capability/feature negotiation (cipher suites, trusted CAs, in TLS 1.2 also signature algorithms, etc.) So, this is a good place to attempt to use this method. Data to be sent: 1) supported capabilities on the client 2) supported capabilities on the server 3) negotiated capabilities Dependencies: 1) No dependencies (first message from client to server) 2) No dependencies (first message from server to client) 3) Depends on #1 and #2 Results: 3 messages 1-1.5 RTTs (one if there's a simultaneous open, which is rare) So unless I'm missing something, we're still at 3 messages. Aside: I would like to point out that TCP-based protocols have the latency disadvantage of having to do a 3-way handshake before transferring any data. If you were to design a new IP protocol, you could do the key exchange within the handshake, which would save 3 messages, but may be vulnerable to a resource-consumption attack on the CPU. I wonder if we here could develop a handshake that was cryptographically secure, resistant to CPU DoS now, and would be possible to adjust as we get faster at doing crypto operations to reduce latency even further. Basically an easy knob for balancing high latency and DoS resistance vs. crypto overhead and low latency. It should be adjustable on either end without altering the other. -- Life would be so much easier if it was open-source. URL:https://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgp8fMSK6gOb3.pgp Description: PGP signature
Re: refactoring crypto handshakes (SSL in 3 easy steps)
On Thu, Nov 15, 2007 at 10:28:43AM +0200, [EMAIL PROTECTED] wrote: There's a dependency from negotiated capabililities to the cryptographic things included in the first message from client to server (since e.g. what algorithm is used by the client, or even what certificate is selected, depends on these non-crypto capability/feature parts.) But as James pointed out, you could probably handle this in optimistic mode; i.e. make a guess what the negotiated capabilities are likely to be, and fall back to more RTTs if the guess is wrong. One could theoretically send all of the permutations prior to negotiation. However, there would be a bandwidth penalty, a privacy penalty (any listener knows all cryptographic identities), and a possible security penalty (if any of the supported methods are undesirably weak). However, if you only have strong ciphers and don't care about cryptographic identity protection, it could be useful. Note that all these weaknesses already exist, as they could be triggered by communicating with a less-capable client, or one controlled by an adversary. Whether or not it matters depends on some contextual details. (BTW, usually we also want the capability negotiation to be secure; SSL simply exchanges MACs of all messages once the key for MAC has been agreed on. Would this add 0.5 or 1RTT? Or perhaps there's some clever way to do it without additional RTT?) Schneier suggests keeping a running MAC over the entire datastream, the state of which is sent with each logical message. I think that's a simple and safe way to do it, and so there's no extra messages involved. You always check the MAC first, before operating on the data, and you abort whenever you receive one with a message with an invalid MAC. The MAC with each message attests to the integrity of all data ever sent over that connection, period. The obvious way - doing a specific step just to verify the handshake - is the kind of code-centric thinking that I'm trying to avoid. I'm having trouble finding the right words for it. Basically an encrypted network protocol is a language in which a transmission is syntactically correct if and only if all the security properties hold. In some ways current protocols are like a poorly-written language whose parser that needs a seperator character between statements instead of being able to detect the syntax error when it starts processing the following statement. Basically it lacks even a single symbol look-ahead. -- Life would be so much easier if it was open-source. URL:https://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpjHn1QEV8i0.pgp Description: PGP signature
crypto class design
So... supposing I was going to design a crypto library for use within
a financial organization, which mostly deals with credit card numbers
and bank accounts, and wanted to create an API for use by developers,
does anyone have any advice on it?
It doesn't have to be terribly complete, but it does have to be
relatively easy to use correctly (i.e. securely).
I was thinking of something like this:
class crypto_api
{
...
// developers call these based on what they're trying to do
// these routines simply call crypto_logic layer
Buffer encrypt_credit_card(Buffer credit_card_number, key_t key);
Buffer encrypt_bank_account(Buffer bank_account, key_t key);
Buffer encrypt_other(Buffer buffer, key_t key);
...
};
class crypto_logic
{
...
algo_default = ALGO_AES256CBC;
// encrypt with a given algorithm
Buffer encrypt(Buffer buffer, key_t key, algo_t aid = algo_default);
// calls different routines in crypto_implementation layer depending on
algorithm used
Buffer decrypt(Buffer buffer, key_t key);
...
};
class crypto_glue
{
...
// calls routines in libraries such as OpenSSL
// mostly wrappers that translate between our data types and theirs
Buffer aes256cbc-encrypt(...);
Buffer aes256cbc-decrypt(...);
...
};
The general idea is that crypto_api provides domain-specific APIs that
are easy for anyone to understand, that the logic layer allows for the
selection of different algorithms, and the glue layer is basically a
translation layer to underlying libraries.
It is very important that the API remain stable, because the code
base is large and owned by various groups.
One thing that I'm wondering is how to indicate (e.g.) the overhead in
terms of padding, or whatever, for various algorithms... or if it
matters. The old code had some really disturbing practices like
assuming that the output buffer was 16 octets bigger, and stuff like
that... scary.
Intend to skim the OpenSSL design and Gutmann's Design of a
Cryptographic Security Architecture for ideas.
Comments?
--
In God We Trust, All Others Must Provide Source Code
URL:https://www.subspacefield.org/~travis/ Eff the ineffable!
For a good time on my email blacklist, email [EMAIL PROTECTED]
pgp60d9I19hOd.pgp
Description: PGP signature
Re: crypto class design
On Wed, Dec 19, 2007 at 08:22:09AM +0100, Luis Martin wrote: I am not sure I understood what you want but here's my suggestion. The problem is that client code assumes that there is a fixed (constant) relationship between the size of the output and the size of the input, and does its own memory allocation for the output, and uses pointers. This makes it difficult to change that relationship safely; I basically have to track down and change all the calling code, which may be near-impossible. I think the right solution in this case is to pass objects and not pointers, unless performance dictates otherwise. But, are there similar assumptions implicit in the calling code which I can avoid through proper design, now? That having been said, your suggestion for a data type for this purpose, with semantically-useful subdivisions, is an interesting one; thank you (and everyone else who gave suggestions!) -- In God We Trust, All Others Must Provide Source Code URL:https://www.subspacefield.org/~travis/ Eff the ineffable! For a good time on my email blacklist, email [EMAIL PROTECTED] pgp89cGmO9kmW.pgp Description: PGP signature
crypto quotes
http://www.amk.ca/quotations/cryptography/ -- URL:https://www.subspacefield.org/~travis/ The stream is deaf, yet sings its melody for all to hear. For a good time on my email blacklist, email [EMAIL PROTECTED] pgpqS3cxnwgDl.pgp Description: PGP signature
delegating SSL certificates
So at the company I work for, most of the internal systems have expired SSL certs, or self-signed certs. Obviously this is bad. I know that if we had IT put our root cert in the browsers, that we could then generate our own SSL certs. Are there any options that don't involve adding a new root CA? I would think this would be rather common, and I may have heard about certs that had authority to sign other certs in some circumstances... -- URL:https://www.subspacefield.org/~travis/ Who Would Jesus Bomb? For a good time on my email blacklist, email [EMAIL PROTECTED] pgp62b6zjh4z9.pgp Description: PGP signature
presentations about encrypted storage
I've got two presentations I've given on encrypted storage technologies here: http://www.subspacefield.org/security/ There's also a book I'm writing, if anyone is interested. -- https://www.subspacefield.org/~travis/ I need a better strategy for being less analytical. For a good time on my email blacklist, email [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Pi, randomness, entropy, unpredictability
I've been working on the randomness and unpredictability this morning instead of doing my taxes, and found these links: http://crd.lbl.gov/~dhbailey/pi/ http://pisearch.lbl.gov/ The section on randomness, entropy, etc. is here: http://www.subspacefield.org/security/security_concepts.html#tth_sEc20 The formatting on the PDF is better: http://www.subspacefield.org/security/security_concepts.pdf Currently the section begins on page 72. Please tell me what you think. -- Crypto ergo sum. https://www.subspacefield.org/~travis/ My password is easy to remember; it's the digits of Pi. All of them. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
quantum cryptography broken?
http://www.kurzweilai.net/news/frame.html?main=/news/news_single.html?id%3D8471 Quantum cryptography broken KurzweilAI.net, April 20, 2008 Two Swedish scientsts, Jorgen Cederlof, now of Google, and Jan-Ake Larsson of Link In a paper published in IEEE Trans. Inf Theory, 54: 1735-1741 (2008), they point out that an eavesdropper could gain partial knowledge on the key in quantum cryptography that may have an effect on the security of the authentication in the later round. By accessing the quantum channel used in quantum cryptography, the attacker can change the message to be authenticated (since the message is influenced by attacker-initiated events on the quantum channel). This, combined with partial knowledge of the key (transmitted on the quantum channel), creates a potential security gap, they suggest. Their proposed solution: simply transmit an extra exchange of a small amount of random bits on the classical (Internet) channel. FAQ: http://www.mai.liu.se/~jalar/qkg/faq.html -- Crypto ergo sum. https://www.subspacefield.org/~travis/ My password is easy to remember; it's the digits of Pi. All of them. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Code makers and breakers of WWII era
http://news.cnet.com/2300-1029_3-6240826-1.html?tag=ne.gall.pg -- Crypto ergo sum. https://www.subspacefield.org/~travis/ Truth does not fear scrutiny or competition, only lies do. If you are a spammer, please email [EMAIL PROTECTED] to get blacklisted. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
Reading really old email, but have new information to add. On Wed, Oct 03, 2007 at 02:15:38PM +1000, Daniel Carosone wrote: Speculation: the drive always encrypts the platters with a (fixed) AES key, obviating the need to track which sectors are encrypted or not. Setting the drive password simply changes the key-handling. Implication: fixed keys may be known and data recoverable from factory records, e.g. for law enforcement, even if this is not provided as an end-user service. There was an interesting article in 2600 recently about ATA drive security. It's in Volume 26, Number 1 (Spring 2009). Sorry that I don't have an electronic copy. The relevant bit of it is that there are two keys. One key is for the user, and one (IIRC, it is called a master key) is set by the factory. IIRC, there was a court case recently where law enforcement was able to read the contents of a locked disk, contrary to the vendor's claims that nobody, even them, would be able to do so. The man in question had his drives sized by the FBI and they read the drives, uncovering emails between the man and his lawyer. He was suing the manufacturer for false advertising. Here are the links from the 2600 article: http://tinyurl.com/atapwd http://tinyurl.com/cmrrse http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml hdparm -security-erase-enhanced in Linux http://www.deadondemand.com/ http://www.vogon-investigation.com/password-cracker.htm -- Obama Nation | 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. pgpvh6qewOZcV.pgp Description: PGP signature
padding attack vs. PKCS7
http://www.matasano.com/log/1749/typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/ Towards the end of this rather offbeat blog post they describe a rather clever attack which is possible when the application provides error messages (i.e. is an error oracle) for PKCS7 padding in e.g. AES CBC-encrypted web authenticators that allows an adversary to attack the crypto one octet at a time. -- Obama Nation | 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. pgptls3HY1oR9.pgp Description: PGP signature
Re: Intercepting Microsoft wireless keyboard communications
On Tue, Dec 11, 2007 at 02:01:03PM -0500, j...@tla.org wrote: How many bits (not just data, also preamble/postamble, sync bits, etc.) is the keyboard sending for each keystroke anyway? FWIW, it is likely sending keyboard scan codes: http://en.wikipedia.org/wiki/Scancode It doesn't send the actual characters typed, because games and the like need to know when keys are depressed and released, not just what letter was typed. Here's an overview of keyboard input under Linux: http://www.subspacefield.org/~travis/keyboard/index.html -- Obama Nation | 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. pgpePeM4q7uNa.pgp Description: PGP signature
work factor calculation for brute-forcing crypto
Hi folks, Assume for a moment that we have a random number generator which is non-uniform, and we are using it to generate a key. What I'd like to do is characterize the work factor involved in brute-force search of the key space, assuming that the adversary has knowledge of the characteristics of the random number generator? The algorithm for this is simple: Let the array X represent the probabilities of the outcomes of the random number generator, sorted by probability, with x[0] being the probability of the most probable value. Then, for a given fraction of the messages n (0 n = 1): i = 0 m = 0 while (m + x[i]) n: m = m + x[i] i = i + 1 return (i - 1) + (n - m) / (m + x[i]) This return value represents the average number of decryption attempts required to guess the right key. If one wanted to round up, one could just return i instead of the last expression above, because the second term is always in (0, 1] I'm curious if there's a way to express this calculation as a mathematical formula, rather than an algorithm, but right now I'm just blanking on how I could do it. -- Obama Nation | 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. pgpJ4gqi6vQJo.pgp Description: PGP signature
phpwn: PHP cookie PRNG flawed (Netscape redux)
https://media.blackhat.com/bh-us-10/whitepapers/Kamkar/BlackHat-USA-2010-Kamkar-How-I-Met-Your-Girlfriend-wp.pdf Hey, another PRNG is broken. Raise your hand if you're surprised. -- A Weapon of Mass Construction 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. pgpXw4d3k1gaP.pgp Description: PGP signature
questions about RNGs and FIPS 140
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
Re: questions about RNGs and FIPS 140
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
