Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #5610
| 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> |
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
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