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

Groups > comp.programming > #5547 > unrolled thread

An advantage of RSA encryption

Back to article view | Back to comp.programming

Contents

  An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-01 16:52 +0200
    Re: An advantage of RSA encryption Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-01 20:17 +0200
      Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-01 23:04 +0200
        Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-02 04:32 +0200
        Re: An advantage of RSA encryption Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-08-02 19:36 +0200
          Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-02 21:04 +0200
            Re: An advantage of RSA encryption Kaz Kylheku <kaz@kylheku.com> - 2015-08-03 17:31 +0000
              Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 14:44 +0200
                Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:01 +0100
                  Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 15:07 +0200
                    Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:21 +0100
                      Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 15:24 +0200
                        Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:43 +0100
                          Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 15:49 +0200
                            Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 15:56 +0100
                              Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 22:05 +0200
                    Re: An advantage of RSA encryption Kaz Kylheku <kaz@kylheku.com> - 2015-08-04 15:24 +0000
                      Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 22:10 +0200
                        Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 21:42 +0100
                          Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 23:05 +0200
                            Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 22:18 +0100
                              Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 23:58 +0200
                                Re: An advantage of RSA encryption Chad <cdalten@gmail.com> - 2015-08-04 16:45 -0700
                                  Re: An advantage of RSA encryption Chad <cdalten@gmail.com> - 2015-08-04 16:55 -0700
                                    Re: An advantage of RSA encryption Chad <cdalten@gmail.com> - 2015-08-04 22:12 -0700
                                      Re: An advantage of RSA encryption Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 07:58 +0100
                                        Re: An advantage of RSA encryption Chad <cdalten@gmail.com> - 2015-08-05 08:06 -0700
    Re: An advantage of RSA encryption "J. Clarke" <j.clarke.873638@gmail.com> - 2015-08-03 06:50 -0400
      Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-03 18:28 +0200
        Re: An advantage of RSA encryption "J. Clarke" <j.clarke.873638@gmail.com> - 2015-08-05 22:07 -0400
          Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-06 11:01 +0200
    Re: An advantage of RSA encryption Mok-Kong Shen <mok-kong.shen@t-online.de> - 2015-08-04 15:26 +0200

Page 1 of 2  [1] 2  Next page →

#5547 — An advantage of RSA encryption

The fact that anyone could send an encrypted message to the owner of
a RSA public key in asymmetric encryption could be highly valuable in
cases e.g. activists in non-democratic countries send (if they manage
to anonymously send, eventually from an Internet cafe etc.) encrypted
messages to the press in democratic foreign countries containing
informations that, for some reasons, should not be immediately revealed
to the public, nor known to any third parties. The press might prefer
obtaining such anonymous encrypted messages. The public key is simply
announced in the media. (No certificates and CAs are needed at all!)

For a fairly simple and self-sufficient code (employing not
probabilistic but provable primes) to perform end-to-end RSA
encryption, see http://s13.zetaboards.com/Crypto/topic/7234475/1/

M. K. Shen

[toc] | [next] | [standalone]

#5548

On 01.08.2015 16:52, Mok-Kong Shen wrote:

> For a fairly simple and self-sufficient code (employing not
> probabilistic but provable primes) to perform end-to-end RSA
> encryption, see http://s13.zetaboards.com/Crypto/topic/7234475/1/

The fact that you rely on Python's random library for generation of
random numbers for cryptographic purposes reveals that you know
absolutely nothing about cryptography at all. Since you quote the HAC
maybe you should try to actually *read* it as well.

Don't try to convince people that you know what you're doing by fancy
shmancy stuff like provable primes. Instead, maybe focus on not trying
to make horribly amateurish mistakes like using "import random" for
cryptographically secure RNG.

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]

#5549

