Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5683 > unrolled thread

Researches in quantum computing seem to progress only extremely slowly

Back to article view | Back to comp.programming

Contents

  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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#5748

On 03.09.2015 00:46, Mok-Kong Shen wrote:
> Am 03.09.2015 um 00:35 schrieb bartekltg:
>> On 03.09.2015 00:03, Mok-Kong Shen 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.
>>
>> OK, this will be far from formal math...
>>
>> Do you assume the text is known? If the entropy is only entropy
>> of the coding sequence, you do.
>> In the first 128 bits there is 128bit of enthropy.
>> In the second 128 bits there is 128bit of enthropy.
>> In the first 256 bits - 128 bits of enthropy.
>>
>> The entropy of whole sequence (X,Y)
>> H(X,Y) = H(X) + H(Y|X)  (=H(y) + H(X|Y))
>> is equal to entropy of the first part plus
>> _conditional_ entropy od Y under the assumption X is known.
>> And because you use the same sequence to code the second half,
>> there is no new information. H(X|Y) = 0.
>
> Sorry, I can't follow your contional entropy argument.

https://en.wikipedia.org/wiki/Conditional_entropy

> You wrote "... assumption X is known".

This is a standard formula from propability theory.
for two random variable X and Y, Y|X is a a distribution
of Y if X is fixed.

> But one can simply consider
> that one has got n output bits from AES before doing anything
> else. What is "known" at that time?

I look at the first 128 bits of the code. Because I know
original text, I can decode the sequance.
If I look at the second 128 bits, I do not get any
new information.

> If none, what's the average
> entropy per bit?

It looks like average entropy is very consuming,
because bits in your example are not independent.

If you look at any 128bit chunk you get the whole 128bit
of information.
REad the second post about a candy.

bartekltg






>
> M. K. Shen
>

[toc] | [prev] | [next] | [standalone]

#5751

Am 03.09.2015 um 00:54 schrieb bartekltg:
> On 03.09.2015 00:46, Mok-Kong Shen wrote:
>> Am 03.09.2015 um 00:35 schrieb bartekltg:
>>> On 03.09.2015 00:03, Mok-Kong Shen 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.
>>>
>>> OK, this will be far from formal math...
>>>
>>> Do you assume the text is known? If the entropy is only entropy
>>> of the coding sequence, you do.
>>> In the first 128 bits there is 128bit of enthropy.
>>> In the second 128 bits there is 128bit of enthropy.
>>> In the first 256 bits - 128 bits of enthropy.
>>>
>>> The entropy of whole sequence (X,Y)
>>> H(X,Y) = H(X) + H(Y|X)  (=H(y) + H(X|Y))
>>> is equal to entropy of the first part plus
>>> _conditional_ entropy od Y under the assumption X is known.
>>> And because you use the same sequence to code the second half,
>>> there is no new information. H(X|Y) = 0.
>>
>> Sorry, I can't follow your contional entropy argument.
>
> https://en.wikipedia.org/wiki/Conditional_entropy
>
>> You wrote "... assumption X is known".
>
> This is a standard formula from propability theory.
> for two random variable X and Y, Y|X is a a distribution
> of Y if X is fixed.
>
>> But one can simply consider
>> that one has got n output bits from AES before doing anything
>> else. What is "known" at that time?
>
> I look at the first 128 bits of the code. Because I know
> original text, I can decode the sequance.
> If I look at the second 128 bits, I do not get any
> new information.
>
>> If none, what's the average
>> entropy per bit?
>
> It looks like average entropy is very consuming,
> because bits in your example are not independent.
>
> If you look at any 128bit chunk you get the whole 128bit
> of information.
> REad the second post about a candy.

Sorry, I prefer not to be involved in discussing a different scenario
and like to know why the simply calculation of mine, which concerns
only input bits and output bits of AES alone (without involving
any subsequent operations done with the output bits) is anywhere
logically wrong.

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5752

On 03.09.2015 01:11, Mok-Kong Shen wrote:
> Am 03.09.2015 um 00:54 schrieb bartekltg:
>> On 03.09.2015 00:46, Mok-Kong Shen wrote:
>>> Am 03.09.2015 um 00:35 schrieb bartekltg:
>>>> On 03.09.2015 00:03, Mok-Kong Shen 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.
>>>>
>>>> OK, this will be far from formal math...
>>>>
>>>> Do you assume the text is known? If the entropy is only entropy
>>>> of the coding sequence, you do.
>>>> In the first 128 bits there is 128bit of enthropy.
>>>> In the second 128 bits there is 128bit of enthropy.
>>>> In the first 256 bits - 128 bits of enthropy.
>>>>
>>>> The entropy of whole sequence (X,Y)
>>>> H(X,Y) = H(X) + H(Y|X)  (=H(y) + H(X|Y))
>>>> is equal to entropy of the first part plus
>>>> _conditional_ entropy od Y under the assumption X is known.
>>>> And because you use the same sequence to code the second half,
>>>> there is no new information. H(X|Y) = 0.
>>>
>>> Sorry, I can't follow your contional entropy argument.
>>
>> https://en.wikipedia.org/wiki/Conditional_entropy
>>
>>> You wrote "... assumption X is known".
>>
>> This is a standard formula from propability theory.
>> for two random variable X and Y, Y|X is a a distribution
>> of Y if X is fixed.
>>
>>> But one can simply consider
>>> that one has got n output bits from AES before doing anything
>>> else. What is "known" at that time?
>>
>> I look at the first 128 bits of the code. Because I know
>> original text, I can decode the sequance.
>> If I look at the second 128 bits, I do not get any
>> new information.
>>
>>> If none, what's the average
>>> entropy per bit?
>>
>> It looks like average entropy is very consuming,
>> because bits in your example are not independent.
>>
>> If you look at any 128bit chunk you get the whole 128bit
>> of information.
>> REad the second post about a candy.
>
> Sorry, I prefer not to be involved in discussing a different scenario
> and like to know why the simply calculation of mine, which concerns
> only input bits and output bits of AES alone (without involving
> any subsequent operations done with the output bits) is anywhere
> logically wrong.


