OSDev.org

Of course. That's called distribution. Just omitted it for simplicity of speculations.

Solar wrote:

Owen wrote:...every hash function can trivially be transformed into a cipher.

Which, unfortunately, is not true. (I'd like to see how you'd go about reconstructing a document from it's md5 hash.)

No, actually, he's right. A stream cipher really just boils down to a secure PRNG seeded with the key, and a secure PRNG can be created using a secure hash function. It's not as trivial as "the hash of the message is the ciphertext", which of course wouldn't be invertible, but it's trivial in the sense that you don't need to bring in any other crypto algorithms to make it work.

Solar wrote:You generate a 128bit seed by capturing radio noise.

NO. I wrote about increasing the unpredictibility of random seeds by using radio noise too as data for hash algorithms. Never wrote 128 bit, did I? Read the document I linked.

Maxim #1 of any forumer: read, read, read.

Solar wrote:if I capture almost the same radio noise, that significantly reduces

...nothing. First, you cannot capture the same waves, so you'll be always guessing. Second, if by any chance you managed to guess the right combination, you would not know it, because you still do not know the other factors of the seed.

Yoda wrote:To use it you need to build radio receiver

NO. Which part did you not understand of "already installed" and "existing"? You have a strong random seed generator. And you have an infrastructure to receive waves (already built for other reasons, providing huge amount of noise data as a side-effect). Feeding the former with stream data from latter cost you nothing.

Yoda wrote:The randomness doesn't depend on how large is you hash and how random it looks

Never said so. What I said:

The key part is, change it in a non-periodic way

Other sources (the more the better) needed.

Ok, I'm fed up, because you guys simply do not read.

turdus wrote:

Solar wrote:You generate a 128bit seed by capturing radio noise.

NO. I wrote about increasing the unpredictibility of random seeds by using radio noise too as data for hash algorithms. Never wrote 128 bit, did I? Read the document I linked.

Maxim #1 of any forumer: read, read, read.

Maxim #2 of any forumer: Understand what the other person is saying before going balistic. If you're intentionally misunderstanding people, there's little we can do.

Solar wrote:

turdus wrote:

Solar wrote:You generate a 128bit seed by capturing radio noise.

NO. I wrote about increasing the unpredictibility of random seeds by using radio noise too as data for hash algorithms. Never wrote 128 bit, did I? Read the document I linked.

Maxim #1 of any forumer: read, read, read.

Maxim #2 of any forumer: Understand what the other person is saying before going balistic. If you're intentionally misunderstanding people, there's little we can do.

You wrote that as a memo for you, did you?
It wasn't me who misunderstood a post... It's a fact, I never wrote "generate a 128bit seed by capturing radio noise". Still wondering where did you get that from?

There doesn't seem to be a single thread without an argument nowadays. I enjoy this forum because I enjoy OS development, but most members are just a little too sensitive. Requesting a topic lock.

I believe VIA uses the difference in two clocks for RNG. Heres a rough over view http://www.via.com.tw/en/initiatives/pa ... nd_how.jsp.

ACcurrent wrote:I believe VIA uses the difference in two clocks for RNG. Heres a rough over view http://www.via.com.tw/en/initiatives/pa ... nd_how.jsp.

I think has a reasonably technical explanation.

http://en.wikipedia.org/wiki/Hardware_r ... lock_drift

If I wasn't about to go to bed, I'd check in to truecrypt as well, that seems rather promising.

NickJohnson wrote:

Solar wrote:

Owen wrote:...every hash function can trivially be transformed into a cipher.

Which, unfortunately, is not true. (I'd like to see how you'd go about reconstructing a document from it's md5 hash.)

No, actually, he's right. A stream cipher really just boils down to a secure PRNG seeded with the key, and a secure PRNG can be created using a secure hash function. It's not as trivial as "the hash of the message is the ciphertext", which of course wouldn't be invertible, but it's trivial in the sense that you don't need to bring in any other crypto algorithms to make it work.

In fact, Snuffle is an example of this - an extremely important example as it brought about the overturn of the US strong cryptography export laws.

Actually, he is neither right, nor wrong. Every hash algorithm may be used for building cipher, but this cipher will not be proof against whole set of attacks which classical block cipher (AES, for example) is proof. For example, if an attacker has original text and the encrypted one, in the case of AES he will not be able to modify the message so that after decription the recepient will get intentionally mangled text. But in the case of hash-based cipher he will be able to do this. Another issue is that this kind of cipher is extremely weak in successive usage of the same key. But in AES you may safely use same key [practically] unlimited number of times.

Yoda wrote:Actually, he is neither right, nor wrong. Every hash algorithm may be used for building cipher, but this cipher will not be proof against whole set of attacks which classical block cipher (AES, for example) is proof. For example, if an attacker has original text and the encrypted one, in the case of AES he will not be able to modify the message so that after decription the recepient will get intentionally mangled text. But in the case of hash-based cipher he will be able to do this. Another issue is that this kind of cipher is extremely weak in successive usage of the same key. But in AES you may safely use same key [practically] unlimited number of times.

The security of the derived stream cipher is very much a function of how it is used; and the considerations are very much similar to those for a block cipher derived stream cipher. I see multiple flaws in your argument:

• You are using the cipher to guarantee message integrity. This is absolutely a horrendous idea. No cipher can guarantee this; this is what a message authentication code is for, e.g. HMAC-SHA-512
• Your argument about safe key reuse applies equally for any block cipher when a stream cipher is derived from it. Many cryptosystems use an initialization vector; this precaution prevents exactly this kind of attack.

Your argument demonstrates exactly why people who are not cryptographers should not ever attempt to design or implement a cryptosystem; they inevitably get it wrong. I'm sure you can gather that I'm quite versed in cryptosystems; Because of this, I know that I should never implement one myself, and a far better idea is to delegate to an existing, well tested and preferably FIPS reviewed one, such as Mozilla's NSS

Owen wrote:You are using the cipher to guarantee message integrity...

Of course NOT! There are many applications that doesn't require full implementation of message authenticity validation (as banking transactions) but still may become point of vulnerability. Spoofing of network packets in a large traffic is an example (remember an attack of Mitnick against Shimomura). Of course, potentially you can protect every packet by digital signature but this will result in an extremely large overhead in traffic and CPU resources.

Owen wrote:Many cryptosystems use an initialization vector; this precaution prevents exactly this kind of attack.

This also results in further complication of algorithm and inventing the mechanisms of vectors synchronization. Remember that the original statement was "trivial conversion of hash to block cipher". But this conversion is neither trivial nor effective. You may even return to the roots of cryptography and state that One-time pad is absolutely reliable cipher but please consider the effectiveness first, before further arguing.

Owen wrote:Your argument demonstrates exactly why people who are not cryptographers should not ever attempt... ... I'm sure you can gather that I'm quite versed in cryptosystems;

I don't like measuring everione's merits and regalia. I don't know you, you don't know me.

Yoda wrote:

Owen wrote:You are using the cipher to guarantee message integrity...

Of course NOT! There are many applications that doesn't require full implementation of message authenticity validation (as banking transactions) but still may become point of vulnerability. Spoofing of network packets in a large traffic is an example (remember an attack of Mitnick against Shimomura). Of course, potentially you can protect every packet by digital signature but this will result in an extremely large overhead in traffic and CPU resources.

Did I say digital signature? No. I said Message Authentication Code; a completely different cryptographic primitive. But, in any case, ask any qualified cryptographer and they will tell you that evaluating encryption systems on the basis of their resilience to tampering is like evaluating types of bread on the basis of their tensile strength: almost meaningless

Owen wrote:Many cryptosystems use an initialization vector; this precaution prevents exactly this kind of attack.

This also results in further complication of algorithm and inventing the mechanisms of vectors synchronization. Remember that the original statement was "trivial conversion of hash to block cipher". But this conversion is neither trivial nor effective. You may even return to the roots of cryptography and state that One-time pad is absolutely reliable cipher but please consider the effectiveness first, before further arguing.

Observe that any effective mode of using a traditional block cipher (i.e. any mode which isn't ECB, which leaks so much information its use is almost futile) requires an IV or nonce, because otherwise for the first block of data the cipher leaks as much information as ECB would, and because it is often a good idea to make it impossible to determine whether two ciphertexts correspond to equal plaintexts. Also note that any channel which can carry the ciphertext can carry the IV - after all, the IV is just a non-secret random number.

Finally, I said trivial conversion of a hash function into a cipher - nowhere did I say block cipher, and in fact it should have been obvious from my previous post that I was inferring a stream cipher.

Owen wrote:Did I say digital signature? No. I said Message Authentication Code; a completely different cryptographic primitive.

Doesn't matter. Fast MAC algorithms (CBC-MAC, for example) are based on the intrinsic strength of block cipher against tampering, but MAC for this hash-derived cipher may be reliable only in case of applying the digital hash over the whole message - very consumptive algorithm.

Owen wrote:ask any qualified cryptographer and they will tell you that evaluating encryption systems on the basis of their resilience to tampering is ... almost meaningless

Every qualified cryptographer will tell you that each cryptographical method has it's own set of characteristics and scope of usage. The strength against tampering is one of the most valuable quality of cipher. I pointed to one characteristic where hash-based cipher is not competitive against block cipher.

Owen wrote:

Yoda wrote:But this conversion is neither trivial nor effective. ... but please consider the effectiveness first, before further arguing.

Observe that any effective mode of using a traditional block cipher (i.e. any mode which isn't ECB, which leaks so much information its use is almost futile) requires an IV or nonce, because otherwise for the first block of data the cipher leaks as much information as ECB would, and because it is often a good idea to make it impossible to determine whether two ciphertexts correspond to equal plaintexts.

Again, you are trying to oblige cipher with properties wich are actually not necessary in many applications. For example, monitoring of critical hardware may not require that intruder will not be able to determine the identity of some packets. But it may require proof against tampering and decrypting plaintext.

Yoda wrote:

Owen wrote:Did I say digital signature? No. I said Message Authentication Code; a completely different cryptographic primitive.

Doesn't matter. Fast MAC algorithms (CBC-MAC, for example) are based on the intrinsic strength of block cipher against tampering, but MAC for this hash-derived cipher may be reliable only in case of applying the digital hash over the whole message - very consumptive algorithm.

Nowhere did I say that the derived cipher would be used for the MAC - it would be far more efficient to return to the underlying hash function and use e.g. HMAC. In any case, CBC-MAC likewise requires the whole message be processed by itself (failure to use a different CBC-MAC key to the encryption key severely weakens it)

Owen wrote:ask any qualified cryptographer and they will tell you that evaluating encryption systems on the basis of their resilience to tampering is ... almost meaningless

Every qualified cryptographer will tell you that each cryptographical method has it's own set of characteristics and scope of usage. The strength against tampering is one of the most valuable quality of cipher. I pointed to one characteristic where hash-based cipher is not competitive against block cipher.

Protection against tampering is a property offered by a message authentication code. A MAC can be constructed from a block cipher, but a cipher itself is not a method of preventing tampering. If you wish to argue otherwise, please cite your peer-reviewed source.

Owen wrote:

Yoda wrote:But this conversion is neither trivial nor effective. ... but please consider the effectiveness first, before further arguing.

Observe that any effective mode of using a traditional block cipher (i.e. any mode which isn't ECB, which leaks so much information its use is almost futile) requires an IV or nonce, because otherwise for the first block of data the cipher leaks as much information as ECB would, and because it is often a good idea to make it impossible to determine whether two ciphertexts correspond to equal plaintexts.

Again, you are trying to oblige cipher with properties wich are actually not necessary in many applications. For example, monitoring of critical hardware may not require that intruder will not be able to determine the identity of some packets. But it may require proof against tampering and decrypting plaintext.

Prevention of tampering: Usage of a MAC
Prevention of descryption: Usage of a secure method of operation, i.e. one which is not ECB (because ECB does not provide sufficient confidentiality)