Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #5683 > unrolled thread
| Started by | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| First post | 2015-09-01 13:09 +0200 |
| Last post | 2015-09-02 02:22 -0500 |
| Articles | 20 on this page of 85 — 6 participants |
Back to article view | Back to comp.programming
Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-01 13:09 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-01 14:23 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-01 20:00 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-01 18:43 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 10:48 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-02 13:00 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 22:50 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-02 21:31 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 23:46 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-02 21:58 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 00:13 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-03 00:32 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 02:47 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 16:52 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 00:03 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 17:18 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 00:28 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 17:52 -0500
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 01:04 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 18:29 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 01:04 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 18:25 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 01:33 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 18:53 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 02:16 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 02:18 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 02:33 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 02:42 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 02:55 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 03:03 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 03:14 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 03:17 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 03:30 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 03:36 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 04:13 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 04:19 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 04:32 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 22:51 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 16:51 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-03 10:49 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-04 19:47 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-04 13:42 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-04 21:50 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-04 20:33 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-04 23:45 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-05 01:24 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 00:50 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-07 14:14 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-07 15:57 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 12:19 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-08 23:47 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-09 02:28 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-04 20:23 +0000
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-05 00:55 +0200
Re: Researches in quantum computing seem to progress only extremely slowly "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-04 17:11 -0700
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-05 02:31 +0200
Re: Researches in quantum computing seem to progress only extremely slowly "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-04 20:15 -0700
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 00:35 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 00:42 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 00:46 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 00:54 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 01:11 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 01:21 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 01:28 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 02:01 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 02:22 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 02:51 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 02:57 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 03:08 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 03:31 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 03:45 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 03:54 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 04:18 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-03 04:24 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-09-03 07:23 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 16:14 -0500
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 23:23 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Kaz Kylheku <kaz@kylheku.com> - 2015-09-02 21:33 +0000
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 23:54 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-02 23:22 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 23:32 +0200
Re: Researches in quantum computing seem to progress only extremely slowly bartekltg <bartek@gmail.com> - 2015-09-03 00:22 +0200
Re: Researches in quantum computing seem to progress only extremely slowly "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-01 13:23 -0700
Re: Researches in quantum computing seem to progress only extremely slowly Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-09-02 11:04 +0200
Re: Researches in quantum computing seem to progress only extremely slowly Robert Wessel <robertwessel2@yahoo.com> - 2015-09-02 02:22 -0500
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-01 13:09 +0200 |
| Subject | Researches in quantum computing seem to progress only extremely slowly |
| Message-ID | <ms4114$nal$2@news.albasani.net> |
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/ The article doesn't seem to be much more optimistic than reports on other well-known currently running big projects of physics, e.g. nuclear fusion. This means that there is in the foreseeable future no danger of the currently used asymmetric encryption schemes being broken by quantum computers and one could consequently concentrate one's efforts in attempting to improve the practical security of these schemes, e.g. in authentication of the public keys and in prevention of eventually possible backdoors being implanted in the software or hardware involved. M. K. Shen
[toc] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-09-01 14:23 +0000 |
| Message-ID | <20150901072207.925@kylheku.com> |
| In reply to | #5683 |
On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > > http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/ > > The article doesn't seem to be much more optimistic than reports on > other well-known currently running big projects of physics, e.g. > nuclear fusion. > > This means that there is in the foreseeable future no danger of the > currently used asymmetric encryption schemes being broken by quantum Phew! Your python-PRNG-based security schemes is safe!
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-01 20:00 +0200 |
| Message-ID | <ms4p4g$5ul$1@news.albasani.net> |
| In reply to | #5685 |
Am 01.09.2015 um 16:23 schrieb Kaz Kylheku: > On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> >> http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/ >> >> The article doesn't seem to be much more optimistic than reports on >> other well-known currently running big projects of physics, e.g. >> nuclear fusion. >> >> This means that there is in the foreseeable future no danger of the >> currently used asymmetric encryption schemes being broken by quantum > > Phew! Your python-PRNG-based security schemes is safe! In another thread I asked you to provide a reference to support your claim there but you still kept silence on that! M. K. Shen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-09-01 18:43 +0000 |
| Message-ID | <20150901111251.317@kylheku.com> |
| In reply to | #5687 |
["Followup-To:" header set to comp.programming.] On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > Am 01.09.2015 um 16:23 schrieb Kaz Kylheku: >> On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>> >>> http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/ >>> >>> The article doesn't seem to be much more optimistic than reports on >>> other well-known currently running big projects of physics, e.g. >>> nuclear fusion. >>> >>> This means that there is in the foreseeable future no danger of the >>> currently used asymmetric encryption schemes being broken by quantum >> >> Phew! Your python-PRNG-based security schemes is safe! > > In another thread I asked you to provide a reference to support your > claim there but you still kept silence on that! The reference is that the entire sequence coming out of a PRNG only contains as much information as its seed. For instance, a 32 bit seed means that the entire sequence contains at most 32 bits of information. (This is true even if the PRNG is a good one with a big state vector, and a long period.) The seed is effectively a selector which chooses one of 2**32 different sequences. If you generate, say, a 1024 bit key with a PRNG that is seeded with, say, 64 bits, then it's effectively a 64 bit key. Given a known plaintext and ciphertext pair, we only have to search a 64 bit space to recover the key. The encryption algorithm might be RSA-1024, but it's not really because of the weak seeding; it is a misleading lie and "security through obscurity"--- you hope that the scheme is secure because the attacker doesn't know that a particular weekly-seeded PRNG was used. Do you also require a reference for the claim that water is wet? Moreover, a PRNG may have other problems with it even if the state space is large enough and the seed has enough entropy for the given crypto use. About stream ciphers; yes they are lot like PRNG's where the encryption key is a seed. The seed has an appropriate size to achieve a given security level, and no misleading claims are made about the space from which it is chosen. If we use a 256 bit stream cipher, but seed it with a PRNG that uses a 32 bit seed, we have the same problem: the cipher is effectively 32 bit (but the users are duped into believing that it's the 256 bit real thing). No, key entropy does not dilute with the increasing length of an encrypted message. Suppose we have a very good symmetric cipher against which there is no known attack other than brute force. Suppose the attacker knows all of our plaintext. It does not help the attacker to have a large quantity of known plaintext. In fact using more plaintext/ciphertext pairs only slows down the brute force search. For each key which is tried, it is enough to try a single known ciphertext/plaintex pair. Encryption does not work by spreading key entropy across a message. The entropy in a key is important, however, for obvious reasons: more entropy means a larger key space. If an encryption algoirthm requires keys with a certain amount of entropy, and is given less entropy, it is incompetently implemented. Its security is weakened.
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-02 10:48 +0200 |
| Message-ID | <ms6d4b$674$1@news.albasani.net> |
| In reply to | #5688 |
Am 01.09.2015 um 20:43 schrieb Kaz Kylheku: > ["Followup-To:" header set to comp.programming.] > On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> Am 01.09.2015 um 16:23 schrieb Kaz Kylheku: >>> On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>> >>>> http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/ >>>> >>>> The article doesn't seem to be much more optimistic than reports on >>>> other well-known currently running big projects of physics, e.g. >>>> nuclear fusion. >>>> >>>> This means that there is in the foreseeable future no danger of the >>>> currently used asymmetric encryption schemes being broken by quantum >>> >>> Phew! Your python-PRNG-based security schemes is safe! >> >> In another thread I asked you to provide a reference to support your >> claim there but you still kept silence on that! > > The reference is that the entire sequence coming out of a PRNG only contains as > much information as its seed. For instance, a 32 bit seed means that the > entire sequence contains at most 32 bits of information. (This is true even if > the PRNG is a good one with a big state vector, and a long period.) > The seed is effectively a selector which chooses one of 2**32 different > sequences. > > If you generate, say, a 1024 bit key with a PRNG that is seeded with, say, 64 > bits, then it's effectively a 64 bit key. Given a known plaintext and > ciphertext pair, we only have to search a 64 bit space to recover the key. > The encryption algorithm might be RSA-1024, but it's not really because > of the weak seeding; it is a misleading lie and "security through obscurity"--- > you hope that the scheme is secure because the attacker doesn't know > that a particular weekly-seeded PRNG was used. > > Do you also require a reference for the claim that water is wet? > > Moreover, a PRNG may have other problems with it even if the state space is > large enough and the seed has enough entropy for the given crypto use. > > > About stream ciphers; yes they are lot like PRNG's where the encryption key > is a seed. The seed has an appropriate size to achieve a given security > level, and no misleading claims are made about the space from which it > is chosen. If we use a 256 bit stream cipher, but seed it with a PRNG > that uses a 32 bit seed, we have the same problem: the cipher is effectively > 32 bit (but the users are duped into believing that it's the 256 > bit real thing). > > No, key entropy does not dilute with the increasing length of an encrypted > message. Suppose we have a very good symmetric cipher against which there is > no known attack other than brute force. Suppose the attacker knows all of our > plaintext. It does not help the attacker to have a large quantity of known > plaintext. In fact using more plaintext/ciphertext pairs only slows down the > brute force search. For each key which is tried, it is enough to try a single > known ciphertext/plaintex pair. > > Encryption does not work by spreading key entropy across a message. > The entropy in a key is important, however, for obvious reasons: > more entropy means a larger key space. > > If an encryption algoirthm requires keys with a certain amount of entropy, > and is given less entropy, it is incompetently implemented. Its security > is weakened. In my code PROVABLEPRIME (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed to be input by the user at all. When the Python session starts, the system employs the current time to seed its built-in PRNG. So each time one uses the code to e.g. generate RSA keys, one gets a different pair by chance. Certainly one could question the security of that from an "exact" standpoint (I mean in the sense of proofs of pure math), but there is in "practical" crypto in general IMHO no way to take that exact standpoint and yet have useful things done. Does e.g. AES have an exact proof of its security? There is none, at least to my humble knowledge. To repeat a few points of mine in another thread: (1) if a CSPRNG were required in the implementation of Maurer's algorithm (detailed in HAC), the authors of HAC would have explicitly mentioned it according to the common style of writing in such contexts, (2) the algorithm given in HAC of implementing a CSPRNG via RSA would barely have had any practical sense (since one has a "need" of a CSPRNG "only" in situations where one doesn't yet have one). BTW, I like to mention (though this is certainly not any argument of mine here) that a copy of my code was sent to the authors of HAC since, if I don't err, it is the first publically available implementation of Maurer's algrorithm in any popular programming language. M. K. Shen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-09-02 13:00 +0000 |
| Message-ID | <20150902054403.661@kylheku.com> |
| In reply to | #5705 |
On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > In my code PROVABLEPRIME > (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed > to be input by the user at all. When the Python session starts, the > system employs the current time to seed its built-in PRNG. So each > time one uses the code to e.g. generate RSA keys, one gets a different > pair by chance. Certainly one could question the security of that from > an "exact" standpoint (I mean in the sense of proofs of pure math), The "exact standpoint" here is quite obvious and it is that a sample of the current time (even if it includes micro or nanoseconds from a high resolution timer, and not only the "seconds sine epoch" or whatever) simply has too few bits of entropy to generate good RSA keys. > but there is in "practical" crypto in general IMHO no way to take that > exact standpoint and yet have useful things done. Does e.g. AES have > an exact proof of its security? There is none, at least to my humble > knowledge. So if some crypto has no "exact proof of its security", then it's okay to implement it idiotically so that it is guaranteed to insecure? "This car wasn't put through rigorous crash tests, so I'm not going to bother wearing its seat belt!" > To repeat a few points of mine in another thread: (1) if a CSPRNG were > required in the implementation of Maurer's algorithm (detailed in HAC), It has already been explained to you that a CSPRNG is not in fact (specifically) required. What's required is enough bits of entropy from some good source. > the authors of HAC would have explicitly mentioned it according to the I'm pretty sure that HAC teaches that all randomly generated keys require sufficient entropy from a good source. (By the way, since you don't understand HAC, why should anyone waste their time giving you additional references?) > common style of writing in such contexts, (2) the algorithm given in > HAC of implementing a CSPRNG via RSA would barely have had any > practical sense (since one has a "need" of a CSPRNG "only" in > situations where one doesn't yet have one). It's been explained to you that there is no such "chicken or egg" problem. A CSPRNG needs a quality seed from a random source. If you have that, you can do the necessary key generation to bootstrap a PRNG which is based on RSA.
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-02 22:50 +0200 |
| Message-ID | <ms7nf7$j4q$1@news.albasani.net> |
| In reply to | #5717 |
Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: > On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> In my code PROVABLEPRIME >> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >> to be input by the user at all. When the Python session starts, the >> system employs the current time to seed its built-in PRNG. So each >> time one uses the code to e.g. generate RSA keys, one gets a different >> pair by chance. Certainly one could question the security of that from >> an "exact" standpoint (I mean in the sense of proofs of pure math), > > The "exact standpoint" here is quite obvious and it is that a sample of the > current time (even if it includes micro or nanoseconds from a high resolution timer, > and not only the "seconds sine epoch" or whatever) simply has too few bits of > entropy to generate good RSA keys. I must admit that I yet have doubt on such application of the entropy argument (i.e. without regard to how an amount of entropy is actually being employed in the processing) due to a paradox that I put up and described in a recent another thread: AES-128 in counter mode has an input of max 128 bits of entropy but its ouput is commonly used to e.g. xor n plaintext bits with n >> 128. The average entropy that is contained in one ciphertext bit thus can't be greater than 128/n, which is negligible for even moderately large n. Does that imply that AES in CTR mode is totally broken? M. K. Shen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-09-02 21:31 +0000 |
| Message-ID | <20150902142852.600@kylheku.com> |
| In reply to | #5728 |
On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku:
>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>> In my code PROVABLEPRIME
>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed
>>> to be input by the user at all. When the Python session starts, the
>>> system employs the current time to seed its built-in PRNG. So each
>>> time one uses the code to e.g. generate RSA keys, one gets a different
>>> pair by chance. Certainly one could question the security of that from
>>> an "exact" standpoint (I mean in the sense of proofs of pure math),
>>
>> The "exact standpoint" here is quite obvious and it is that a sample of the
>> current time (even if it includes micro or nanoseconds from a high resolution timer,
>> and not only the "seconds sine epoch" or whatever) simply has too few bits of
>> entropy to generate good RSA keys.
>
> I must admit that I yet have doubt on such application of the entropy
> argument (i.e. without regard to how an amount of entropy is actually
> being employed in the processing) due to a paradox that I put up
> and described in a recent another thread: AES-128 in counter mode has
> an input of max 128 bits of entropy but its ouput is commonly used to
> e.g. xor n plaintext bits with n >> 128. The average entropy that is
This topic is directly addressed in the post you replied to above,
under:
> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku:
You just ignored it.
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-02 23:46 +0200 |
| Message-ID | <ms7qo9$oks$1@news.albasani.net> |
| In reply to | #5732 |
Am 02.09.2015 um 23:31 schrieb Kaz Kylheku: > On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>> In my code PROVABLEPRIME >>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>>> to be input by the user at all. When the Python session starts, the >>>> system employs the current time to seed its built-in PRNG. So each >>>> time one uses the code to e.g. generate RSA keys, one gets a different >>>> pair by chance. Certainly one could question the security of that from >>>> an "exact" standpoint (I mean in the sense of proofs of pure math), >>> >>> The "exact standpoint" here is quite obvious and it is that a sample of the >>> current time (even if it includes micro or nanoseconds from a high resolution timer, >>> and not only the "seconds sine epoch" or whatever) simply has too few bits of >>> entropy to generate good RSA keys. >> >> I must admit that I yet have doubt on such application of the entropy >> argument (i.e. without regard to how an amount of entropy is actually >> being employed in the processing) due to a paradox that I put up >> and described in a recent another thread: AES-128 in counter mode has >> an input of max 128 bits of entropy but its ouput is commonly used to >> e.g. xor n plaintext bits with n >> 128. The average entropy that is > > This topic is directly addressed in the post you replied to above, > under: > > > Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: > > You just ignored it. I could have ignored it but excuse me that I don't yet see that. Could you kindly quote one line of your response so that I can identify it (I mean a "direct" resolution of my paradox, I don't see "CTR" in your post mentioned)? Thanks in advance. M. K. Shen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-09-02 21:58 +0000 |
| Message-ID | <20150902145601.221@kylheku.com> |
| In reply to | #5735 |
On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > I could have ignored it but excuse me that I don't yet see that. > Could you kindly quote one line of your response so that I can Sorry, no. "NNTP server" is not anywhere in my job description. These post are still fresh and should be still unexpired on your news server. Just chase the parent article references. (For instance ESC-P in the SLRN newsreader.)
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-03 00:13 +0200 |
| Message-ID | <ms7sau$r96$1@news.albasani.net> |
| In reply to | #5738 |
Am 02.09.2015 um 23:58 schrieb Kaz Kylheku: > On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> I could have ignored it but excuse me that I don't yet see that. >> Could you kindly quote one line of your response so that I can > > Sorry, no. "NNTP server" is not anywhere in my job description. > > These post are still fresh and should be still unexpired on your > news server. Just chase the parent article references. (For instance ESC-P in > the SLRN newsreader.) > But you refer to "Am 02.09.2015 um 15:00 schrieb Kaz Kylheku" and I have that post but I don't see anywhere you wrote about AES CTR. Do you currently see your post where you wrote about AES CTR? If yes, is there any trouble to quote a line out of it? (That's less work than your posting the above, isn't it?) So please once again, quote one relevant line. M. K. Shen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-09-03 00:32 +0000 |
| Message-ID | <20150902172920.478@kylheku.com> |
| In reply to | #5740 |
On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: > Am 02.09.2015 um 23:58 schrieb Kaz Kylheku: >> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>> I could have ignored it but excuse me that I don't yet see that. >>> Could you kindly quote one line of your response so that I can >> >> Sorry, no. "NNTP server" is not anywhere in my job description. >> >> These post are still fresh and should be still unexpired on your >> news server. Just chase the parent article references. (For instance ESC-P in >> the SLRN newsreader.) >> > But you refer to "Am 02.09.2015 um 15:00 schrieb Kaz Kylheku" and > I have that post but I don't see anywhere you wrote about AES CTR. That's because I didn't write specifically about AES, but about stream ciphers in general. Your original objection was about all stream ciphers, right? They use some fixed amount of entropy to create an indefinitely long stream of bits: why doesn't that dilute the entropy?
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-03 02:47 +0200 |
| Message-ID | <ms85aq$5d2$1@news.albasani.net> |
| In reply to | #5762 |
Am 03.09.2015 um 02:32 schrieb Kaz Kylheku: > On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >> Am 02.09.2015 um 23:58 schrieb Kaz Kylheku: >>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>> I could have ignored it but excuse me that I don't yet see that. >>>> Could you kindly quote one line of your response so that I can >>> >>> Sorry, no. "NNTP server" is not anywhere in my job description. >>> >>> These post are still fresh and should be still unexpired on your >>> news server. Just chase the parent article references. (For instance ESC-P in >>> the SLRN newsreader.) >>> >> But you refer to "Am 02.09.2015 um 15:00 schrieb Kaz Kylheku" and >> I have that post but I don't see anywhere you wrote about AES CTR. > > That's because I didn't write specifically about AES, but about stream > ciphers in general. Your original objection was about all stream ciphers, > right? They use some fixed amount of entropy to create an indefinitely long > stream of bits: why doesn't that dilute the entropy? My point concerns the paradox, which is formulated in a scenario where AES in CTR mode is used. You certainly have read that post of mine. Could you resolve that paradox? M. K. Shen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-02 16:52 -0500 |
| Message-ID | <c0reua9jbn013grv90b7bpckeq844ljfv6@4ax.com> |
| In reply to | #5728 |
On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>> In my code PROVABLEPRIME >>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>> to be input by the user at all. When the Python session starts, the >>> system employs the current time to seed its built-in PRNG. So each >>> time one uses the code to e.g. generate RSA keys, one gets a different >>> pair by chance. Certainly one could question the security of that from >>> an "exact" standpoint (I mean in the sense of proofs of pure math), >> >> The "exact standpoint" here is quite obvious and it is that a sample of the >> current time (even if it includes micro or nanoseconds from a high resolution timer, >> and not only the "seconds sine epoch" or whatever) simply has too few bits of >> entropy to generate good RSA keys. > >I must admit that I yet have doubt on such application of the entropy >argument (i.e. without regard to how an amount of entropy is actually >being employed in the processing) due to a paradox that I put up >and described in a recent another thread: AES-128 in counter mode has >an input of max 128 bits of entropy but its ouput is commonly used to >e.g. xor n plaintext bits with n >> 128. The average entropy that is >contained in one ciphertext bit thus can't be greater than 128/n, >which is negligible for even moderately large n. Does that imply that >AES in CTR mode is totally broken? No, it simply means that you don't need to do more than about 2**128 work to break it with a known plaintext attack of sufficient size (where "sufficient" may be as little as 16 bytes). But that's not broken, since that's what we were assuming anyway. Sure, it's not a OTP, but it was never meant to be. DES, with a 56 bit key is broken in the sense that we *can* realistically do 2**56 work (and that's still about the best we can do, the algorithm has held up beautifully after all these years, jus the key is too small) 2**128 work is likely to be impractical* for all time, although there's not a lot of margin there. 2**256 seems inconceivable** with any imaginable technology. Now should someone discover attacks on AES-128 that take significantly less than 2**128 work, that would be a break. *The Landauer limit implies that merely *counting* through the 2**128 states (much less actually attempting to check the keys) would take some 10**18 Joules (about three days of the world's entire energy output, or about the output of a 200 megaton nuclear device***). And that's the theoretical limit - real hardware operates ~100 million times less efficiently, and then you need to add 6-10 additional orders of magnitudes of work to actually test each possible key. The lower end of that range equates to something like three days of the Sun's total energy output. **Again the theoretical minimum for just counting to 2**256 requires the equivalent of the conversion of a couple billion times the mass of the sun to energy. Call it roughly a third of the mass of the Small Magellanic Cloud****. ***IOW, even if someone did this, it *would* be noticed. ****ibid(!)
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-03 00:03 +0200 |
| Message-ID | <ms7ro4$qcm$1@news.albasani.net> |
| In reply to | #5736 |
Am 02.09.2015 um 23:52 schrieb Robert Wessel: > On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen > <mok-kong.shen@t-online.de> wrote: > >> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>> In my code PROVABLEPRIME >>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>>> to be input by the user at all. When the Python session starts, the >>>> system employs the current time to seed its built-in PRNG. So each >>>> time one uses the code to e.g. generate RSA keys, one gets a different >>>> pair by chance. Certainly one could question the security of that from >>>> an "exact" standpoint (I mean in the sense of proofs of pure math), >>> >>> The "exact standpoint" here is quite obvious and it is that a sample of the >>> current time (even if it includes micro or nanoseconds from a high resolution timer, >>> and not only the "seconds sine epoch" or whatever) simply has too few bits of >>> entropy to generate good RSA keys. >> >> I must admit that I yet have doubt on such application of the entropy >> argument (i.e. without regard to how an amount of entropy is actually >> being employed in the processing) due to a paradox that I put up >> and described in a recent another thread: AES-128 in counter mode has >> an input of max 128 bits of entropy but its ouput is commonly used to >> e.g. xor n plaintext bits with n >> 128. The average entropy that is >> contained in one ciphertext bit thus can't be greater than 128/n, >> which is negligible for even moderately large n. Does that imply that >> AES in CTR mode is totally broken? > > > No, it simply means that you don't need to do more than about 2**128 > work to break it with a known plaintext attack of sufficient size > (where "sufficient" may be as little as 16 bytes). But that's not > broken, since that's what we were assuming anyway. Sure, it's not a > OTP, but it was never meant to be. I don't yet understand. One expands a sequence of 128 bits somehow to a sequence of n bits with n >> 128. If the input 128 bits have a total "entropy" of 128, then it can certainly also be asked how much entropy the output n bits have in total and hence the average value of entropy of each output bit. M. K. Shen > > DES, with a 56 bit key is broken in the sense that we *can* > realistically do 2**56 work (and that's still about the best we can > do, the algorithm has held up beautifully after all these years, jus > the key is too small) > > 2**128 work is likely to be impractical* for all time, although > there's not a lot of margin there. 2**256 seems inconceivable** with > any imaginable technology. > > Now should someone discover attacks on AES-128 that take significantly > less than 2**128 work, that would be a break. > > > > *The Landauer limit implies that merely *counting* through the 2**128 > states (much less actually attempting to check the keys) would take > some 10**18 Joules (about three days of the world's entire energy > output, or about the output of a 200 megaton nuclear device***). And > that's the theoretical limit - real hardware operates ~100 million > times less efficiently, and then you need to add 6-10 additional > orders of magnitudes of work to actually test each possible key. The > lower end of that range equates to something like three days of the > Sun's total energy output. > > **Again the theoretical minimum for just counting to 2**256 requires > the equivalent of the conversion of a couple billion times the mass of > the sun to energy. Call it roughly a third of the mass of the Small > Magellanic Cloud****. > > ***IOW, even if someone did this, it *would* be noticed. > > ****ibid(!) > >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-02 17:18 -0500 |
| Message-ID | <34teuahtcltdi1mrq4gj95bu8gacjv112i@4ax.com> |
| In reply to | #5739 |
On Thu, 3 Sep 2015 00:03:52 +0200, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >Am 02.09.2015 um 23:52 schrieb Robert Wessel: >> On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen >> <mok-kong.shen@t-online.de> wrote: >> >>> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >>>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>>> In my code PROVABLEPRIME >>>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>>>> to be input by the user at all. When the Python session starts, the >>>>> system employs the current time to seed its built-in PRNG. So each >>>>> time one uses the code to e.g. generate RSA keys, one gets a different >>>>> pair by chance. Certainly one could question the security of that from >>>>> an "exact" standpoint (I mean in the sense of proofs of pure math), >>>> >>>> The "exact standpoint" here is quite obvious and it is that a sample of the >>>> current time (even if it includes micro or nanoseconds from a high resolution timer, >>>> and not only the "seconds sine epoch" or whatever) simply has too few bits of >>>> entropy to generate good RSA keys. >>> >>> I must admit that I yet have doubt on such application of the entropy >>> argument (i.e. without regard to how an amount of entropy is actually >>> being employed in the processing) due to a paradox that I put up >>> and described in a recent another thread: AES-128 in counter mode has >>> an input of max 128 bits of entropy but its ouput is commonly used to >>> e.g. xor n plaintext bits with n >> 128. The average entropy that is >>> contained in one ciphertext bit thus can't be greater than 128/n, >>> which is negligible for even moderately large n. Does that imply that >>> AES in CTR mode is totally broken? >> >> >> No, it simply means that you don't need to do more than about 2**128 >> work to break it with a known plaintext attack of sufficient size >> (where "sufficient" may be as little as 16 bytes). But that's not >> broken, since that's what we were assuming anyway. Sure, it's not a >> OTP, but it was never meant to be. > >I don't yet understand. One expands a sequence of 128 bits somehow >to a sequence of n bits with n >> 128. If the input 128 bits have >a total "entropy" of 128, then it can certainly also be asked how >much entropy the output n bits have in total and hence the average >value of entropy of each output bit. If there's 128 bits of entropy going in, that's what's coming out. Spread over however many bits you output. IOW, if you encrypt something with AES-128 in whatever mode (ignoring any nonce or IV), there will be only 2**128 possible decryptions of the message, no matter how long it might be. That assumes the key actually has 128 bits of entropy. If you have a poor key generator, the key may well have less than 128 bits of entropy, and an attacker may have to check far fewer than 2**128 possible keys.
[toc] | [prev] | [next] | [standalone]
| From | Mok-Kong Shen <mok-kong.shen@t-online.de> |
|---|---|
| Date | 2015-09-03 00:28 +0200 |
| Message-ID | <ms7t6c$sft$1@news.albasani.net> |
| In reply to | #5741 |
Am 03.09.2015 um 00:18 schrieb Robert Wessel: > On Thu, 3 Sep 2015 00:03:52 +0200, Mok-Kong Shen > <mok-kong.shen@t-online.de> wrote: > >> Am 02.09.2015 um 23:52 schrieb Robert Wessel: >>> On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen >>> <mok-kong.shen@t-online.de> wrote: >>> >>>> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >>>>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>>>> In my code PROVABLEPRIME >>>>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>>>>> to be input by the user at all. When the Python session starts, the >>>>>> system employs the current time to seed its built-in PRNG. So each >>>>>> time one uses the code to e.g. generate RSA keys, one gets a different >>>>>> pair by chance. Certainly one could question the security of that from >>>>>> an "exact" standpoint (I mean in the sense of proofs of pure math), >>>>> >>>>> The "exact standpoint" here is quite obvious and it is that a sample of the >>>>> current time (even if it includes micro or nanoseconds from a high resolution timer, >>>>> and not only the "seconds sine epoch" or whatever) simply has too few bits of >>>>> entropy to generate good RSA keys. >>>> >>>> I must admit that I yet have doubt on such application of the entropy >>>> argument (i.e. without regard to how an amount of entropy is actually >>>> being employed in the processing) due to a paradox that I put up >>>> and described in a recent another thread: AES-128 in counter mode has >>>> an input of max 128 bits of entropy but its ouput is commonly used to >>>> e.g. xor n plaintext bits with n >> 128. The average entropy that is >>>> contained in one ciphertext bit thus can't be greater than 128/n, >>>> which is negligible for even moderately large n. Does that imply that >>>> AES in CTR mode is totally broken? >>> >>> >>> No, it simply means that you don't need to do more than about 2**128 >>> work to break it with a known plaintext attack of sufficient size >>> (where "sufficient" may be as little as 16 bytes). But that's not >>> broken, since that's what we were assuming anyway. Sure, it's not a >>> OTP, but it was never meant to be. >> >> I don't yet understand. One expands a sequence of 128 bits somehow >> to a sequence of n bits with n >> 128. If the input 128 bits have >> a total "entropy" of 128, then it can certainly also be asked how >> much entropy the output n bits have in total and hence the average >> value of entropy of each output bit. > > > If there's 128 bits of entropy going in, that's what's coming out. > Spread over however many bits you output. IOW, if you encrypt > something with AES-128 in whatever mode (ignoring any nonce or IV), > there will be only 2**128 possible decryptions of the message, no > matter how long it might be. But you are ignoring the "entropy" in your 2nd sentence. My paradox is however centered on "entropy". Each input bit is assumed to have 1 bit of entropy. After spreading, the average entropy can't be larger than 128/n. What is wrong in that calculation logically? That's what I like very much to know from you or Kylheku. M. K. Shen > > That assumes the key actually has 128 bits of entropy. If you have a > poor key generator, the key may well have less than 128 bits of > entropy, and an attacker may have to check far fewer than 2**128 > possible keys. >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-02 17:52 -0500 |
| Message-ID | <nrueuap090o6cds3elqata8fsbos63j1md@4ax.com> |
| In reply to | #5743 |
On Thu, 3 Sep 2015 00:28:33 +0200, Mok-Kong Shen
<mok-kong.shen@t-online.de> wrote:
>Am 03.09.2015 um 00:18 schrieb Robert Wessel:
>> On Thu, 3 Sep 2015 00:03:52 +0200, Mok-Kong Shen
>> <mok-kong.shen@t-online.de> wrote:
>>
>>> Am 02.09.2015 um 23:52 schrieb Robert Wessel:
>>>> On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen
>>>> <mok-kong.shen@t-online.de> wrote:
>>>>
>>>>> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku:
>>>>>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>>>>>> In my code PROVABLEPRIME
>>>>>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed
>>>>>>> to be input by the user at all. When the Python session starts, the
>>>>>>> system employs the current time to seed its built-in PRNG. So each
>>>>>>> time one uses the code to e.g. generate RSA keys, one gets a different
>>>>>>> pair by chance. Certainly one could question the security of that from
>>>>>>> an "exact" standpoint (I mean in the sense of proofs of pure math),
>>>>>>
>>>>>> The "exact standpoint" here is quite obvious and it is that a sample of the
>>>>>> current time (even if it includes micro or nanoseconds from a high resolution timer,
>>>>>> and not only the "seconds sine epoch" or whatever) simply has too few bits of
>>>>>> entropy to generate good RSA keys.
>>>>>
>>>>> I must admit that I yet have doubt on such application of the entropy
>>>>> argument (i.e. without regard to how an amount of entropy is actually
>>>>> being employed in the processing) due to a paradox that I put up
>>>>> and described in a recent another thread: AES-128 in counter mode has
>>>>> an input of max 128 bits of entropy but its ouput is commonly used to
>>>>> e.g. xor n plaintext bits with n >> 128. The average entropy that is
>>>>> contained in one ciphertext bit thus can't be greater than 128/n,
>>>>> which is negligible for even moderately large n. Does that imply that
>>>>> AES in CTR mode is totally broken?
>>>>
>>>>
>>>> No, it simply means that you don't need to do more than about 2**128
>>>> work to break it with a known plaintext attack of sufficient size
>>>> (where "sufficient" may be as little as 16 bytes). But that's not
>>>> broken, since that's what we were assuming anyway. Sure, it's not a
>>>> OTP, but it was never meant to be.
>>>
>>> I don't yet understand. One expands a sequence of 128 bits somehow
>>> to a sequence of n bits with n >> 128. If the input 128 bits have
>>> a total "entropy" of 128, then it can certainly also be asked how
>>> much entropy the output n bits have in total and hence the average
>>> value of entropy of each output bit.
>>
>>
>> If there's 128 bits of entropy going in, that's what's coming out.
>> Spread over however many bits you output. IOW, if you encrypt
>> something with AES-128 in whatever mode (ignoring any nonce or IV),
>> there will be only 2**128 possible decryptions of the message, no
>> matter how long it might be.
>
>But you are ignoring the "entropy" in your 2nd sentence. My paradox
>is however centered on "entropy". Each input bit is assumed to have
>1 bit of entropy. After spreading, the average entropy can't be
>larger than 128/n. What is wrong in that calculation logically?
>That's what I like very much to know from you or Kylheku.
I wouldn't use the word average, but there would be about 128/n bits
of entropy per output bit.
That's not really at question, or very interesting. If I take a
gallon of milk, and divide it evenly between 1024 containers, I'll
have an eighth of an ounce of milk in each container.
I have perhaps missed some part of this discussion.
If this has to do with CS vs. non-CS PRNGs, the difference is that
non-CS PRNGs make it trivial(-ish) to extract the original data
("entropy") from the stream, or equivalently, allow the prediction of
future outputs from existing ones without excessive work. For example
you can seed and LFSR with some amount of entropy, but if you have
some output from it, you can work it backwards to determine what that
initial seed (or at least the initial state derived from that seed)
was.
[toc] | [prev] | [next] | [standalone]
| From | bartekltg <bartek@gmail.com> |
|---|---|
| Date | 2015-09-03 01:04 +0200 |
| Message-ID | <ms7v9v$m5k$1@speranza.aioe.org> |
| In reply to | #5747 |
On 03.09.2015 00:52, Robert Wessel wrote: > On Thu, 3 Sep 2015 00:28:33 +0200, Mok-Kong Shen > <mok-kong.shen@t-online.de> wrote: > >> Am 03.09.2015 um 00:18 schrieb Robert Wessel: >>> On Thu, 3 Sep 2015 00:03:52 +0200, Mok-Kong Shen >>> <mok-kong.shen@t-online.de> wrote: >>> >>>> Am 02.09.2015 um 23:52 schrieb Robert Wessel: >>>>> On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen >>>>> <mok-kong.shen@t-online.de> wrote: >>>>> >>>>>> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >>>>>>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>>>>>> In my code PROVABLEPRIME >>>>>>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>>>>>>> to be input by the user at all. When the Python session starts, the >>>>>>>> system employs the current time to seed its built-in PRNG. So each >>>>>>>> time one uses the code to e.g. generate RSA keys, one gets a different >>>>>>>> pair by chance. Certainly one could question the security of that from >>>>>>>> an "exact" standpoint (I mean in the sense of proofs of pure math), >>>>>>> >>>>>>> The "exact standpoint" here is quite obvious and it is that a sample of the >>>>>>> current time (even if it includes micro or nanoseconds from a high resolution timer, >>>>>>> and not only the "seconds sine epoch" or whatever) simply has too few bits of >>>>>>> entropy to generate good RSA keys. >>>>>> >>>>>> I must admit that I yet have doubt on such application of the entropy >>>>>> argument (i.e. without regard to how an amount of entropy is actually >>>>>> being employed in the processing) due to a paradox that I put up >>>>>> and described in a recent another thread: AES-128 in counter mode has >>>>>> an input of max 128 bits of entropy but its ouput is commonly used to >>>>>> e.g. xor n plaintext bits with n >> 128. The average entropy that is >>>>>> contained in one ciphertext bit thus can't be greater than 128/n, >>>>>> which is negligible for even moderately large n. Does that imply that >>>>>> AES in CTR mode is totally broken? >>>>> >>>>> >>>>> No, it simply means that you don't need to do more than about 2**128 >>>>> work to break it with a known plaintext attack of sufficient size >>>>> (where "sufficient" may be as little as 16 bytes). But that's not >>>>> broken, since that's what we were assuming anyway. Sure, it's not a >>>>> OTP, but it was never meant to be. >>>> >>>> I don't yet understand. One expands a sequence of 128 bits somehow >>>> to a sequence of n bits with n >> 128. If the input 128 bits have >>>> a total "entropy" of 128, then it can certainly also be asked how >>>> much entropy the output n bits have in total and hence the average >>>> value of entropy of each output bit. >>> >>> >>> If there's 128 bits of entropy going in, that's what's coming out. >>> Spread over however many bits you output. IOW, if you encrypt >>> something with AES-128 in whatever mode (ignoring any nonce or IV), >>> there will be only 2**128 possible decryptions of the message, no >>> matter how long it might be. >> >> But you are ignoring the "entropy" in your 2nd sentence. My paradox >> is however centered on "entropy". Each input bit is assumed to have >> 1 bit of entropy. After spreading, the average entropy can't be >> larger than 128/n. What is wrong in that calculation logically? >> That's what I like very much to know from you or Kylheku. > > > I wouldn't use the word average, but there would be about 128/n bits > of entropy per output bit. > > That's not really at question, or very interesting. If I take a > gallon of milk, and divide it evenly between 1024 containers, I'll > have an eighth of an ounce of milk in each container. > > I have perhaps missed some part of this discussion. <ms7u0f$jem$1@speranza.aioe.org> <ms7tk8$is0$1@speranza.aioe.org> //simplified, one candy, I mean bit One um^3 of milk and other um^3 of milk are independent. The two chunk of information coded using the same cipher are not. There is whole information in both of them, but if you learn this information from one chunk, you don't get any new information from second one. bartekltg
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-02 18:29 -0500 |
| Message-ID | <7c1fuatih4aedh6umqdvfrusfeonbnd7g8@4ax.com> |
| In reply to | #5749 |
On Thu, 03 Sep 2015 01:04:31 +0200, bartekltg <bartek@gmail.com> wrote: >On 03.09.2015 00:52, Robert Wessel wrote: >> On Thu, 3 Sep 2015 00:28:33 +0200, Mok-Kong Shen >> <mok-kong.shen@t-online.de> wrote: >> >>> Am 03.09.2015 um 00:18 schrieb Robert Wessel: >>>> On Thu, 3 Sep 2015 00:03:52 +0200, Mok-Kong Shen >>>> <mok-kong.shen@t-online.de> wrote: >>>> >>>>> Am 02.09.2015 um 23:52 schrieb Robert Wessel: >>>>>> On Wed, 2 Sep 2015 22:50:52 +0200, Mok-Kong Shen >>>>>> <mok-kong.shen@t-online.de> wrote: >>>>>> >>>>>>> Am 02.09.2015 um 15:00 schrieb Kaz Kylheku: >>>>>>>> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote: >>>>>>>>> In my code PROVABLEPRIME >>>>>>>>> (http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed >>>>>>>>> to be input by the user at all. When the Python session starts, the >>>>>>>>> system employs the current time to seed its built-in PRNG. So each >>>>>>>>> time one uses the code to e.g. generate RSA keys, one gets a different >>>>>>>>> pair by chance. Certainly one could question the security of that from >>>>>>>>> an "exact" standpoint (I mean in the sense of proofs of pure math), >>>>>>>> >>>>>>>> The "exact standpoint" here is quite obvious and it is that a sample of the >>>>>>>> current time (even if it includes micro or nanoseconds from a high resolution timer, >>>>>>>> and not only the "seconds sine epoch" or whatever) simply has too few bits of >>>>>>>> entropy to generate good RSA keys. >>>>>>> >>>>>>> I must admit that I yet have doubt on such application of the entropy >>>>>>> argument (i.e. without regard to how an amount of entropy is actually >>>>>>> being employed in the processing) due to a paradox that I put up >>>>>>> and described in a recent another thread: AES-128 in counter mode has >>>>>>> an input of max 128 bits of entropy but its ouput is commonly used to >>>>>>> e.g. xor n plaintext bits with n >> 128. The average entropy that is >>>>>>> contained in one ciphertext bit thus can't be greater than 128/n, >>>>>>> which is negligible for even moderately large n. Does that imply that >>>>>>> AES in CTR mode is totally broken? >>>>>> >>>>>> >>>>>> No, it simply means that you don't need to do more than about 2**128 >>>>>> work to break it with a known plaintext attack of sufficient size >>>>>> (where "sufficient" may be as little as 16 bytes). But that's not >>>>>> broken, since that's what we were assuming anyway. Sure, it's not a >>>>>> OTP, but it was never meant to be. >>>>> >>>>> I don't yet understand. One expands a sequence of 128 bits somehow >>>>> to a sequence of n bits with n >> 128. If the input 128 bits have >>>>> a total "entropy" of 128, then it can certainly also be asked how >>>>> much entropy the output n bits have in total and hence the average >>>>> value of entropy of each output bit. >>>> >>>> >>>> If there's 128 bits of entropy going in, that's what's coming out. >>>> Spread over however many bits you output. IOW, if you encrypt >>>> something with AES-128 in whatever mode (ignoring any nonce or IV), >>>> there will be only 2**128 possible decryptions of the message, no >>>> matter how long it might be. >>> >>> But you are ignoring the "entropy" in your 2nd sentence. My paradox >>> is however centered on "entropy". Each input bit is assumed to have >>> 1 bit of entropy. After spreading, the average entropy can't be >>> larger than 128/n. What is wrong in that calculation logically? >>> That's what I like very much to know from you or Kylheku. >> >> >> I wouldn't use the word average, but there would be about 128/n bits >> of entropy per output bit. >> >> That's not really at question, or very interesting. If I take a >> gallon of milk, and divide it evenly between 1024 containers, I'll >> have an eighth of an ounce of milk in each container. >> >> I have perhaps missed some part of this discussion. > > <ms7u0f$jem$1@speranza.aioe.org> > <ms7tk8$is0$1@speranza.aioe.org> //simplified, one candy, I mean bit > >One um^3 of milk and other um^3 of milk are independent. >The two chunk of information coded using the same cipher >are not. > >There is whole information in both of them, but >if you learn this information from one chunk, >you don't get any new information from second one. I should probably have avoided the analogy, but I'm still not clear what Mok-Kong Shen is talking about.
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.programming
csiph-web