Am 01.08.2015 um 20:17 schrieb Johannes Bauer:
> On 01.08.2015 16:52, Mok-Kong Shen wrote:
>
>> For a fairly simple and self-sufficient code (employing not
>> probabilistic but provable primes) to perform end-to-end RSA
>> encryption, see http://s13.zetaboards.com/Crypto/topic/7234475/1/
>
> The fact that you rely on Python's random library for generation of
> random numbers for cryptographic purposes reveals that you know
> absolutely nothing about cryptography at all. Since you quote the HAC
> maybe you should try to actually *read* it as well.
>
> Don't try to convince people that you know what you're doing by fancy
> shmancy stuff like provable primes. Instead, maybe focus on not trying
> to make horribly amateurish mistakes like using "import random" for
> cryptographically secure RNG.

PRNs may be directly used as in stream encryption with xoring or
indirectly used. Depending on how indirectly the PRNs are employed,
it could be practically impossible to get from the result of using
the PRNs step by step to the values of the PRNs. Just to indicate
the idea: Suppose an array of
n objects are given and one uses n-1 PRNs to get with Fisher & Yates
a permuted array. (Note that at the base these PRNs are real-valued.)
Now it is practically very hard, I would say barely feasible, to
reconstruct from the two arrays the sequence of n-1 PRNs with sufficient 
accuracy and with that information find the seed of the
PRNG. If one does the permutation a second time and it is required to
reconstrct from the first and last array the PRNs, the task would be
evidently infeasible.

In the Maurer's algorithm there is nowhere a mention that the PRNs
used must be from a CSPRNG. So the requirement is statistically
satisfactory, which Python's PRNG satisfies extremely well.

M. K. Shen

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

#5550

Am 01.08.2015 um 23:04 schrieb Mok-Kong Shen:
> Am 01.08.2015 um 20:17 schrieb Johannes Bauer:
>> On 01.08.2015 16:52, Mok-Kong Shen wrote:
>>
>>> For a fairly simple and self-sufficient code (employing not
>>> probabilistic but provable primes) to perform end-to-end RSA
>>> encryption, see http://s13.zetaboards.com/Crypto/topic/7234475/1/
>>
>> The fact that you rely on Python's random library for generation of
>> random numbers for cryptographic purposes reveals that you know
>> absolutely nothing about cryptography at all. Since you quote the HAC
>> maybe you should try to actually *read* it as well.
>>
>> Don't try to convince people that you know what you're doing by fancy
>> shmancy stuff like provable primes. Instead, maybe focus on not trying
>> to make horribly amateurish mistakes like using "import random" for
>> cryptographically secure RNG.
>
> PRNs may be directly used as in stream encryption with xoring or
> indirectly used. Depending on how indirectly the PRNs are employed,
> it could be practically impossible to get from the result of using
> the PRNs step by step to the values of the PRNs. Just to indicate
> the idea: Suppose an array of
> n objects are given and one uses n-1 PRNs to get with Fisher & Yates
> a permuted array. (Note that at the base these PRNs are real-valued.)
> Now it is practically very hard, I would say barely feasible, to
> reconstruct from the two arrays the sequence of n-1 PRNs with sufficient
> accuracy and with that information find the seed of the
> PRNG. If one does the permutation a second time and it is required to
> reconstrct from the first and last array the PRNs, the task would be
> evidently infeasible.
>
> In the Maurer's algorithm there is nowhere a mention that the PRNs
> used must be from a CSPRNG. So the requirement is statistically
> satisfactory, which Python's PRNG satisfies extremely well.

I have to add:

(1) In my first paragraph n has to be of some not too small value.
In a degenerate case of a very small value for n, my argument could
eventually become problematical.

(2) Maurer's algorithm has the goal to deliver a provable prime
that is well randomly (uniformly) distributed in the statistical sense,
i.e. not necessarily in any cryptologically secure sense, over the set
of all primes of a specified size. See HAC p.152. Thus the PRNG
employed clearly needs only to be statistically good. Given that, the
security of an RSA encryption employing the keys generated with
Maurer's algorithm is dependent on the security of the RSA algorithm
and not dependent on any cryptological property of the PRNG employed
to implement Maurer's algorithm. I hope that this is clear.

