3 ms·

Ultimately the answer is no, because your question is predicated on a nonexistent distinction. A combination of algorithms is simply a new, more complex algori

Ultimately the answer is no, because your question is predicated on a nonexistent distinction. A combination of algorithms is simply a new, more complex algorithm. It may be an obvious and safe algorithm that enhances security, like Truecrypt's option of an AES/Twofish/Serpent cascade, or it may be a totally worthless algorithm -- like if you created a new "hashing" algorithm that consisted of CRC32 followed by SHA256. As that second example demonstrates, the naïve way of combining hashing algorithms is obviously not safe. If you simply layer them, any one of them could destroy entropy by producing biased/predictable results. Your new algorithm is crippled. If you try to "mix" them in some other way, all you've done is create a new hashing algorithm and fed it the output of other hashing algorithms. It's perhaps less likely that any one of those sub-algorithms will seriously cripple your system, but it's much more likely that you've made a mistake, and your new algorithm itself produces poor results. Somewhere along the way, you end up trusting something, even if it's your own algorithm. But since trusting yourself to get crypto right is a bad idea, the next best thing is to trust a well-vetted hashing algorithm, of which there are several that are likely "good enough", and aren't even NSA designed. If you're super-paranoid about backdoors, RIPEMD-160 might be your best bet -- it's a product of European academia. It gets some use, but not as much cryptanalysis as the SHA family has.

contingencies 13y ago
your question is predicated on a nonexistent distinction. A combination of algorithms is simply a new, more complex algorithm. That's true if you combine multiple algorithms conventionally, for example by feeding inputs from one to the other or by passing the original entropy to the two algorithms in parallel. However, if you run one algorithm independently of another - with completely different entropy sources - then flip between supplying the output of each in rapid succession, then on the face of it for ~50% overheads you have probably mostly mitigated exploitable vulnerabilities in either of the two single PRNGs for most applications. (Optionally add another for more security, and take it a step further...) You are right that this would need to be done carefully .. perhaps the flip in which PRNG is used for the output stream occurs at hard-to-predict points in time (the range of periods for which, potentially, might be carefully chosen from a range that takes in to account some other cryptographically relevant factors ... from a complete non-cryptographer like me, this might include things like entropy draw size by typical applications (optimizing for multiple PRNGs over a typical application draw), the length of any feedback register or calibration cycle of individual cryptographic client algorithms, etc. Generally this would mean 'pretty frequently but not so frequently that it's predictably useful' - something of a paradox, true.) In short, I still think this approach may have some merit.
- nknighthb 13y ago
  > That's true if you combine multiple algorithms conventionally What I said is true no matter how you combine them, including in the manner you propose. > flip between supplying the output of each in rapid succession You've just exposed yourself to a possible related-key attack. Also, the effective entropy of your key could be halved simply by one of the PRNGs being compromised, so even absent a related-key attack, you'd better be using an encryption algorithm with a big key size. (BTW, it's 100% overhead, not 50% overhead.) (Oh, and if both algorithms happen to be compromised, the results are or might as well be 0-entropy. Yet again, somewhere along the way you end up trusting something.) > perhaps the flip in which PRNG is used for the output stream occurs at hard-to-predict points in time "Hard-to-predict" requires a secure random number generator. You've gone on to describe yet another ad-hoc random number generator that you would use in the construction of your random number generator. Cryptography is hard.
  - contingencies 13y ago
    You've just exposed yourself to a possible related-key attack It's a tradeoff for mitigating other, perhaps more realistic attack vectors. the effective entropy of your key could be halved simply by one of the PRNGs being compromised Halved is a whole lot better than wholly negated, which was the point of the suggestion. Cryptography is hard. Yeah. Architecturally, though, it seems that (dis-)trusting two supposedly PRNG sources is better than all eggs in one basket with one.
- StavrosK 13y ago
  Basically, cryptography requires a PRNG whose output is provably indistinguishable from a true RNG. Your algorithm cannot be proven to have this property, and might even be susceptible to some attacks. Basically, it's a band-aid, but cryptography is rigorous and averse to band-aids, requiring everything to be mathematically proven before use. It's not enough for an algorithm to "seem reasonable", it must be mathematically proven to have certain properties. It's really an extremely interesting subject to study, I'd give it a go. Join the coursera class on cryptography.
  - 13y ago

contingencies 13y ago

your question is predicated on a nonexistent distinction. A combination of algorithms is simply a new, more complex algorithm. That's true if you combine multiple algorithms conventionally, for example by feeding inputs from one to the other or by passing the original entropy to the two algorithms in parallel. However, if you run one algorithm independently of another - with completely different entropy sources - then flip between supplying the output of each in rapid succession, then on the face of it for ~50% overheads you have probably mostly mitigated exploitable vulnerabilities in either of the two single PRNGs for most applications. (Optionally add another for more security, and take it a step further...) You are right that this would need to be done carefully .. perhaps the flip in which PRNG is used for the output stream occurs at hard-to-predict points in time (the range of periods for which, potentially, might be carefully chosen from a range that takes in to account some other cryptographically relevant factors ... from a complete non-cryptographer like me, this might include things like entropy draw size by typical applications (optimizing for multiple PRNGs over a typical application draw), the length of any feedback register or calibration cycle of individual cryptographic client algorithms, etc. Generally this would mean 'pretty frequently but not so frequently that it's predictably useful' - something of a paradox, true.) In short, I still think this approach may have some merit.

nknighthb 13y ago
> That's true if you combine multiple algorithms conventionally What I said is true no matter how you combine them, including in the manner you propose. > flip between supplying the output of each in rapid succession You've just exposed yourself to a possible related-key attack. Also, the effective entropy of your key could be halved simply by one of the PRNGs being compromised, so even absent a related-key attack, you'd better be using an encryption algorithm with a big key size. (BTW, it's 100% overhead, not 50% overhead.) (Oh, and if both algorithms happen to be compromised, the results are or might as well be 0-entropy. Yet again, somewhere along the way you end up trusting something.) > perhaps the flip in which PRNG is used for the output stream occurs at hard-to-predict points in time "Hard-to-predict" requires a secure random number generator. You've gone on to describe yet another ad-hoc random number generator that you would use in the construction of your random number generator. Cryptography is hard.
- contingencies 13y ago
  You've just exposed yourself to a possible related-key attack It's a tradeoff for mitigating other, perhaps more realistic attack vectors. the effective entropy of your key could be halved simply by one of the PRNGs being compromised Halved is a whole lot better than wholly negated, which was the point of the suggestion. Cryptography is hard. Yeah. Architecturally, though, it seems that (dis-)trusting two supposedly PRNG sources is better than all eggs in one basket with one.
StavrosK 13y ago
Basically, cryptography requires a PRNG whose output is provably indistinguishable from a true RNG. Your algorithm cannot be proven to have this property, and might even be susceptible to some attacks. Basically, it's a band-aid, but cryptography is rigorous and averse to band-aids, requiring everything to be mathematically proven before use. It's not enough for an algorithm to "seem reasonable", it must be mathematically proven to have certain properties. It's really an extremely interesting subject to study, I'd give it a go. Join the coursera class on cryptography.
- 13y ago