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

Groups > comp.programming > #5589 > unrolled thread

JTRIG, SIGDEV

Back to article view | Back to comp.programming

Contents

  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

#5589 — JTRIG, SIGDEV

 From an article of Glenn Greenwald
(https://firstlook.org/theintercept/20144/02/24/jtrig-manipulation)
I found the following interesting paragraph:

"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; and (2) to use social sciences
and other techniques to manipulate online discourse and activism to
generate outcomes it considers desirable. To see how extremist these
programs are, just consider the tactics they boast of using to achieve
those ends: “false flag operations” (posting material to the internet
and falsely attributing it to someone else), fake victim blog posts
(pretending to be a victim of the individual whose reputation they want
to destroy), and posting “negative information” on various forums."

M. K. Shen

[toc] | [next] | [standalone]

#5591

On 07.08.2015 09:48, Mok-Kong Shen wrote:
> 
> From an article of Glenn Greenwald
> (https://firstlook.org/theintercept/20144/02/24/jtrig-manipulation)
> I found the following interesting paragraph:

Which has to with with programming exactly *what*?

> "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;

Hmmm, so posting a clearly broken encryption algorithm, claiming it to
be secure and hoping for the "next Snowden" to use it would fall under
this strategy? Is this supposed to be a confession?

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]

#5594

Am 07.08.2015 um 09:57 schrieb Johannes Bauer:
> On 07.08.2015 09:48, Mok-Kong Shen wrote:
>>
>>  From an article of Glenn Greenwald
>> (https://firstlook.org/theintercept/20144/02/24/jtrig-manipulation)
>> I found the following interesting paragraph:
>
> Which has to with with programming exactly *what*?

I just wanted to call attention to the phenomenon of defamation
which unfavorably affects the discussion atmosphere in many groups.

M. K. Shen
>
>> "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;
>
> Hmmm, so posting a clearly broken encryption algorithm, claiming it to
> be secure and hoping for the "next Snowden" to use it would fall under
> this strategy? Is this supposed to be a confession?
>
> Cheers,
> Johannes
>

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

#5596

["Followup-To:" header set to comp.programming.]
On 2015-08-07, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> Am 07.08.2015 um 09:57 schrieb Johannes Bauer:
>> On 07.08.2015 09:48, Mok-Kong Shen wrote:
>>>
>>>  From an article of Glenn Greenwald
>>> (https://firstlook.org/theintercept/20144/02/24/jtrig-manipulation)
>>> I found the following interesting paragraph:
>>
>> Which has to with with programming exactly *what*?
>
> I just wanted to call attention to the phenomenon of defamation
> which unfavorably affects the discussion atmosphere in many groups.

Why don't you pause to lookup up "defamation" in an English dictionary?
Now what you've used the word several times, it is high time to formally
introduce yourself to its definition.

Defamation means that someone utters or writes something false about you which
damages your public reputation. (Uttered defamation is "slander" and written
defamation is "libel".)

Defamation would occur if someone announces that, for instance, he has seen you
steal something from a store. Some members of the public believe it, and so
your reputation is tarnished.  The announcement only defamation if it isn't true.

"You're an idiot" isn't defamation; it's clearly just an opinion.  Such an
opinion can be a justified, evidence-based comment on someone's recent
output in a network forum.

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

#5597

Am 07.08.2015 um 17:05 schrieb Kaz Kylheku:
> ["Followup-To:" header set to comp.programming.]
> On 2015-08-07, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>> Am 07.08.2015 um 09:57 schrieb Johannes Bauer:
>>> On 07.08.2015 09:48, Mok-Kong Shen wrote:
>>>>
>>>>   From an article of Glenn Greenwald
>>>> (https://firstlook.org/theintercept/20144/02/24/jtrig-manipulation)
>>>> I found the following interesting paragraph:
>>>
>>> Which has to with with programming exactly *what*?
>>
>> I just wanted to call attention to the phenomenon of defamation
>> which unfavorably affects the discussion atmosphere in many groups.
>
> Why don't you pause to lookup up "defamation" in an English dictionary?
> Now what you've used the word several times, it is high time to formally
> introduce yourself to its definition.
>
> Defamation means that someone utters or writes something false about you which
> damages your public reputation. (Uttered defamation is "slander" and written
> defamation is "libel".)
>
> Defamation would occur if someone announces that, for instance, he has seen you
> steal something from a store. Some members of the public believe it, and so
> your reputation is tarnished.  The announcement only defamation if it isn't true.
>
> "You're an idiot" isn't defamation; it's clearly just an opinion.  Such an
> opinion can be a justified, evidence-based comment on someone's recent
> output in a network forum.

I like to ask the general readers of the groups to remember that the
issue I quoted unfortunately exists in the world, each time when they
see arguments in the groups that are personal attacks and have nothing
to do with objective discussions. They could then better build their
own opinions about whether such personal attacks are indeed justified.

M. K. Shen

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

#5595

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".

Wait, when did you have a good reputation around here?

At the time of the From: line in your first posting, it was slightly
positive. It took a downturn to neutral in Subject: and continued
to plummet in the body.

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

#5599

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?

M. K. Shen

> Wait, when did you have a good reputation around here?
>
> At the time of the From: line in your first posting, it was slightly
> positive. It took a downturn to neutral in Subject: and continued
> to plummet in the body.
>

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

#5606

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.

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

#5610

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

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

#5614

On 08.08.2015 10:25, Mok-Kong Shen wrote:

> I can't yet believe that it's "always" a deadly sin, when a non-CSPRNG
> is used somewhere in a crypto algorithm.

It isn't. There are applications for painfully broken RNGs even in
cryptographic algorithms.

One example would be Miller-Rabin primality testing.

Another one would be determining square roots in finite fields. For
Tonelli-Shanks you need a quadratic non-residue to perform the
operation. You can use any old RNG and just try if you found a QNR.

Both appear within cryptogaphic software. What everyone tries to stuff
into your brain however is that is is NOT OKAY to use such broken RNGs
for key generation. But you just won't understand and repeat the same
drivel over and over and over without once thinking about the whole
thing. That's pretty damn sad.

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]

#5615

Am 08.08.2015 um 19:57 schrieb Johannes Bauer:
> On 08.08.2015 10:25, Mok-Kong Shen wrote:
>
>> I can't yet believe that it's "always" a deadly sin, when a non-CSPRNG
>> is used somewhere in a crypto algorithm.
>
> It isn't. There are applications for painfully broken RNGs even in
> cryptographic algorithms.
>
> One example would be Miller-Rabin primality testing.
>
> Another one would be determining square roots in finite fields. For
> Tonelli-Shanks you need a quadratic non-residue to perform the
> operation. You can use any old RNG and just try if you found a QNR.
>
> Both appear within cryptogaphic software. What everyone tries to stuff
> into your brain however is that is is NOT OKAY to use such broken RNGs
> for key generation. But you just won't understand and repeat the same
> drivel over and over and over without once thinking about the whole
> thing. That's pretty damn sad.

But could you kindly give concrete reasons why in the one case it's
ok, while in the other it isn't??

M. K. Shen

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

#5618

On 08.08.2015 22:14, Mok-Kong Shen wrote:

> But could you kindly give concrete reasons why in the one case it's
> ok, while in the other it isn't??

Did you think about this for a SINGLE SECOND? Or are you deliberately
trolling?

Algorithms like Miller-Rabin are pseudo-deterministic. They have a
(extremely small) failure probability, but if you ignore that (and it
can be made arbitrarily small) then the output of the algorithm is
deterministic. For Miller-Rabin it ALWAYS outputs "prime" if the input
as a prime and it ALWAYS outputs "non-prime" if the input was not a prime.

Key generation is supposed to be NON DETERMINISTIC. You do not want
someone to be able recreate your circumstances, set the time to the time
your machine has and be able to recreate the same cryptographic keys.

Because then your keys are not secret any more and your system is
fundamentally broken. Just like your "crypto" system is.

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]

#5619

Am 09.08.2015 um 12:23 schrieb Johannes Bauer:
> On 08.08.2015 22:14, Mok-Kong Shen wrote:
>
>> But could you kindly give concrete reasons why in the one case it's
>> ok, while in the other it isn't??
>
> Did you think about this for a SINGLE SECOND? Or are you deliberately
> trolling?
>
> Algorithms like Miller-Rabin are pseudo-deterministic. They have a
> (extremely small) failure probability, but if you ignore that (and it
> can be made arbitrarily small) then the output of the algorithm is
> deterministic. For Miller-Rabin it ALWAYS outputs "prime" if the input
> as a prime and it ALWAYS outputs "non-prime" if the input was not a prime.
>
> Key generation is supposed to be NON DETERMINISTIC. You do not want
> someone to be able recreate your circumstances, set the time to the time
> your machine has and be able to recreate the same cryptographic keys.
>
> Because then your keys are not secret any more and your system is
> fundamentally broken. Just like your "crypto" system is.

Pardon, it is not clear for me from the above whether you support
Miller-Rabin to generate RSA-Keys or not. Since "pseudo-deterministic"
is not the same as "non-deterministic", I guess the answer would
probably be negative. Am I right in this? A further question is: I
am only familier with the concept of "pseudo-random" but how is
"pseudo-deterministic" a concept compared to "pseudo-random"? (Any
reference to "pseudo-deterministic"?) Thanks in advance.

BTW, I had posted a reply to your another post of 08.08.2015 22:15.
Could you kindly give a reply to that as well?

M. K. Shen

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

#5620

Am 09.08.2015 um 22:04 schrieb Mok-Kong Shen:
> Am 09.08.2015 um 12:23 schrieb Johannes Bauer:
>> On 08.08.2015 22:14, Mok-Kong Shen wrote:
>>
>>> But could you kindly give concrete reasons why in the one case it's
>>> ok, while in the other it isn't??
>>
>> Did you think about this for a SINGLE SECOND? Or are you deliberately
>> trolling?
>>
>> Algorithms like Miller-Rabin are pseudo-deterministic. They have a
>> (extremely small) failure probability, but if you ignore that (and it
>> can be made arbitrarily small) then the output of the algorithm is
>> deterministic. For Miller-Rabin it ALWAYS outputs "prime" if the input
>> as a prime and it ALWAYS outputs "non-prime" if the input was not a
>> prime.
>>
>> Key generation is supposed to be NON DETERMINISTIC. You do not want
>> someone to be able recreate your circumstances, set the time to the time
>> your machine has and be able to recreate the same cryptographic keys.
>>
>> Because then your keys are not secret any more and your system is
>> fundamentally broken. Just like your "crypto" system is.
>
> Pardon, it is not clear for me from the above whether you support
> Miller-Rabin to generate RSA-Keys or not. Since "pseudo-deterministic"
> is not the same as "non-deterministic", I guess the answer would
> probably be negative. Am I right in this? A further question is: I
> am only familier with the concept of "pseudo-random" but how is
> "pseudo-deterministic" a concept compared to "pseudo-random"? (Any
> reference to "pseudo-deterministic"?) Thanks in advance.
>
> BTW, I had posted a reply to your another post of 08.08.2015 22:15.
> Could you kindly give a reply to that as well?

Sorry, 22:15 was my post, your post was 15:25.

M. K. Shen

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

#5621

On 09/08/15 11:23, Johannes Bauer wrote:
> On 08.08.2015 22:14, Mok-Kong Shen wrote:
>
>> But could you kindly give concrete reasons why in the one case it's
>> ok, while in the other it isn't??
>
> Did you think about this for a SINGLE SECOND? Or are you deliberately
> trolling?

I don't think he's trolling. I really do think he's sincere. But I also 
think he hasn't got the brains he was born with. Why else would he copy 
his Usenet responses to email?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#5609

On 07.08.2015 19:18, Mok-Kong Shen wrote:

> 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?

Yes.

You seem to think that a CSPRNG is the only way to generate keys. That
is absolutely false.

For key generation typically a TRNG is used. If it is absolutely
necessary, then one may rely on a CSPRNG that has been seeded by a TRNG.
Under no circumstances is any of the following ever a surrogate for a TRNG:

(1) A regular PRNG (even if seeded by a TRNG)
(2) A CSRNG seeded by deterministic data

You're using the worst of two world: A regular PRNG seeded by
deterministic data and claim to use secure key generation.

And you repeatedly spreading that somehow an RSA-CSPRNG would be a
prerequisite or the only way to generate RSA keys is ludicrous. You
clearly demonstrate your vast inaptitude when it comes to cryptography
time and time again.

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]

#5611

Am 08.08.2015 um 10:12 schrieb Johannes Bauer:
> On 07.08.2015 19:18, Mok-Kong Shen wrote:
>
>> 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?
>
> Yes.
>
> You seem to think that a CSPRNG is the only way to generate keys. That
> is absolutely false.
>
> For key generation typically a TRNG is used. If it is absolutely
> necessary, then one may rely on a CSPRNG that has been seeded by a TRNG.
> Under no circumstances is any of the following ever a surrogate for a TRNG:
>
> (1) A regular PRNG (even if seeded by a TRNG)
> (2) A CSRNG seeded by deterministic data
>
> You're using the worst of two world: A regular PRNG seeded by
> deterministic data and claim to use secure key generation.
>
> And you repeatedly spreading that somehow an RSA-CSPRNG would be a
> prerequisite or the only way to generate RSA keys is ludicrous. You
> clearly demonstrate your vast inaptitude when it comes to cryptography
> time and time again.

Oh, I don't remember to have ever claimed that "somehow an RSA-CSPRNG
would be a prerequisite or the only way to generate RSA keys"!! Could
you please quote me?

You seem also to be an expert in issues of entropy. Could you please
read my answer to Kylheku, just sent, and eventually provide answers
to points that he may not sufficiently cover in his next post?

M. K. Shen

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

#5612

On 08.08.2015 10:36, Mok-Kong Shen wrote:

> Oh, I don't remember to have ever claimed that "somehow an RSA-CSPRNG
> would be a prerequisite or the only way to generate RSA keys"!! Could
> you please quote me?

"there would have been a vicious circle in implementation"

No. There isn't. Because RSA-CSPRNG is not the only way to generate RSA
keys. Therefore no "vicious cycle".

> You seem also to be an expert in issues of entropy. Could you please
> read my answer to Kylheku, just sent, and eventually provide answers
> to points that he may not sufficiently cover in his next post?

The posting is so full of errors that it makes my stomach turn.

It starts with the fact that you don't even know what the blocksize of
AES-128 vs. AES-256 is. Hint: They're identical.

Then you continue to say that the output entropy would be half the
output bits. How do you arrive at this conclusion? It is clearly an
obviosly false. If AES were an ideal block cipher, the amount of output
entropy would be the output blocksize. 128 bits for AES.

Then you seem to assume that nonces are reused. They is not. CTR mode of
operation is not safe when nonces are reused, this is a blantly obvious
fact. One that even stands in every textbook should you ever read one.

If counters are not reused and AES were a perfect block cipher, there is
no correlation between outputs. Your whole conclusion therefore makes
zero sense.

Your amateurish understanding of cryptography combined with the
stubborness on completely obvious topics makes for a dangerous combination.

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]