M. K. Shen

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

#5551

On 01.08.2015 23:04, Mok-Kong Shen wrote:

> In the Maurer's algorithm there is nowhere a mention that the PRNs
> used must be from a CSPRNG. So the requirement is statistically
> satisfactory, which Python's PRNG satisfies extremely well.

It is unfortunate that you do not realize how blatantly obvious the
requirement for high-quality entropy sources for key generation really is.

Looking at the forum entry you posted you got exactly this advice
already about one year back and haven't even considered the implications
of your botched implementation. I'm not going to invent the time to
explain the blatantly obvious to you when you have sufficiently proven
that you ignore any advice which is given to you.

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]

#5552

Am 02.08.2015 um 19:36 schrieb Johannes Bauer:
> On 01.08.2015 23:04, Mok-Kong Shen wrote:
>
>> In the Maurer's algorithm there is nowhere a mention that the PRNs
>> used must be from a CSPRNG. So the requirement is statistically
>> satisfactory, which Python's PRNG satisfies extremely well.
>
> It is unfortunate that you do not realize how blatantly obvious the
> requirement for high-quality entropy sources for key generation really is.
>
> Looking at the forum entry you posted you got exactly this advice
> already about one year back and haven't even considered the implications
> of your botched implementation. I'm not going to invent the time to
> explain the blatantly obvious to you when you have sufficiently proven
> that you ignore any advice which is given to you.

If HAC and Maurer don't mention that a CSPRNG is required to
implement Maurer's algorithm, I can't imagine that they (both)
had by pure chance forgotten to do that, if a CSPRNG were indeed
necessary to do that implementation.

M. K. Shen

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

#5555

On 2015-08-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> If HAC and Maurer don't mention that a CSPRNG is required to
> implement Maurer's algorithm, I can't imagine that they (both)
> had by pure chance forgotten to do that, if a CSPRNG were indeed
> necessary to do that implementation.

This doesn't need to be spelled out, because the assumption that anyone
qualified to be reading the material isn't dumb as a fucking brick.

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

#5558

Am 03.08.2015 um 19:31 schrieb Kaz Kylheku:
> On 2015-08-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>> If HAC and Maurer don't mention that a CSPRNG is required to
>> implement Maurer's algorithm, I can't imagine that they (both)
>> had by pure chance forgotten to do that, if a CSPRNG were indeed
>> necessary to do that implementation.
>
> This doesn't need to be spelled out, because the assumption that anyone
> qualified to be reading the material isn't dumb as a fucking brick.
>
Your sentence is a bit ambiguous. Do you mean CSPRNG is required or
not in the present context? If yes, please kindly explain a bit.
(Note anyway that in HAC there is given a way to implement a CSPRNG
with RSA. So, if a CSPRNG were required to implement RSA, that
would lead to a viscious circle.)

M. K. Shen

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

#5559

On 04/08/15 13:44, Mok-Kong Shen wrote:
> Am 03.08.2015 um 19:31 schrieb Kaz Kylheku:
>> On 2015-08-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>> If HAC and Maurer don't mention that a CSPRNG is required to
>>> implement Maurer's algorithm, I can't imagine that they (both)
>>> had by pure chance forgotten to do that, if a CSPRNG were indeed
>>> necessary to do that implementation.
>>
>> This doesn't need to be spelled out, because the assumption that anyone
>> qualified to be reading the material isn't dumb as a fucking brick.
>>
> Your sentence is a bit ambiguous.

I don't see how.

> Do you mean CSPRNG is required or
> not in the present context? If yes, please kindly explain a bit.

Kaz means that a CSPRNG is required for Maurer's algorithm. My 
explanation of Kaz's meaning is by way of a parallel. Consider an 
algorithm for filling a bucket with water:

Step 1: place the bucket under the tap
Step 2: turn the tap on
Step 3: monitor the flow of water
Step 4: when the bucket is full, turn off the tap

At no stage does the algorithm say "ensure that the ambient temperature 
and pressure are such that the water is in liquid form" or "ensure that 
gravity is working" or "ensure that your bucket has no holes except the 
one for allowing water in at the top", but we may safely deduce these 
facts from the context, and anyone who needs these conditions to be 
spelled out may experience self-esteem challenges when their IQ is 
compared to that of a brick.

Kaz - fair summary?

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

#5560

Am 04.08.2015 um 15:01 schrieb Richard Heathfield:
> On 04/08/15 13:44, Mok-Kong Shen wrote:
>> Am 03.08.2015 um 19:31 schrieb Kaz Kylheku:
>>> On 2015-08-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>>> If HAC and Maurer don't mention that a CSPRNG is required to
>>>> implement Maurer's algorithm, I can't imagine that they (both)
>>>> had by pure chance forgotten to do that, if a CSPRNG were indeed
>>>> necessary to do that implementation.
>>>
>>> This doesn't need to be spelled out, because the assumption that anyone
>>> qualified to be reading the material isn't dumb as a fucking brick.
>>>
>> Your sentence is a bit ambiguous.
>
> I don't see how.
>
>> Do you mean CSPRNG is required or
>> not in the present context? If yes, please kindly explain a bit.
>
> Kaz means that a CSPRNG is required for Maurer's algorithm. My
> explanation of Kaz's meaning is by way of a parallel. Consider an
> algorithm for filling a bucket with water:
>
> Step 1: place the bucket under the tap
> Step 2: turn the tap on
> Step 3: monitor the flow of water
> Step 4: when the bucket is full, turn off the tap
>
> At no stage does the algorithm say "ensure that the ambient temperature
> and pressure are such that the water is in liquid form" or "ensure that
> gravity is working" or "ensure that your bucket has no holes except the
> one for allowing water in at the top", but we may safely deduce these
> facts from the context, and anyone who needs these conditions to be
> spelled out may experience self-esteem challenges when their IQ is
> compared to that of a brick.
>
> Kaz - fair summary?
>

ok. Then please comment on what I wrote in parentheses.

M. K. Shen

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

#5561

On 04/08/15 14:07, Mok-Kong Shen wrote:
> Am 04.08.2015 um 15:01 schrieb Richard Heathfield:
>> On 04/08/15 13:44, Mok-Kong Shen wrote:
>>> Am 03.08.2015 um 19:31 schrieb Kaz Kylheku:
>>>> On 2015-08-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>>>> If HAC and Maurer don't mention that a CSPRNG is required to
>>>>> implement Maurer's algorithm, I can't imagine that they (both)
>>>>> had by pure chance forgotten to do that, if a CSPRNG were indeed
>>>>> necessary to do that implementation.
>>>>
>>>> This doesn't need to be spelled out, because the assumption that anyone
>>>> qualified to be reading the material isn't dumb as a fucking brick.
>>>>
>>> Your sentence is a bit ambiguous.
>>
>> I don't see how.
>>
>>> Do you mean CSPRNG is required or
>>> not in the present context? If yes, please kindly explain a bit.
>>
>> Kaz means that a CSPRNG is required for Maurer's algorithm. My
>> explanation of Kaz's meaning is by way of a parallel. Consider an
>> algorithm for filling a bucket with water:
>>
>> Step 1: place the bucket under the tap
>> Step 2: turn the tap on
>> Step 3: monitor the flow of water
>> Step 4: when the bucket is full, turn off the tap
>>
>> At no stage does the algorithm say "ensure that the ambient temperature
>> and pressure are such that the water is in liquid form" or "ensure that
>> gravity is working" or "ensure that your bucket has no holes except the
>> one for allowing water in at the top", but we may safely deduce these
>> facts from the context, and anyone who needs these conditions to be
>> spelled out may experience self-esteem challenges when their IQ is
>> compared to that of a brick.
>>
>> Kaz - fair summary?
>>
>
> ok. Then please comment on what I wrote in parentheses.

