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

Groups > comp.programming > #5606

Re: JTRIG, SIGDEV

Show all headers | View raw

On 2015-08-07, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Am 07.08.2015 um 16:51 schrieb Kaz Kylheku:
>> On 2015-08-07, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>> "Among the core self-identified purposes of JTRIG are two tactics: (1)
>>> to inject all sorts of false material onto the internet in order to
>>> destroy the reputation of its targets.
>>
>> This does not apply when the target is yourself and you believe the false
>> material that you're posting that is ruining your own reputation,
>> like "Python's PRNG is good enough for generating RSA keys and one-time pads"
>> and "if an academic paper doesn't explicitly spell out an assumption,
>> then such an assumption doesn't hold".
>
> In the other thread I argued that, since an algorithm of CSPRNG
> given in HAC is based on RSA, there would have been a vicious
> circle in implementation, if the generation of RSA keys had required
> from the outset an CSPRNG. (If this 2nd CSPRNG is not available,
> then the implementation of the first CSPRNG is obviously impossible.
> If the 2nd CSPRNG is available, then in the clearly majority of cases
> in practice one would (for convenience and economy) simply use that
> 2nd CSPRNG and not spend any additional time and efforts to do an
> implementation for the 1st CSPRNG.
>
> Is there any logical error in my argument above?

Numerous.

Your closing claim that nobody will bother implement two CSPRNG's is not a fact
at all, just an unfounded opinion.

RSA key generation doesn't require any kind of PRNG. It requires *entropy*. If
a PRNG has sufficient entropy (from a real source of randomness, needless to
say) and other qualities then it can be used.

There exists neither a chicken-and-egg problem, nor the requirement for two
CSPRNG implementation. A library can provide RSA and an RSA-based PRNG.
Instances of that PRNG need to generate keys. That can be done using some pool
of random bits from the operating system.  At the same time, the application
API can provide the option that RSA key generation could use the RSA-based PRNG
(together with random bits from the OS).  The key generation is simply
switchable between the raw (or "lightly massaged") source of bits and PRNG.
When the RSA-based PRNG is being instantiated and calls the key generation API,
it of course selects the alternative source of randomness to be used, and not a
recursive instance of itself!

I'd expect a co-op student to be able to work out the framework for this.

All CSPRNG's are only secure to the extent that they are seeded with
truly random bits. You cannot extract more entropy from them than what was put
in. Moreover, they can spoil  the entropy that is there. For instance,
a PRNG which takes in 10000000 bits of entropy, but then keeps returning
repetitions of the number 42, isn't  any good!

Your claim that "RSA key generation doesn't require a CSPRNG therefore I can
use any PRNG, like the one in Python" is *moronically* illogical.  RSA doesn't
*specifically* require a CSPRNG; but if a PRNG is used, it must be CS.
Whenever a CSPRNG is used for generating keys, it is acting as a broker for the
entropy bits that it was seeded with.  Those entropy is what the key generation
needs, not the PRNG specifically.

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