This is exactly the answer to you question about 'mean entropy'.
You did not understand the direct answer because you do not
know math about entropy. This is why I also wrote the second
post about simplified problem, but with the same question
and answer.

If I have a candy in one hand I do not have a half of bits
of enthropy in each hand. I have one bit in left and one
bit in right. But both bits are corelated, so if you
known one, you also known the second - second hand
have zero entropy, because ("under the assuption the
first hand in known") you known where the candy is.

"Mean entropy" as you proposed ("128/n") have no sense,
because probability doesn't work that way.

bartekltg

[toc] | [prev] | [next] | [standalone]

#5754

Am 03.09.2015 um 01:21 schrieb bartekltg:
> On 03.09.2015 01:11, Mok-Kong Shen wrote:
>> Am 03.09.2015 um 00:54 schrieb bartekltg:
>>> On 03.09.2015 00:46, Mok-Kong Shen wrote:
>>>> Am 03.09.2015 um 00:35 schrieb bartekltg:
>>>>> On 03.09.2015 00:03, Mok-Kong Shen 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.
>>>>>
>>>>> OK, this will be far from formal math...
>>>>>
>>>>> Do you assume the text is known? If the entropy is only entropy
>>>>> of the coding sequence, you do.
>>>>> In the first 128 bits there is 128bit of enthropy.
>>>>> In the second 128 bits there is 128bit of enthropy.
>>>>> In the first 256 bits - 128 bits of enthropy.
>>>>>
>>>>> The entropy of whole sequence (X,Y)
>>>>> H(X,Y) = H(X) + H(Y|X)  (=H(y) + H(X|Y))
>>>>> is equal to entropy of the first part plus
>>>>> _conditional_ entropy od Y under the assumption X is known.
>>>>> And because you use the same sequence to code the second half,
>>>>> there is no new information. H(X|Y) = 0.
>>>>
>>>> Sorry, I can't follow your contional entropy argument.
>>>
>>> https://en.wikipedia.org/wiki/Conditional_entropy
>>>
>>>> You wrote "... assumption X is known".
>>>
>>> This is a standard formula from propability theory.
>>> for two random variable X and Y, Y|X is a a distribution
>>> of Y if X is fixed.
>>>
>>>> But one can simply consider
>>>> that one has got n output bits from AES before doing anything
>>>> else. What is "known" at that time?
>>>
>>> I look at the first 128 bits of the code. Because I know
>>> original text, I can decode the sequance.
>>> If I look at the second 128 bits, I do not get any
>>> new information.
>>>
>>>> If none, what's the average
>>>> entropy per bit?
>>>
>>> It looks like average entropy is very consuming,
>>> because bits in your example are not independent.
>>>
>>> If you look at any 128bit chunk you get the whole 128bit
>>> of information.
>>> REad the second post about a candy.
>>
>> Sorry, I prefer not to be involved in discussing a different scenario
>> and like to know why the simply calculation of mine, which concerns
>> only input bits and output bits of AES alone (without involving
>> any subsequent operations done with the output bits) is anywhere
>> logically wrong.
>
>
> This is exactly the answer to you question about 'mean entropy'.
> You did not understand the direct answer because you do not
> know math about entropy. This is why I also wrote the second
> post about simplified problem, but with the same question
> and answer.
>
> If I have a candy in one hand I do not have a half of bits
> of enthropy in each hand. I have one bit in left and one
> bit in right. But both bits are corelated, so if you
> known one, you also known the second - second hand
> have zero entropy, because ("under the assuption the
> first hand in known") you known where the candy is.
>
> "Mean entropy" as you proposed ("128/n") have no sense,
> because probability doesn't work that way.

Ok, then simply entropy. Lets say that the 128 input bits
are all of full entropy, each bit has entropy of 1.0. We
assume that AES is very well designed such that the output
n bits are equally good. How much entropy has under this
assumption one output bit?

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5758

On 03.09.2015 01:28, Mok-Kong Shen wrote:
> Am 03.09.2015 um 01:21 schrieb bartekltg:

>>
>>
>> This is exactly the answer to you question about 'mean entropy'.
>> You did not understand the direct answer because you do not
>> know math about entropy. This is why I also wrote the second
>> post about simplified problem, but with the same question
>> and answer.
>>
>> If I have a candy in one hand I do not have a half of bits
>> of enthropy in each hand. I have one bit in left and one
>> bit in right. But both bits are corelated, so if you
>> known one, you also known the second - second hand
>> have zero entropy, because ("under the assuption the
>> first hand in known") you known where the candy is.
>>
>> "Mean entropy" as you proposed ("128/n") have no sense,
>> because probability doesn't work that way.
>
> Ok, then simply entropy. Lets say that the 128 input bits
> are all of full entropy, each bit has entropy of 1.0. We
> assume that AES is very well designed such that the output
> n bits are equally good. How much entropy has under this
> assumption one output bit?

One bit.
If AES is good, both 0 and 1 is equally probable,
so entropy is
-1/2*log(1/2) -1/2*log(1/2)  = 1


Entropy of two bits is almost two.

Entropy of the whole n bits is not greater than 128bits
//forth dot
https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties

bartekltg

[toc] | [prev] | [next] | [standalone]

#5761

Am 03.09.2015 um 02:01 schrieb bartekltg:
> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>
>>>
>>>
>>> This is exactly the answer to you question about 'mean entropy'.
>>> You did not understand the direct answer because you do not
>>> know math about entropy. This is why I also wrote the second
>>> post about simplified problem, but with the same question
>>> and answer.
>>>
>>> If I have a candy in one hand I do not have a half of bits
>>> of enthropy in each hand. I have one bit in left and one
>>> bit in right. But both bits are corelated, so if you
>>> known one, you also known the second - second hand
>>> have zero entropy, because ("under the assuption the
>>> first hand in known") you known where the candy is.
>>>
>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>> because probability doesn't work that way.
>>
>> Ok, then simply entropy. Lets say that the 128 input bits
>> are all of full entropy, each bit has entropy of 1.0. We
>> assume that AES is very well designed such that the output
>> n bits are equally good. How much entropy has under this
>> assumption one output bit?
>
> One bit.
> If AES is good, both 0 and 1 is equally probable,
> so entropy is
> -1/2*log(1/2) -1/2*log(1/2)  = 1
>
>
> Entropy of two bits is almost two.
>
> Entropy of the whole n bits is not greater than 128bits
> //forth dot
> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties

So, assuming that the n bits are equally good, the entropy
of each output bit is not greater than 128/n. A trivial
calculation, isn't it?

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5766

On 03.09.2015 02:22, Mok-Kong Shen wrote:
> Am 03.09.2015 um 02:01 schrieb bartekltg:
>> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>>
>>>>
>>>>
>>>> This is exactly the answer to you question about 'mean entropy'.
>>>> You did not understand the direct answer because you do not
>>>> know math about entropy. This is why I also wrote the second
>>>> post about simplified problem, but with the same question
>>>> and answer.
>>>>
>>>> If I have a candy in one hand I do not have a half of bits
>>>> of enthropy in each hand. I have one bit in left and one
>>>> bit in right. But both bits are corelated, so if you
>>>> known one, you also known the second - second hand
>>>> have zero entropy, because ("under the assuption the
>>>> first hand in known") you known where the candy is.
>>>>
>>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>>> because probability doesn't work that way.
>>>
>>> Ok, then simply entropy. Lets say that the 128 input bits
>>> are all of full entropy, each bit has entropy of 1.0. We
>>> assume that AES is very well designed such that the output
>>> n bits are equally good. How much entropy has under this
>>> assumption one output bit?
>>
>> One bit.
>> If AES is good, both 0 and 1 is equally probable,
>> so entropy is
>> -1/2*log(1/2) -1/2*log(1/2)  = 1
>>
>>
>> Entropy of two bits is almost two.
>>
>> Entropy of the whole n bits is not greater than 128bits
>> //forth dot
>> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties
>>
>
> So, assuming that the n bits are equally good, the entropy
> of each output bit is not greater than 128/n. A trivial
> calculation, isn't it?

No. You still don't get this hands and a candy story ;]


We have two bit random sequence.
00, 01, 10, 11, all with probability 1/4.

AES_2_4 generate:

AES(00) = 1011
AES(01) = 1000
AES(10) = 0111
AES(11) = 0110
[you can write better "AES" bunction and recalculate entropies]

Do you know definition of entropy?
x_i are possible sequewnces. P(x_i) propability od that seqence.
entropy H = \sum_i P(x_i)*log2(1/P(x_i))

Entropy of first bit is 1
Entropy of second bit is 1
entropy of third bit is 1/4log2(4) + 3/4log2(4/3) = 0.81128
entropy of fourth bit is 1

Entropy of first two bits?
We have only two possible sequences. 01 and 10.
Both have probability 1/2. So H = 1
First two bits have only one bit of entropy.
-How, first bit have one bit, and second bit have one bit,
this is total two bits!

look at the sequences. If I look at first bit and it is 1,
i know random sequieince was eithier 00 or 01.
But if I look at the second bit, I will not get any new information,
i knew before tjat second bit is NOT first bit.

First bit carry information, second bit carry information,
but this is the same information.

Second and third bit can be: 00, 01, 11. The last
with propability 1/2, first two - 1/4. H = 1.3466

The first and the last bit:
sequences:
11 10 01 00. propability od any =1/4. H=2.

If I look at these two bits, I can decipher whole sequence.
They carry whole information. If I know that, the rest of
the sequence have no more information for me.

Entropy of whole sequence is... of course 2 bits,
beceuse i have 4 possible sequences, echch with 1/4 chance.

bartekltg

[toc] | [prev] | [next] | [standalone]

#5768

Am 03.09.2015 um 02:51 schrieb bartekltg:
> On 03.09.2015 02:22, Mok-Kong Shen wrote:
>> Am 03.09.2015 um 02:01 schrieb bartekltg:
>>> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>>>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>>>
>>>>>
>>>>>
>>>>> This is exactly the answer to you question about 'mean entropy'.
>>>>> You did not understand the direct answer because you do not
>>>>> know math about entropy. This is why I also wrote the second
>>>>> post about simplified problem, but with the same question
>>>>> and answer.
>>>>>
>>>>> If I have a candy in one hand I do not have a half of bits
>>>>> of enthropy in each hand. I have one bit in left and one
>>>>> bit in right. But both bits are corelated, so if you
>>>>> known one, you also known the second - second hand
>>>>> have zero entropy, because ("under the assuption the
>>>>> first hand in known") you known where the candy is.
>>>>>
>>>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>>>> because probability doesn't work that way.
>>>>
>>>> Ok, then simply entropy. Lets say that the 128 input bits
>>>> are all of full entropy, each bit has entropy of 1.0. We
>>>> assume that AES is very well designed such that the output
>>>> n bits are equally good. How much entropy has under this
>>>> assumption one output bit?
>>>
>>> One bit.
>>> If AES is good, both 0 and 1 is equally probable,
>>> so entropy is
>>> -1/2*log(1/2) -1/2*log(1/2)  = 1
>>>
>>>
>>> Entropy of two bits is almost two.
>>>
>>> Entropy of the whole n bits is not greater than 128bits
>>> //forth dot
>>> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties
>>>
>>>
>>
>> So, assuming that the n bits are equally good, the entropy
>> of each output bit is not greater than 128/n. A trivial
>> calculation, isn't it?
>
> No. You still don't get this hands and a candy story ;]
>
>
> We have two bit random sequence.
> 00, 01, 10, 11, all with probability 1/4.
>
> AES_2_4 generate:
>
> AES(00) = 1011
> AES(01) = 1000
> AES(10) = 0111
> AES(11) = 0110
> [you can write better "AES" bunction and recalculate entropies]
>
> Do you know definition of entropy?
> x_i are possible sequewnces. P(x_i) propability od that seqence.
> entropy H = \sum_i P(x_i)*log2(1/P(x_i))
>
> Entropy of first bit is 1
> Entropy of second bit is 1
> entropy of third bit is 1/4log2(4) + 3/4log2(4/3) = 0.81128
> entropy of fourth bit is 1
>
> Entropy of first two bits?
> We have only two possible sequences. 01 and 10.
> Both have probability 1/2. So H = 1
> First two bits have only one bit of entropy.
> -How, first bit have one bit, and second bit have one bit,
> this is total two bits!
>
> look at the sequences. If I look at first bit and it is 1,
> i know random sequieince was eithier 00 or 01.
> But if I look at the second bit, I will not get any new information,
> i knew before tjat second bit is NOT first bit.
>
> First bit carry information, second bit carry information,
> but this is the same information.
>
> Second and third bit can be: 00, 01, 11. The last
> with propability 1/2, first two - 1/4. H = 1.3466
>
> The first and the last bit:
> sequences:
> 11 10 01 00. propability od any =1/4. H=2.
>
> If I look at these two bits, I can decipher whole sequence.
> They carry whole information. If I know that, the rest of
> the sequence have no more information for me.
>
> Entropy of whole sequence is... of course 2 bits,
> beceuse i have 4 possible sequences, echch with 1/4 chance.

Sorry, please find possible logical faults in what I have
stated in my paradox, e.g. why my calculation is wrong.

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5770

On 03.09.2015 02:57, Mok-Kong Shen wrote:
> Am 03.09.2015 um 02:51 schrieb bartekltg:
>> On 03.09.2015 02:22, Mok-Kong Shen wrote:
>>> Am 03.09.2015 um 02:01 schrieb bartekltg:
>>>> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>>>>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>>>>
>>>>>>
>>>>>>
>>>>>> This is exactly the answer to you question about 'mean entropy'.
>>>>>> You did not understand the direct answer because you do not
>>>>>> know math about entropy. This is why I also wrote the second
>>>>>> post about simplified problem, but with the same question
>>>>>> and answer.
>>>>>>
>>>>>> If I have a candy in one hand I do not have a half of bits
>>>>>> of enthropy in each hand. I have one bit in left and one
>>>>>> bit in right. But both bits are corelated, so if you
>>>>>> known one, you also known the second - second hand
>>>>>> have zero entropy, because ("under the assuption the
>>>>>> first hand in known") you known where the candy is.
>>>>>>
>>>>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>>>>> because probability doesn't work that way.
>>>>>
>>>>> Ok, then simply entropy. Lets say that the 128 input bits
>>>>> are all of full entropy, each bit has entropy of 1.0. We
>>>>> assume that AES is very well designed such that the output
>>>>> n bits are equally good. How much entropy has under this
>>>>> assumption one output bit?
>>>>
>>>> One bit.
>>>> If AES is good, both 0 and 1 is equally probable,
>>>> so entropy is
>>>> -1/2*log(1/2) -1/2*log(1/2)  = 1
>>>>
>>>>
>>>> Entropy of two bits is almost two.
>>>>
>>>> Entropy of the whole n bits is not greater than 128bits
>>>> //forth dot
>>>> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties
>>>>
>>>>
>>>>
>>>
>>> So, assuming that the n bits are equally good, the entropy
>>> of each output bit is not greater than 128/n. A trivial
>>> calculation, isn't it?
>>
>> No. You still don't get this hands and a candy story ;]
>>
>>
>> We have two bit random sequence.
>> 00, 01, 10, 11, all with probability 1/4.
>>
>> AES_2_4 generate:
>>
>> AES(00) = 1011
>> AES(01) = 1000
>> AES(10) = 0111
>> AES(11) = 0110
>> [you can write better "AES" bunction and recalculate entropies]
>>
>> Do you know definition of entropy?
>> x_i are possible sequewnces. P(x_i) propability od that seqence.
>> entropy H = \sum_i P(x_i)*log2(1/P(x_i))
>>
>> Entropy of first bit is 1
>> Entropy of second bit is 1
>> entropy of third bit is 1/4log2(4) + 3/4log2(4/3) = 0.81128
>> entropy of fourth bit is 1
>>
>> Entropy of first two bits?
>> We have only two possible sequences. 01 and 10.
>> Both have probability 1/2. So H = 1
>> First two bits have only one bit of entropy.
>> -How, first bit have one bit, and second bit have one bit,
>> this is total two bits!
>>
>> look at the sequences. If I look at first bit and it is 1,
>> i know random sequieince was eithier 00 or 01.
>> But if I look at the second bit, I will not get any new information,
>> i knew before tjat second bit is NOT first bit.
>>
>> First bit carry information, second bit carry information,
>> but this is the same information.
>>
>> Second and third bit can be: 00, 01, 11. The last
>> with propability 1/2, first two - 1/4. H = 1.3466
>>
>> The first and the last bit:
>> sequences:
>> 11 10 01 00. propability od any =1/4. H=2.
>>
>> If I look at these two bits, I can decipher whole sequence.
>> They carry whole information. If I know that, the rest of
>> the sequence have no more information for me.
>>
>> Entropy of whole sequence is... of course 2 bits,
>> beceuse i have 4 possible sequences, echch with 1/4 chance.
>
> Sorry, please find possible logical faults in what I have
> stated in my paradox, e.g. why my calculation is wrong.


"128/n bits of entropy in one bit" is wrong.
You do not give us mathematical proof of your claim,
so I cant point at a specific logical fault other than this.

I give you proof (based on definition of entropy, this
is easy stuff) that every single bit in your sequence
have (almost) one bit.

I'm sure that your problem now is 'how it is possible that
each of 135769461 bits have one bit of entropy, but we generated
it from only 128bits of entropy'.

The answer is a correlation between bits, and I put a nice example
in previous post (read it carefully, with wiki and calculator).

bartekltg

[toc] | [prev] | [next] | [standalone]

#5774

Am 03.09.2015 um 03:08 schrieb bartekltg:
> On 03.09.2015 02:57, Mok-Kong Shen wrote:
>> Am 03.09.2015 um 02:51 schrieb bartekltg:
>>> On 03.09.2015 02:22, Mok-Kong Shen wrote:
>>>> Am 03.09.2015 um 02:01 schrieb bartekltg:
>>>>> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>>>>>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is exactly the answer to you question about 'mean entropy'.
>>>>>>> You did not understand the direct answer because you do not
>>>>>>> know math about entropy. This is why I also wrote the second
>>>>>>> post about simplified problem, but with the same question
>>>>>>> and answer.
>>>>>>>
>>>>>>> If I have a candy in one hand I do not have a half of bits
>>>>>>> of enthropy in each hand. I have one bit in left and one
>>>>>>> bit in right. But both bits are corelated, so if you
>>>>>>> known one, you also known the second - second hand
>>>>>>> have zero entropy, because ("under the assuption the
>>>>>>> first hand in known") you known where the candy is.
>>>>>>>
>>>>>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>>>>>> because probability doesn't work that way.
>>>>>>
>>>>>> Ok, then simply entropy. Lets say that the 128 input bits
>>>>>> are all of full entropy, each bit has entropy of 1.0. We
>>>>>> assume that AES is very well designed such that the output
>>>>>> n bits are equally good. How much entropy has under this
>>>>>> assumption one output bit?
>>>>>
>>>>> One bit.
>>>>> If AES is good, both 0 and 1 is equally probable,
>>>>> so entropy is
>>>>> -1/2*log(1/2) -1/2*log(1/2)  = 1
>>>>>
>>>>>
>>>>> Entropy of two bits is almost two.
>>>>>
>>>>> Entropy of the whole n bits is not greater than 128bits
>>>>> //forth dot
>>>>> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> So, assuming that the n bits are equally good, the entropy
>>>> of each output bit is not greater than 128/n. A trivial
>>>> calculation, isn't it?
>>>
>>> No. You still don't get this hands and a candy story ;]
>>>
>>>
>>> We have two bit random sequence.
>>> 00, 01, 10, 11, all with probability 1/4.
>>>
>>> AES_2_4 generate:
>>>
>>> AES(00) = 1011
>>> AES(01) = 1000
>>> AES(10) = 0111
>>> AES(11) = 0110
>>> [you can write better "AES" bunction and recalculate entropies]
>>>
>>> Do you know definition of entropy?
>>> x_i are possible sequewnces. P(x_i) propability od that seqence.
>>> entropy H = \sum_i P(x_i)*log2(1/P(x_i))
>>>
>>> Entropy of first bit is 1
>>> Entropy of second bit is 1
>>> entropy of third bit is 1/4log2(4) + 3/4log2(4/3) = 0.81128
>>> entropy of fourth bit is 1
>>>
>>> Entropy of first two bits?
>>> We have only two possible sequences. 01 and 10.
>>> Both have probability 1/2. So H = 1
>>> First two bits have only one bit of entropy.
>>> -How, first bit have one bit, and second bit have one bit,
>>> this is total two bits!
>>>
>>> look at the sequences. If I look at first bit and it is 1,
>>> i know random sequieince was eithier 00 or 01.
>>> But if I look at the second bit, I will not get any new information,
>>> i knew before tjat second bit is NOT first bit.
>>>
>>> First bit carry information, second bit carry information,
>>> but this is the same information.
>>>
>>> Second and third bit can be: 00, 01, 11. The last
>>> with propability 1/2, first two - 1/4. H = 1.3466
>>>
>>> The first and the last bit:
>>> sequences:
>>> 11 10 01 00. propability od any =1/4. H=2.
>>>
>>> If I look at these two bits, I can decipher whole sequence.
>>> They carry whole information. If I know that, the rest of
>>> the sequence have no more information for me.
>>>
>>> Entropy of whole sequence is... of course 2 bits,
>>> beceuse i have 4 possible sequences, echch with 1/4 chance.
>>
>> Sorry, please find possible logical faults in what I have
>> stated in my paradox, e.g. why my calculation is wrong.
>
>
> "128/n bits of entropy in one bit" is wrong.
> You do not give us mathematical proof of your claim,
> so I cant point at a specific logical fault other than this.

But that's exactly simple math calculation, on the assumption
that AES output bits are equally good, i.e. having equal entropy,
isn't it? If you still don't want to accept this, then you should
at least, to be fair, also respond to the post of Wessel where he
agreed with my calculation and similarly tell him that he is wrong
and see what he will react to that!!

M. K. Shen

>
> I give you proof (based on definition of entropy, this
> is easy stuff) that every single bit in your sequence
> have (almost) one bit.
>
> I'm sure that your problem now is 'how it is possible that
> each of 135769461 bits have one bit of entropy, but we generated
> it from only 128bits of entropy'.
>
> The answer is a correlation between bits, and I put a nice example
> in previous post (read it carefully, with wiki and calculator).
>
> bartekltg
>
>
>
>
>

[toc] | [prev] | [next] | [standalone]

#5776

On 03.09.2015 03:31, Mok-Kong Shen wrote:
> Am 03.09.2015 um 03:08 schrieb bartekltg:
>> On 03.09.2015 02:57, Mok-Kong Shen wrote:
>>> Am 03.09.2015 um 02:51 schrieb bartekltg:
>>>> On 03.09.2015 02:22, Mok-Kong Shen wrote:
>>>>> Am 03.09.2015 um 02:01 schrieb bartekltg:
>>>>>> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>>>>>>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This is exactly the answer to you question about 'mean entropy'.
>>>>>>>> You did not understand the direct answer because you do not
>>>>>>>> know math about entropy. This is why I also wrote the second
>>>>>>>> post about simplified problem, but with the same question
>>>>>>>> and answer.
>>>>>>>>
>>>>>>>> If I have a candy in one hand I do not have a half of bits
>>>>>>>> of enthropy in each hand. I have one bit in left and one
>>>>>>>> bit in right. But both bits are corelated, so if you
>>>>>>>> known one, you also known the second - second hand
>>>>>>>> have zero entropy, because ("under the assuption the
>>>>>>>> first hand in known") you known where the candy is.
>>>>>>>>
>>>>>>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>>>>>>> because probability doesn't work that way.
>>>>>>>
>>>>>>> Ok, then simply entropy. Lets say that the 128 input bits
>>>>>>> are all of full entropy, each bit has entropy of 1.0. We
>>>>>>> assume that AES is very well designed such that the output
>>>>>>> n bits are equally good. How much entropy has under this
>>>>>>> assumption one output bit?
>>>>>>
>>>>>> One bit.
>>>>>> If AES is good, both 0 and 1 is equally probable,
>>>>>> so entropy is
>>>>>> -1/2*log(1/2) -1/2*log(1/2)  = 1
>>>>>>
>>>>>>
>>>>>> Entropy of two bits is almost two.
>>>>>>
>>>>>> Entropy of the whole n bits is not greater than 128bits
>>>>>> //forth dot
>>>>>> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> So, assuming that the n bits are equally good, the entropy
>>>>> of each output bit is not greater than 128/n. A trivial
>>>>> calculation, isn't it?
>>>>
>>>> No. You still don't get this hands and a candy story ;]
>>>>
>>>>
>>>> We have two bit random sequence.
>>>> 00, 01, 10, 11, all with probability 1/4.
>>>>
>>>> AES_2_4 generate:
>>>>
>>>> AES(00) = 1011
>>>> AES(01) = 1000
>>>> AES(10) = 0111
>>>> AES(11) = 0110
>>>> [you can write better "AES" bunction and recalculate entropies]
>>>>
>>>> Do you know definition of entropy?
>>>> x_i are possible sequewnces. P(x_i) propability od that seqence.
>>>> entropy H = \sum_i P(x_i)*log2(1/P(x_i))
>>>>
>>>> Entropy of first bit is 1
>>>> Entropy of second bit is 1
>>>> entropy of third bit is 1/4log2(4) + 3/4log2(4/3) = 0.81128
>>>> entropy of fourth bit is 1
>>>>
>>>> Entropy of first two bits?
>>>> We have only two possible sequences. 01 and 10.
>>>> Both have probability 1/2. So H = 1
>>>> First two bits have only one bit of entropy.
>>>> -How, first bit have one bit, and second bit have one bit,
>>>> this is total two bits!
>>>>
>>>> look at the sequences. If I look at first bit and it is 1,
>>>> i know random sequieince was eithier 00 or 01.
>>>> But if I look at the second bit, I will not get any new information,
>>>> i knew before tjat second bit is NOT first bit.
>>>>
>>>> First bit carry information, second bit carry information,
>>>> but this is the same information.
>>>>
>>>> Second and third bit can be: 00, 01, 11. The last
>>>> with propability 1/2, first two - 1/4. H = 1.3466
>>>>
>>>> The first and the last bit:
>>>> sequences:
>>>> 11 10 01 00. propability od any =1/4. H=2.
>>>>
>>>> If I look at these two bits, I can decipher whole sequence.
>>>> They carry whole information. If I know that, the rest of
>>>> the sequence have no more information for me.
>>>>
>>>> Entropy of whole sequence is... of course 2 bits,
>>>> beceuse i have 4 possible sequences, echch with 1/4 chance.
>>>
>>> Sorry, please find possible logical faults in what I have
>>> stated in my paradox, e.g. why my calculation is wrong.
>>
>>
>> "128/n bits of entropy in one bit" is wrong.
>> You do not give us mathematical proof of your claim,
>> so I cant point at a specific logical fault other than this.
>
> But that's exactly simple math calculation, on the assumption
> that AES output bits are equally good, i.e.

Yes.

> having equal entropy,

Be carefully. Can you prove that?
Yes, this is also true (for 1 bit sequnces, for k-sequences,
where 128<k<n is obviously not true).

Not only all bits have equal entropy, but all bits have
entropy equal to one bit.

 From 'entropy of every bit is equal' you can't conclude
that entropy is divided.



About that was the "candy"post.
I have one candy, keep it in one of two places.
Every place hold 1 bit of information, not half.

******too much messages ago***

I have one candy. I hide it in one of my hands and present
both hand to you. Information, where is the candy is one bit.
It is either in the left or in the right hand.

Do you think that if I open one of my hands, you get
a 1/2 bit of information? And when I open the second
one - net 1/2 bit of information?

No, the whole bit is in my left hand in the same way it is in
my right hand. When I open the first hand you will get whole bit
of information, and when I open the second hand, you gen no new
information, 0 bits.
****************



> isn't it? If you still don't want to accept this, then you should
> at least, to be fair, also respond to the post of Wessel where he
> agreed with my calculation and similarly tell him that he is wrong
> and see what he will react to that!!

I have posted an answer to his message, this post included a brief
description between a small volume of milk and random variables.

Also, think for yourself;>

bartekltg

[toc] | [prev] | [next] | [standalone]

#5777

Am 03.09.2015 um 03:45 schrieb bartekltg:
> On 03.09.2015 03:31, Mok-Kong Shen wrote:
>> Am 03.09.2015 um 03:08 schrieb bartekltg:
>>> On 03.09.2015 02:57, Mok-Kong Shen wrote:
>>>> Am 03.09.2015 um 02:51 schrieb bartekltg:
>>>>> On 03.09.2015 02:22, Mok-Kong Shen wrote:
>>>>>> Am 03.09.2015 um 02:01 schrieb bartekltg:
>>>>>>> On 03.09.2015 01:28, Mok-Kong Shen wrote:
>>>>>>>> Am 03.09.2015 um 01:21 schrieb bartekltg:
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is exactly the answer to you question about 'mean entropy'.
>>>>>>>>> You did not understand the direct answer because you do not
>>>>>>>>> know math about entropy. This is why I also wrote the second
>>>>>>>>> post about simplified problem, but with the same question
>>>>>>>>> and answer.
>>>>>>>>>
>>>>>>>>> If I have a candy in one hand I do not have a half of bits
>>>>>>>>> of enthropy in each hand. I have one bit in left and one
>>>>>>>>> bit in right. But both bits are corelated, so if you
>>>>>>>>> known one, you also known the second - second hand
>>>>>>>>> have zero entropy, because ("under the assuption the
>>>>>>>>> first hand in known") you known where the candy is.
>>>>>>>>>
>>>>>>>>> "Mean entropy" as you proposed ("128/n") have no sense,
>>>>>>>>> because probability doesn't work that way.
>>>>>>>>
>>>>>>>> Ok, then simply entropy. Lets say that the 128 input bits
>>>>>>>> are all of full entropy, each bit has entropy of 1.0. We
>>>>>>>> assume that AES is very well designed such that the output
>>>>>>>> n bits are equally good. How much entropy has under this
>>>>>>>> assumption one output bit?
>>>>>>>
>>>>>>> One bit.
>>>>>>> If AES is good, both 0 and 1 is equally probable,
>>>>>>> so entropy is
>>>>>>> -1/2*log(1/2) -1/2*log(1/2)  = 1
>>>>>>>
>>>>>>>
>>>>>>> Entropy of two bits is almost two.
>>>>>>>
>>>>>>> Entropy of the whole n bits is not greater than 128bits
>>>>>>> //forth dot
>>>>>>> https://en.wikipedia.org/wiki/Entropy_(information_theory)#Further_properties
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, assuming that the n bits are equally good, the entropy
>>>>>> of each output bit is not greater than 128/n. A trivial
>>>>>> calculation, isn't it?
>>>>>
>>>>> No. You still don't get this hands and a candy story ;]
>>>>>
>>>>>
>>>>> We have two bit random sequence.
>>>>> 00, 01, 10, 11, all with probability 1/4.
>>>>>
>>>>> AES_2_4 generate:
>>>>>
>>>>> AES(00) = 1011
>>>>> AES(01) = 1000
>>>>> AES(10) = 0111
>>>>> AES(11) = 0110
>>>>> [you can write better "AES" bunction and recalculate entropies]
>>>>>
>>>>> Do you know definition of entropy?
>>>>> x_i are possible sequewnces. P(x_i) propability od that seqence.
>>>>> entropy H = \sum_i P(x_i)*log2(1/P(x_i))
>>>>>
>>>>> Entropy of first bit is 1
>>>>> Entropy of second bit is 1
>>>>> entropy of third bit is 1/4log2(4) + 3/4log2(4/3) = 0.81128
>>>>> entropy of fourth bit is 1
>>>>>
>>>>> Entropy of first two bits?
>>>>> We have only two possible sequences. 01 and 10.
>>>>> Both have probability 1/2. So H = 1
>>>>> First two bits have only one bit of entropy.
>>>>> -How, first bit have one bit, and second bit have one bit,
>>>>> this is total two bits!
>>>>>
>>>>> look at the sequences. If I look at first bit and it is 1,
>>>>> i know random sequieince was eithier 00 or 01.
>>>>> But if I look at the second bit, I will not get any new information,
>>>>> i knew before tjat second bit is NOT first bit.
>>>>>
>>>>> First bit carry information, second bit carry information,
>>>>> but this is the same information.
>>>>>
>>>>> Second and third bit can be: 00, 01, 11. The last
>>>>> with propability 1/2, first two - 1/4. H = 1.3466
>>>>>
>>>>> The first and the last bit:
>>>>> sequences:
>>>>> 11 10 01 00. propability od any =1/4. H=2.
>>>>>
>>>>> If I look at these two bits, I can decipher whole sequence.
>>>>> They carry whole information. If I know that, the rest of
>>>>> the sequence have no more information for me.
>>>>>
>>>>> Entropy of whole sequence is... of course 2 bits,
>>>>> beceuse i have 4 possible sequences, echch with 1/4 chance.
>>>>
>>>> Sorry, please find possible logical faults in what I have
>>>> stated in my paradox, e.g. why my calculation is wrong.
>>>
>>>
>>> "128/n bits of entropy in one bit" is wrong.
>>> You do not give us mathematical proof of your claim,
>>> so I cant point at a specific logical fault other than this.
>>
>> But that's exactly simple math calculation, on the assumption
>> that AES output bits are equally good, i.e.
>
> Yes.
>
>> having equal entropy,
>
> Be carefully. Can you prove that?
> Yes, this is also true (for 1 bit sequnces, for k-sequences,
> where 128<k<n is obviously not true).

This is, as said, assumption. (For ease of discussion one could commonly
idealize a bit, or are you unfamiliar with that?)

> Not only all bits have equal entropy, but all bits have
> entropy equal to one bit.

Oh, then what is the total entropy of the n bits? You would then
have a wonderful machine of creating lots of entropy from 128 bits
input!!

Anyway, I repeat, please ALSO write an post answering Wessel,
similarly telling him that he is wrong in his calculation in your
opinion.

M. K. Shen
>
>  From 'entropy of every bit is equal' you can't conclude
> that entropy is divided.
>
>
>
> About that was the "candy"post.
> I have one candy, keep it in one of two places.
> Every place hold 1 bit of information, not half.
>
> ******too much messages ago***
>
> I have one candy. I hide it in one of my hands and present
> both hand to you. Information, where is the candy is one bit.
> It is either in the left or in the right hand.
>
> Do you think that if I open one of my hands, you get
> a 1/2 bit of information? And when I open the second
> one - net 1/2 bit of information?
>
> No, the whole bit is in my left hand in the same way it is in
> my right hand. When I open the first hand you will get whole bit
> of information, and when I open the second hand, you gen no new
> information, 0 bits.
> ****************
>
>
>
>> isn't it? If you still don't want to accept this, then you should
>> at least, to be fair, also respond to the post of Wessel where he
>> agreed with my calculation and similarly tell him that he is wrong
>> and see what he will react to that!!
>
> I have posted an answer to his message, this post included a brief
> description between a small volume of milk and random variables.
>
> Also, think for yourself;>
>
> bartekltg
>
>

[toc] | [prev] | [next] | [standalone]

#5779

On 03.09.2015 03:54, Mok-Kong Shen wrote:

>> Not only all bits have equal entropy, but all bits have
>> entropy equal to one bit.
>
> Oh, then what is the total entropy of the n bits?

128bits. I have just written that!


> You would then
> have a wonderful machine of creating lots of entropy from 128 bits
> input!!

I address this a couple of times.
READ!

bartekltg

[toc] | [prev] | [next] | [standalone]

#5781

Am 03.09.2015 um 04:18 schrieb bartekltg:
> On 03.09.2015 03:54, Mok-Kong Shen wrote:
>
>>> Not only all bits have equal entropy, but all bits have
>>> entropy equal to one bit.
>>
>> Oh, then what is the total entropy of the n bits?
>
> 128bits. I have just written that!
>
>
>> You would then
>> have a wonderful machine of creating lots of entropy from 128 bits
>> input!!
>
> I address this a couple of times.
> READ!

Before seeing your refuting the said post of Wessel, I'll
delay answering further posts from you.

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5784

On 03.09.2015 04:24, Mok-Kong Shen wrote:

> Before seeing your refuting the said post of Wessel, I'll
> delay answering further posts from you.

Ha, interesting!

This is exactly the approach I'm taking with your posts. Before you
acklowledge most basic facts about cryptography, I won't answer your
post at all.

Works out great so far. Not even surprised that you regurgitated your
ingenious PRNG ideas again.

I know, I know, either your Python PRNG is safe OR AES CTR is completely
broken. No other option here! You really should try publishing a paper
about your epiphanies. If you'd quote the reviewer's comments in here
for amusement I'd be delighted.

Cheers,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#5729

On Wed, 2 Sep 2015 10:48:15 +0200, 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),
>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.


Assuming the time value was microsecond resolution, and the attacker
can localize the time when you generated the primes to about a year,
he'd have to test no more than about 2**45 possible sets of primes.
IOW, this is fundamentally broken.

[toc] | [prev] | [next] | [standalone]

#5731

Am 02.09.2015 um 23:14 schrieb Robert Wessel:
> On Wed, 2 Sep 2015 10:48:15 +0200, 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),
>> 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.
>
>
> Assuming the time value was microsecond resolution, and the attacker
> can localize the time when you generated the primes to about a year,
> he'd have to test no more than about 2**45 possible sets of primes.
> IOW, this is fundamentally broken.

I only know that there is dependency on time but not how Python
actually does the seeding. Anyway, please see also my post to
Kylheku of 22:50.

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5734

On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Am 02.09.2015 um 23:14 schrieb Robert Wessel:
>> Assuming the time value was microsecond resolution, and the attacker
>> can localize the time when you generated the primes to about a year,
>> he'd have to test no more than about 2**45 possible sets of primes.
>> IOW, this is fundamentally broken.
>
> I only know that there is dependency on time but not how Python
> actually does the seeding.

As a crypto software developer, it's your *job* to know!

The fact that you don't know how Python does the seeding doesn't make
your program secure. The attacker knows.

I must ask again, how fucking dumb are you?

[toc] | [prev] | [next] | [standalone]

#5737

Am 02.09.2015 um 23:33 schrieb Kaz Kylheku:
> On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>> Am 02.09.2015 um 23:14 schrieb Robert Wessel:
>>> Assuming the time value was microsecond resolution, and the attacker
>>> can localize the time when you generated the primes to about a year,
>>> he'd have to test no more than about 2**45 possible sets of primes.
>>> IOW, this is fundamentally broken.
>>
>> I only know that there is dependency on time but not how Python
>> actually does the seeding.
>
> As a crypto software developer, it's your *job* to know!
>
> The fact that you don't know how Python does the seeding doesn't make
> your program secure. The attacker knows.
>
> I must ask again, how fucking dumb are you?

I am surprised, see my post of 23:46.

M. K. Shen

[toc] | [prev] | [next] | [standalone]

#5730

On 02.09.2015 10:48, Mok-Kong Shen 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.

This is not safe.
For cryptography use
random.SystemRandom
or
os.urandom(n)
in python;
std::random_device from <random>
in c++
...

bartekltg

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.programming

csiph-web