"(both)"

What's to say? It's a word. It means "this one, and that one too". I 
don't get the question.

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

#5562

Am 04.08.2015 um 15:21 schrieb Richard Heathfield:
> On 04/08/15 14:07, Mok-Kong Shen wrote:
>> Am 04.08.2015 um 15:01 schrieb Richard Heathfield:
>>> On 04/08/15 13:44, Mok-Kong Shen wrote:
>>>> Am 03.08.2015 um 19:31 schrieb Kaz Kylheku:
>>>>> On 2015-08-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>>>>> If HAC and Maurer don't mention that a CSPRNG is required to
>>>>>> implement Maurer's algorithm, I can't imagine that they (both)
>>>>>> had by pure chance forgotten to do that, if a CSPRNG were indeed
>>>>>> necessary to do that implementation.
>>>>>
>>>>> This doesn't need to be spelled out, because the assumption that
>>>>> anyone
>>>>> qualified to be reading the material isn't dumb as a fucking brick.
>>>>>
>>>> Your sentence is a bit ambiguous.
>>>
>>> I don't see how.
>>>
>>>> Do you mean CSPRNG is required or
>>>> not in the present context? If yes, please kindly explain a bit.
>>>
>>> Kaz means that a CSPRNG is required for Maurer's algorithm. My
>>> explanation of Kaz's meaning is by way of a parallel. Consider an
>>> algorithm for filling a bucket with water:
>>>
>>> Step 1: place the bucket under the tap
>>> Step 2: turn the tap on
>>> Step 3: monitor the flow of water
>>> Step 4: when the bucket is full, turn off the tap
>>>
>>> At no stage does the algorithm say "ensure that the ambient temperature
>>> and pressure are such that the water is in liquid form" or "ensure that
>>> gravity is working" or "ensure that your bucket has no holes except the
>>> one for allowing water in at the top", but we may safely deduce these
>>> facts from the context, and anyone who needs these conditions to be
>>> spelled out may experience self-esteem challenges when their IQ is
>>> compared to that of a brick.
>>>
>>> Kaz - fair summary?
>>>
>>
>> ok. Then please comment on what I wrote in parentheses.
>
> "(both)"
>
> What's to say? It's a word. It means "this one, and that one too". I
> don't get the question.

I meant naturally the parentheses in my answer to Kylheku, namely:

(Note anyway that in HAC there is given a way to implement a CSPRNG
with RSA. So, if a CSPRNG were required to implement RSA, that
would lead to a viscious circle.)

M. K. Shen

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

#5564

On 04/08/15 14:24, Mok-Kong Shen wrote:
>
> I meant naturally the parentheses in my answer to Kylheku, namely:
>
> (Note anyway that in HAC there is given a way to implement a CSPRNG
> with RSA. So, if a CSPRNG were required to implement RSA, that
> would lead to a viscious circle.)


It isn't even a vicious circle, let alone a viscious circle. The easiest 
way to explain this is to consider two CSPRNGs, X and Y.

X can be used to generate RSA primes, thus making it possible to use RSA.

RSA can be used to implement Y.

I don't see the problem, and I certainly don't see any circles, be they 
vicious, viscious, viscous, or even vicarious.


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

#5565