#5616

Am 08.08.2015 um 15:25 schrieb Johannes Bauer:
> On 08.08.2015 10:36, Mok-Kong Shen wrote:
>
>> Oh, I don't remember to have ever claimed that "somehow an RSA-CSPRNG
>> would be a prerequisite or the only way to generate RSA keys"!! Could
>> you please quote me?
>
> "there would have been a vicious circle in implementation"
>
> No. There isn't. Because RSA-CSPRNG is not the only way to generate RSA
> keys. Therefore no "vicious cycle".

You misread my argument. My argument is: In HAC there is a way to
realize a CSPRNG using RSA. Now suppose in getting RSA keys one
would need a CSPRNG, then one couldn't proceed (if one doesn't
have a CSPRNG at the beginning). Is that clear now??

>
>> You seem also to be an expert in issues of entropy. Could you please
>> read my answer to Kylheku, just sent, and eventually provide answers
>> to points that he may not sufficiently cover in his next post?
>
> The posting is so full of errors that it makes my stomach turn.
>
> It starts with the fact that you don't even know what the blocksize of
> AES-128 vs. AES-256 is. Hint: They're identical.

Where did the "block size" play a role in my argument?? (Did I write
"block size" in my earlier post?? I said that the entropy input are
in the 2 cases 128 and 256 bits. Is your stomach startomg to get a
little bit better now??)

>
> Then you continue to say that the output entropy would be half the
> output bits. How do you arrive at this conclusion? It is clearly an
> obviosly false. If AES were an ideal block cipher, the amount of output
> entropy would be the output blocksize. 128 bits for AES.

You totally misunderstood! Take just the case of AES-128. I throw
dice to get 128 bits of full entropy and use that as the key.
Now I employ counter mode to generate 10000 bits and use that output.
What is the average entropy of one bit in that output bit sequence?
128/10000 bit (at most), correct or not??

> Then you seem to assume that nonces are reused. They is not. CTR mode of
> operation is not safe when nonces are reused, this is a blantly obvious
> fact. One that even stands in every textbook should you ever read one.

How did you come to your nonces in this context?? The above is one
"single" experiment!!

M. K. Shen

> If counters are not reused and AES were a perfect block cipher, there is
> no correlation between outputs. Your whole conclusion therefore makes
> zero sense.
>
> Your amateurish understanding of cryptography combined with the
> stubborness on completely obvious topics makes for a dangerous combination.
>
> Cheers,
> Johannes
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web