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


Groups > comp.programming > #5610

Re: JTRIG, SIGDEV

From Mok-Kong Shen <mok-kong.shen@t-online.de>
Newsgroups comp.programming
Subject Re: JTRIG, SIGDEV
Date 2015-08-08 10:25 +0200
Organization albasani.net
Message-ID <mq4edb$65k$1@news.albasani.net> (permalink)
References <mq1nsl$b1r$1@news.albasani.net> <20150807074449.236@kylheku.com> <mq2p8j$99k$1@news.albasani.net> <20150807143725.869@kylheku.com>

Show all headers | View raw


Am 07.08.2015 um 23:57 schrieb Kaz Kylheku:
[snip]
> RSA doesn't
> *specifically*  require a CSPRNG; but if a PRNG is used, it must be CS.

Could you kindly give a literature reference where such a requirement
could be found?

I can't yet believe that it's "always" a deadly sin, when a non-CSPRNG
is used somewhere in a crypto algorithm. As I wrote in the other
thread, that highly depends in my view on how and where the PRNs from
it are being used. Otherwise it would be difficult to understand IMHO
the fact that e.g. Bruce Schneier took the trouble to provide in his
book Applied Cryptography, 2nd ed. p.370, a not too short list of
linear congruential generators.

Since you seem to have expert knowledges on the issue of entropy,
I like to take the liberty at this opportunity to ask you for an
eventually nice explanation of an issue that has since long years highly
perplexed me: AES-128 or AES-256 in counter-mode is commonly considered
to be secure in practice to process with xor-ing a practically
arbitrarily long bit sequence, say of n bits. Now the enttropy input
to AES is at most 128 or 256 bits. Thus the average entropy of the bits
output from AES would be 128/n or 256/n bits. How could the processing
nonetheless be secure, if only n be moderately large, say n=10000?

M. K. Shen

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-07 09:48 +0200
  Re: JTRIG, SIGDEV Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-07 09:57 +0200
    Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-07 14:03 +0200
      Re: JTRIG, SIGDEV Kaz Kylheku <kaz@kylheku.com> - 2015-08-07 15:05 +0000
        Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-07 18:20 +0200
  Re: JTRIG, SIGDEV Kaz Kylheku <kaz@kylheku.com> - 2015-08-07 14:51 +0000
    Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-07 19:18 +0200
      Re: JTRIG, SIGDEV Kaz Kylheku <kaz@kylheku.com> - 2015-08-07 21:57 +0000
        Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-08 10:25 +0200
          Re: JTRIG, SIGDEV Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-08 19:57 +0200
            Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-08 22:14 +0200
              Re: JTRIG, SIGDEV Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-09 12:23 +0200
                Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-09 22:04 +0200
                Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-09 22:08 +0200
                Re: JTRIG, SIGDEV Richard Heathfield <rjh@cpax.org.uk> - 2015-08-11 17:15 +0100
      Re: JTRIG, SIGDEV Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-08 10:12 +0200
        Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-08 10:36 +0200
          Re: JTRIG, SIGDEV Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-08 15:25 +0200
            Re: JTRIG, SIGDEV Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-08 22:15 +0200

csiph-web