http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
This means that there is in the foreseeable future no danger of the
currently used asymmetric encryption schemes being broken by quantum
On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
This means that there is in the foreseeable future no danger of the
currently used asymmetric encryption schemes being broken by quantum
Phew! Your python-PRNG-based security schemes is safe!
"Mok-Kong Shen" wrote in message news:ms4114$nal$2@news.albasani.net...
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
This means that there is in the foreseeable future no danger of the
currently used asymmetric encryption schemes being broken by quantum >computers and one could consequently concentrate one's efforts in
attempting to improve the practical security of these schemes, e.g.
in authentication of the public keys and in prevention of eventually
possible backdoors being implanted in the software or hardware involved.
Am 01.09.2015 um 16:23 schrieb Kaz Kylheku:
On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
This means that there is in the foreseeable future no danger of the
currently used asymmetric encryption schemes being broken by quantum
Phew! Your python-PRNG-based security schemes is safe!
In another thread I asked you to provide a reference to support your
claim there but you still kept silence on that!
[For completeness I send a copy nonetheless to this group]
In my code PROVABLEPRIME
(http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed
to be input by the user at all. When the Python session starts, the
system employs the current time to seed its built-in PRNG. So each
time one uses the code to e.g. generate RSA keys, one gets a different
pair by chance. Certainly one could question the security of that from
an "exact" standpoint (I mean in the sense of proofs of pure math),
but there is in "practical" crypto in general IMHO no way to take that
exact standpoint and yet have useful things done. Does e.g. AES have
an exact proof of its security? There is none, at least to my humble knowledge.
["Followup-To:" header set to comp.programming.]contains as
On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
Am 01.09.2015 um 16:23 schrieb Kaz Kylheku:
On 2015-09-01, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
This means that there is in the foreseeable future no danger of the
currently used asymmetric encryption schemes being broken by quantum
Phew! Your python-PRNG-based security schemes is safe!
In another thread I asked you to provide a reference to support your
claim there but you still kept silence on that!
The reference is that the entire sequence coming out of a PRNG only
much information as its seed. For instance, a 32 bit seed means that the entire sequence contains at most 32 bits of information. (This istrue even if
the PRNG is a good one with a big state vector, and a long period.)say, 64
The seed is effectively a selector which chooses one of 2**32 different sequences.
If you generate, say, a 1024 bit key with a PRNG that is seeded with,
bits, then it's effectively a 64 bit key. Given a known plaintext and ciphertext pair, we only have to search a 64 bit space to recover thekey.
The encryption algorithm might be RSA-1024, but it's not really becauseobscurity"---
of the weak seeding; it is a misleading lie and "security through
you hope that the scheme is secure because the attacker doesn't knowspace is
that a particular weekly-seeded PRNG was used.
Do you also require a reference for the claim that water is wet?
Moreover, a PRNG may have other problems with it even if the state
large enough and the seed has enough entropy for the given crypto use.
About stream ciphers; yes they are lot like PRNG's where theencryption key
is a seed. The seed has an appropriate size to achieve a given security level, and no misleading claims are made about the space from which iteffectively
is chosen. If we use a 256 bit stream cipher, but seed it with a PRNG
that uses a 32 bit seed, we have the same problem: the cipher is
32 bit (but the users are duped into believing that it's the 256encrypted
bit real thing).
No, key entropy does not dilute with the increasing length of an
message. Suppose we have a very good symmetric cipher against whichthere is
no known attack other than brute force. Suppose the attacker knowsall of our
plaintext. It does not help the attacker to have a large quantity ofknown
plaintext. In fact using more plaintext/ciphertext pairs only slowsdown the
brute force search. For each key which is tried, it is enough to trya single
known ciphertext/plaintex pair.entropy,
Encryption does not work by spreading key entropy across a message.
The entropy in a key is important, however, for obvious reasons:
more entropy means a larger key space.
If an encryption algoirthm requires keys with a certain amount of
and is given less entropy, it is incompetently implemented. Its security
is weakened.
"Mok-Kong Shen" wrote in message news:ms4114$nal$2@news.albasani.net...
http://www.theplatform.net/2015/07/22/google-sees-long-expensive-road-ahead-for-quantum-computing/
The article doesn't seem to be much more optimistic than reports on
other well-known currently running big projects of physics, e.g.
nuclear fusion.
AFAICT, the following project has some promise:
http://www.dwavesys.com
On 2015-09-02, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
[For completeness I send a copy nonetheless to this group]
In my code PROVABLEPRIME
(http://s13.zetaboards.com/Crypto/topic/7234475/1/) there is no seed
to be input by the user at all. When the Python session starts, the
system employs the current time to seed its built-in PRNG. So each
time one uses the code to e.g. generate RSA keys, one gets a different
pair by chance. Certainly one could question the security of that from
No. It is known to be very insecure. You might get 10-20 bits of randomness that way but not more.
an "exact" standpoint (I mean in the sense of proofs of pure math),
but there is in "practical" crypto in general IMHO no way to take that
exact standpoint and yet have useful things done. Does e.g. AES have
an exact proof of its security? There is none, at least to my humble
knowledge.
Rot 13 cannot be proven to be secure, AES 256 cannot be proven to be
secure. Therefor Rot13 is as strong as AES 256. Can you see something
wrong with that logic?
I have in comment lines in my code already indicated how one could use Python's random.SystemRandom() instead of the normal random module.
I am now preparing an update that actually uses random.SystemRandom().
Am 03.09.2015 um 05:58 schrieb Mok-Kong Shen:
[snip]
I have in comment lines in my code already indicated how one could use
Python's random.SystemRandom() instead of the normal random module.
I am now preparing an update that actually uses random.SystemRandom().
The update, PROVABLEPRIME Version 1.2, has just been released.
On 2015-09-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
Am 03.09.2015 um 05:58 schrieb Mok-Kong Shen:
[snip]
I have in comment lines in my code already indicated how one could use
Python's random.SystemRandom() instead of the normal random module.
I am now preparing an update that actually uses random.SystemRandom().
The update, PROVABLEPRIME Version 1.2, has just been released.
The advantages of a provable prime are overhyped. The probability of not finding a prime if you use a probablistic approach are extremely small,
and algorithm for proving primality AFAIK is very slow. Already
generating primes is slow enough that people do not want to do it.
And, AFAIK if you use a non-prime in RSA you will not get the right
answers when you try to decrypt. So you will soon discover that you do
not have a real prime. Ie, speed is probably more important that
provability in this case.
So what is the speed of your implimentation vs the speed of
probabilistic approaches?
On 2015-09-04, Mok-Kong Shen <mok-kong.shen@t-online.de> wrote:
Am 03.09.2015 um 05:58 schrieb Mok-Kong Shen:
[snip]
I have in comment lines in my code already indicated how one could use
Python's random.SystemRandom() instead of the normal random module.
I am now preparing an update that actually uses random.SystemRandom().
The update, PROVABLEPRIME Version 1.2, has just been released.
The advantages of a provable prime are overhyped. The probability of not finding a prime if you use a probablistic approach are extremely small,
and algorithm for proving primality AFAIK is very slow. Already
generating primes is slow enough that people do not want to do it.
And, AFAIK if you use a non-prime in RSA you will not get the right
answers when you try to decrypt. So you will soon discover that you do
not have a real prime. Ie, speed is probably more important that
provability in this case.
So what is the speed of your implimentation vs the speed of
probabilistic approaches?
I have done a comparison. With my Python codes the mean values of
runtime obtained are as follows ..........
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 68:59:18 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,275,379 |