Am 04.08.2015 um 15:43 schrieb Richard Heathfield:
> On 04/08/15 14:24, Mok-Kong Shen wrote:
>>
>> I meant naturally the parentheses in my answer to Kylheku, namely:
>>
>> (Note anyway that in HAC there is given a way to implement a CSPRNG
>> with RSA. So, if a CSPRNG were required to implement RSA, that
>> would lead to a viscious circle.)
>
>
> It isn't even a vicious circle, let alone a viscious circle. The easiest
> way to explain this is to consider two CSPRNGs, X and Y.
>
> X can be used to generate RSA primes, thus making it possible to use RSA.
>
> RSA can be used to implement Y.
>
> I don't see the problem, and I certainly don't see any circles, be they
> vicious, viscious, viscous, or even vicarious.

The problem is: Evidently (unless one wants to argue for argument's
sake) the (common) case is that one doesn't yet have a CSPRNG and
wants to have such a one to generate PRNs for an application. Now
how does one proceed??

M. K. Shen

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

#5566

On 04/08/15 14:49, Mok-Kong Shen wrote:

<snip>

> The problem is: Evidently (unless one wants to argue for argument's
> sake) the (common) case is that one doesn't yet have a CSPRNG and
> wants to have such a one to generate PRNs for an application. Now
> how does one proceed??

Either one is capable of writing one's own high-quality CSPRNG (in which 
case one wouldn't be asking the question), or one finds a good, reliable 
CSPRNG that is already publicly available for one's platform and which 
has been analysed by the cryptographic community and found to be fit for 
purpose.

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

#5570

Am 04.08.2015 um 16:56 schrieb Richard Heathfield:
> On 04/08/15 14:49, Mok-Kong Shen wrote:
>
> <snip>
>
>> The problem is: Evidently (unless one wants to argue for argument's
>> sake) the (common) case is that one doesn't yet have a CSPRNG and
>> wants to have such a one to generate PRNs for an application. Now
>> how does one proceed??
>
> Either one is capable of writing one's own high-quality CSPRNG (in which
> case one wouldn't be asking the question), or one finds a good, reliable
> CSPRNG that is already publicly available for one's platform and which
> has been analysed by the cryptographic community and found to be fit for
> purpose.

The one CSPRNG based on RSA that is described in HAC is a good,
reliable CSPRNG or not in your opinion? If yes, then one wants to
have that in doing an implementation accordingly. What's wrong with that???

M. K. Shen
W

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

#5567

On 2015-08-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
> ok. Then please comment on what I wrote in parentheses.

(dumb as a brick)

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

#5571

Am 04.08.2015 um 17:24 schrieb Kaz Kylheku:
> On 2015-08-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>> ok. Then please comment on what I wrote in parentheses.
>
> (dumb as a brick)
>
If you have good arguments, then give them. You are welcome to
aid Heathfield in his argumentation. But please argue objectively 
Otherwise simply doing defamations is bad IMHO.

M. K. Shen

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

#5572

On 04/08/15 21:10, Mok-Kong Shen wrote:
> Am 04.08.2015 um 17:24 schrieb Kaz Kylheku:
>> On 2015-08-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>> ok. Then please comment on what I wrote in parentheses.
>>
>> (dumb as a brick)
>>
> If you have good arguments, then give them. You are welcome to
> aid Heathfield in his argumentation.

It's the other way round. I was expanding on Kaz's contribution, not he 
on mine. Kaz knows a damn sight more about cryptography than I do.

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

#5573

Am 04.08.2015 um 22:42 schrieb Richard Heathfield:
> On 04/08/15 21:10, Mok-Kong Shen wrote:
>> Am 04.08.2015 um 17:24 schrieb Kaz Kylheku:
>>> On 2015-08-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
>>>> ok. Then please comment on what I wrote in parentheses.
>>>
>>> (dumb as a brick)
>>>
>> If you have good arguments, then give them. You are welcome to
>> aid Heathfield in his argumentation.
>
> It's the other way round. I was expanding on Kaz's contribution, not he
> on mine. Kaz knows a damn sight more about cryptography than I do.

This is not important for the discussion. Important are your
objective counterarguments to mine, if any.

M. K. Shen

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web