On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/

One-time-pads are cheap and easy nowadays, and nothing can crack that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/15/23 18:32, John Larkin wrote:

On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs <bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/

One-time-pads are cheap and easy nowadays, and nothing can crack that.

I don't believe quantum computers will ever deliver. One-time-
pads aren't really a solution either. There are two problems:
How do you produce them and how do you deliver them?

The beauty of public key encryption is that anyone can send you
an encrypted message that only you can decrypt. The public key
is the product of two very large primes and the algorithm is
such that that you need the individual primes, the private key,
to decode the message. The security of the algorithm relies on
the difficulty of finding those primes.

Up to present, as far as I know, quantum computers haven't yet
succeeded in finding the prime factors of numbers with more than
three digits. There is still a long way to go. As I understand
Shor's algorithm, they aren't likely to ever get there. I believe
the limits of Shor's algorithm are about the same as our ability
to measure time or frequency, with goes to 18 digits or so, a
far cry from the 512+ digits required to attack current public
key algorithms by that approach.

Historically, it has always been far easier to capture the sender
or addressee and menace/torture him a bit.

Jeroen Belleman

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 15 Dec 2023 19:18:54 +0100, Jeroen Belleman
<jeroen@nospam.please> wrote:

On 12/15/23 18:32, John Larkin wrote:

On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/ >>

One-time-pads are cheap and easy nowadays, and nothing can crack that.

I don't believe quantum computers will ever deliver. One-time-
pads aren't really a solution either. There are two problems:
How do you produce them and how do you deliver them?

A hardware-based random number generator, and memory sticks.

The beauty of public key encryption is that anyone can send you
an encrypted message that only you can decrypt. The public key
is the product of two very large primes and the algorithm is
such that that you need the individual primes, the private key,
to decode the message. The security of the algorithm relies on
the difficulty of finding those primes.

That keeps getting easier. If quantum computers ever really work, they
could crack public encryption instantly.

Up to present, as far as I know, quantum computers haven't yet
succeeded in finding the prime factors of numbers with more than
three digits. There is still a long way to go. As I understand
Shor's algorithm, they aren't likely to ever get there. I believe
the limits of Shor's algorithm are about the same as our ability
to measure time or frequency, with goes to 18 digits or so, a
far cry from the 512+ digits required to attack current public
key algorithms by that approach.

Historically, it has always been far easier to capture the sender
or addressee and menace/torture him a bit.

Jeroen Belleman

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/15/2023 11:18 AM, Jeroen Belleman wrote:

I don't believe quantum computers will ever deliver. One-time-
pads aren't really a solution either. There are two problems:
How do you produce them and how do you deliver them?

OTPs need to be truly random to be effective. And, of a size
comparable to the size of the message being protected. The
randomness aspect precludes the use of any "set of bits" that
already exists "in the wild" (e.g., the text of "War and Peace")
as those things are likely available to adversaries AND not
truly random.

ALL users of a pad have to be kept in sync -- or, "told"
of the (nonoverlapping) offset into the pad that should be
used as the start for this message (which leaks information
as to the size of previous messages).

And, if you can SECURELY distribute a pad of size X, then
why not distribute your MESSAGE using the same SECURE
mechanism?

Also, keep in mind that for interactive *communications*
running at bus speeds, you can consume a huge pad in
milliseconds. Which suggests you don't really use a
predistributed pad but, rather, synthesize one on the
fly (PRNG) -- which then reduces the effort to crack.

The beauty of public key encryption is that anyone can send you
an encrypted message that only you can decrypt. The public key
is the product of two very large primes and the algorithm is
such that that you need the individual primes, the private key,
to decode the message. The security of the algorithm relies on
the difficulty of finding those primes.

That's ONE approach. All rely on a one-way function, at some
point. But, one way functions tend to (when intensely
scrutinized) fall victim to other forms of attack -- because
you don't just attack the *math* but, rather, the PROTOCOL,
as well.

<https://arstechnica.com/security/2023/11/hackers-can-steal-ssh-cryptographic-keys-in-new-cutting-edge-attack/>

The problem with primes is they are immutable. Once you know one,
it is ALWAYS known. So, whatever was able to find primes p & q
can be replicated by anyone else with that same technology and
level of resources.

[This is the source of vulnerabilities in commodity protocols
built on this... everyone uses the same primes!]

Up to present, as far as I know, quantum computers haven't yet
succeeded in finding the prime factors of numbers with more than
three digits. There is still a long way to go. As I understand
Shor's algorithm, they aren't likely to ever get there. I believe
the limits of Shor's algorithm are about the same as our ability
to measure time or frequency, with goes to 18 digits or so, a
far cry from the 512+ digits required to attack current public
key algorithms by that approach.

You don't try to factor the key. Instead, you explore the range of
POSSIBLE keys using your (accumulating) list of known primes in
a brute force attack. When you *stumble* on the correct pair,
then you implicitly know the private key.

As there is no mechanism that prevents you from throwing
keys at a message as fast as possible (unlike an artificial
timeout imposed in a login procedure), then any advantages
in your computational ability translate to attack gains.

Historically, it has always been far easier to capture the sender
or addressee and menace/torture him a bit.

If the "sender" (message) is dead (stale), that is a moot point.

But, being able to see what was *previously* considered a secret
also has value -- especially if the agents involved had assumed
their secrets were durable and didn't guard them in their
protected forms.

A nation state may be interested in learning another's internal
decision making process unfolded on some major issue by
consulting decades old "secrets" in the hope of gaining insight
to how said state would likely approach a NEW issue.

Or, what the "secret" to access the vault WAS, yesterday
(in the hope that it hasn't changed, today).

Encryption really only has practical value over very short time
intervals.

[Why have we waited 60 years to learn the details of the JFK
assassination investigation?]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/15/23 19:29, John Larkin wrote:

On Fri, 15 Dec 2023 19:18:54 +0100, Jeroen Belleman
<jeroen@nospam.please> wrote:

On 12/15/23 18:32, John Larkin wrote:

On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs
<bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/ >>>

One-time-pads are cheap and easy nowadays, and nothing can crack that.

I don't believe quantum computers will ever deliver. One-time-
pads aren't really a solution either. There are two problems:
How do you produce them and how do you deliver them?

A hardware-based random number generator, and memory sticks.

It's surprisingly difficult to produce cryptographic-quality
random numbers. It's easy for some undetected bias to creep
in, which gives a toehold to eavesdroppers.

The delivery problem is not how to store the OTP. It's rather
how you deliver it into the hands of the intended recipient
while making sure that only *he* gets it. It's not impossible,
embassies do it all the time. It's just a huge hassle, and
things do go wrong from time to time.

The beauty of public key encryption is that anyone can send you
an encrypted message that only you can decrypt. The public key
is the product of two very large primes and the algorithm is
such that that you need the individual primes, the private key,
to decode the message. The security of the algorithm relies on
the difficulty of finding those primes.

That keeps getting easier. If quantum computers ever really work, they
could crack public encryption instantly.

So we get told. Let's wait and see. For the moment, my belief is
that it's all hype. I think the usual talk of quantum bits being
in many states simultaneously is balderdash. I think the QM view
merely encodes the statistics of events if you perform many
measurements. Any single measurement just gives you a single
result. However, believing thus is a luxury unavailable to those
for whom reliable cryptography is essential.

As Don pointed out, the process of selecting a unique pair of huge
primes to create public and private keys is a weak spot of public
key encryption, more serious than the hypothetical menace of quantum
computers.

Jeroen Belleman

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 15 Dec 2023 12:33:27 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

On 12/15/2023 11:18 AM, Jeroen Belleman wrote:

I don't believe quantum computers will ever deliver. One-time-
pads aren't really a solution either. There are two problems:
How do you produce them and how do you deliver them?

OTPs need to be truly random to be effective. And, of a size
comparable to the size of the message being protected. The
randomness aspect precludes the use of any "set of bits" that
already exists "in the wild" (e.g., the text of "War and Peace")
as those things are likely available to adversaries AND not
truly random.

Use 20 zener diode noise sources, scramble each, and XOR. Or one
zener, but use it 100 times.

ALL users of a pad have to be kept in sync -- or, "told"
of the (nonoverlapping) offset into the pad that should be
used as the start for this message (which leaks information
as to the size of previous messages).

Knowing the size of the message is not very useful, and easily avoided
anyhow.

And, if you can SECURELY distribute a pad of size X, then
why not distribute your MESSAGE using the same SECURE
mechanism?

The pad can be physically transported by the recipient, months before
it's used. One unique pad pair per recipient, of course.

Also, keep in mind that for interactive *communications*
running at bus speeds, you can consume a huge pad in
milliseconds.

Terabytes? In milliseconds?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/15/2023 2:26 PM, Jeroen Belleman wrote:

It's surprisingly difficult to produce cryptographic-quality
random numbers. It's easy for some undetected bias to creep
in, which gives a toehold to eavesdroppers.

Exactly. Good sources of entropy are hard to come by.
Periodic noise from power supplies, patterns in external events,
etc. all have hidden (periodic) biases.

When I was doing gaming, it was not uncommon to use 2000 bit
PRNGs to get insanely long periods -- because you don't want to
use consecutive values that could help reveal the logic.
Proprietors aren't keen on players being able to exploit patterns
that "become known", over time.

[I had to fix one design that had an unintended bias in
the logic that could be exploited by a player to increase
his "return" above that expected by The House]

The other, insidious problem with randomness is that of
testing. If truly random, how do you REPEAT a particular
scenario?

The delivery problem is not how to store the OTP. It's rather
how you deliver it into the hands of the intended recipient
while making sure that only *he* gets it. It's not impossible,
embassies do it all the time. It's just a huge hassle, and
things do go wrong from time to time.

It also has to be *huge*. We're not living in the Napoleonic
Era where *a* message has to be conveyed to a trusted party.
Encrypted channels want to be exploited for all sorts of
uses -- like encrypting video feeds from drones, aircraft,
bodycams, etc. So, relying on OTPs for the final encryption
requires insane amounts of data.

I use encrypted tunnels between all of my system nodes, here.
To ensure an observer can't glean any information from the
"rate" of datagrams being transferred, I keep each link
saturated. So, there's 10MB (100BaseTX) of encrypted data
every second. In each direction. On each (up to ~300) link.
24/7/365.

2*10M*60sec*60min*24hr*300nodes=518TB per *day*.

The problem with encryption is that it is too appealing;
you don't bother thinking about what *needs* to be encrypted
(and, if you *did*, you would be tipping your hand as to
where the important data lies!)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On a sunny day (Fri, 15 Dec 2023 09:32:28 -0800) it happened John Larkin <jl@997PotHill.com> wrote in <ia3pnid1el7ao2d0oorq7ibuia8fo923v0@4ax.com>:

On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs ><bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment
could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/

One-time-pads are cheap and easy nowadays, and nothing can crack that.

Unless you use one multiple times.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/16/2023 1:26 AM, whit3rd wrote:

It's surprisingly difficult to produce cryptographic-quality
random numbers. It's easy for some undetected bias to creep
in, which gives a toehold to eavesdroppers.

Not really true; digital logic isn't noise-sensitive, but analog methods of making/capturing random noise are relatively trivial.

And susceptible to other "noise sources" that may be periodic
or consequential to the "data" generated.

They are also easily attacked (deliberately or not) and the randomness of
their data can degrade without the consumer of the data being aware of said degradation.

The "cryptographic-quality"
specifications are subject to creep, and are at relatively (IMHO) absurd heights relative to realistic scales (time-to-test of the order of the age of the universe).

Tabulations like Rand "One Million Random Digits..." are relatively easily available,
and the foreword in that volume explains the process.

But YOUR random number generator must be independant of all others
(else it isn't "random"). So, you now need to be expert in the
design, shielding, protection and validation of that device
as long as you rely on its output.

The right kind of generator isn't a digital computer but an amplifier
with gain, acting on thermal noise. A combination
of one-time use and good-enough randomness is not beatable.

And what if the environment changes (or *is* changed)? Should the
qualities of the "T"RNG change? If it does, then its performance
isn't "random" as it is thus influenced by the changed environment.

Or, the performance of the *analog* circuitry degrades, over time
(power supply fluctuations, component aging, etc.)?

Immutable, uncorruptible entropy sources are difficult to RELIABLY
harvest. Esp if there is value (to a competitor or adversary)
to corrupting the process.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mike Monett VE3BTI <spamme@not.com> wrote:

One bad character screwed the whole page. I removed the character and
reposted the text. Hope it works.

The right kind of generator isn't a digital computer but an amplifier
with gain, acting on thermal noise. A combination of one-time use and good-enough randomness is not beatable.

For most purposes, a code that takes a long time to break is good enough.
Any data will have become useless.

Gibson Research Corporation, by Steve Gibson, produces high quality code
that is often good enough.

Home Page
https://www.grc.com/default.htm

Gibson Ultra High Security Password Generator
https://www.grc.com/passwords.htm

Some results:

Generating long, high-quality random passwords is
not simple. So here is some totally random raw
material, generated just for YOU, to start with.

Every time this page is displayed, our server generates a unique set of
custom, high quality, cryptographic-strength password strings which are
safe for you to use:

64 random hexadecimal characters (0-9 and A-F): 487329B53FC390D647A9F733677113B4A8848205917DECB5A19E82759247D976

63 random printable ASCII characters: B\)ym&bweBC%i,/3i;,[4q%E!6%EH_N;zrurWANEA.!4O}>RxLy=pH9CXYl%Y&N

63 random alpha-numeric characters (a-z, A-Z, 0-9): BqgvA4M1Bw6JcJ8jeZqtaRNG6gKN2GGulTkhGOPG8NnAsfES79BiiTmuE19G9A7

Click your web browser's "refresh" button a few times and watch the
password strings change each time.

What makes these perfect and safe?

Every one is completely random (maximum entropy) without any pattern, and
the cryptographically-strong pseudo random number generator we use
guarantees that no similar strings will ever be produced again.

Also, because this page will only allow itself to be displayed over a snoop-proof and proxy-proof high-security SSL connection, and it is marked
as having expired back in 1999, this page which was custom generated just
now for you will not be cached or visible to anyone else.

Therefore, these password strings are just for you. No one else can ever
see them or get them. You may safely take these strings as they are, or use chunks from several to build your own if you prefer, or do whatever you
want with them. Each set displayed are totally, uniquely yours — forever.

The "Application Notes" section below discusses various aspects of using
these random passwords for locking down wireless WEP and WPA networks, for
use as VPN shared secrets, as well as for other purposes.

The "Techie Details" section at the end describes exactly how these super- strong maximum-entropy passwords are generated (to satisfy the uber-geek
inside you).

note about "random" and "pseudo-random" terminology:

Throughout this page I use the shorthand term "random" instead of the
longer but more precise term "pseudo-random". I use the output of this page myself for any purpose, without hesitation, any time I need a chunk of randomness because there is no better place to find anything more trusted, random and safe. The "pseudo-randomness" of these numbers does not make
them any less good.

There are ways to generate absolutely random numbers, but computer
algorithms cannot be used for that, since, by definition, no deterministic mathematical algorithm can generate a random result. Electrical and
mechanical noise found in chaotic physical systems can be tapped and used
as a source of true randomness, but this is much more than is needed for
our purposes here. High quality algorithms are sufficient.

The deterministic binary noise generated by my server, which is then
converted into various displayable formats, is derived from the highest
quality mathematical pseudo-random algorithms known. In other words, these password strings are as random as anything non-random can be.

[...]

The result of the combination of the 256-bit Rijndael/AES secret key, the unknowable (therefore secret) present value of the 128-bit monotonically incrementing counter, and the 128-bit secret Initialization Vector (IV) is 512-bits of secret data providing extremely high security for the
generation of this page's "perfect passwords". No one is going to figure
out what passwords you have just received.

How much security do 512 binary bits provide? Well, 2^512 (2 raised to the power of 512) is the total number of possible combinations of those 512
binary bits — every single bit of which actively participates in
determining this page's successive password sequence. 2^512 is
approximately equal to: 1.34078079 x 10^154, which is this rather amazing number:

13, 407, 807, 929, 942, 597, 099, 574, 024, 998, 205,
846, 127, 479, 365, 820, 592, 393, 377, 723, 561, 443,
721, 764, 030, 073, 546, 976, 801, 874, 298, 166, 903,
427, 690, 031, 858, 186, 486, 050, 853, 753, 882, 811,
946, 569, 946, 433, 649, 060, 084, 096

https://www.grc.com/passwords.htm

I checked his calculation and found one digit was incorrect. I wrote him
but didn't get a reply.

I put 32 digits of his alphanumeric generator in a password checker:

QO5Ad7TYwgbhV1PknVe45nVcz4UEePgp

Brute-force attack cracking time estimate:

Machine Time
Standard Desktop PC About 9 tredecillion years
Fast Desktop PC About 2 tredecillion years
GPU About 877 duodecillion years
Fast GPU About 438 duodecillion years
Parallel GPUs About 44 duodecillion years
Medium size botnet About 9 undecillion years

http://password-checker.online-domain-tools.com/

undecillion: a cardinal number represented in the U.S. by 1 followed by 36 zeros.

I don't know how you would crack it except by brute force. 9e36 years seems long enough, so I use his code in sensitive areas.




--
MRM

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

whit3rd <whit3rd@gmail.com> wrote:

It's surprisingly difficult to produce cryptographic-quality
random numbers. It's easy for some undetected bias to creep in, which
gives a toehold to eavesdroppers.

Not really true; digital logic isn't noise-sensitive, but analog methods
of making/capturing random noise are relatively trivial. The "cryptographic-quality" specifications are subject to creep, and are at relatively (IMHO) absurd heights relative to realistic scales
(time-to-test of the order of the age of the universe).

Tabulations like Rand "One Million Random Digits..." are relatively
easily available, and the foreword in that volume explains the process.

The right kind of generator isn't a digital computer but an amplifier
with gain, acting on thermal noise. A combination
of one-time use and good-enough randomness is not beatable.

For most purposes, a code that takes a long time to break is good enough.
Any data will have become useless.

Gibson Research Corporation, by Steve Gibson, produces high quality code
that is often good enough.

Home Page
https://www.grc.com/default.htm

Gibson Ultra High Security Password Generator
https://www.grc.com/passwords.htm

Some results:

Generating long, high-quality random passwords is
not simple. So here is some totally random raw
material, generated just for YOU, to start with.

Every time this page is displayed, our server generates a unique set of
custom, high quality, cryptographic-strength password strings which are
safe for you to use:

64 random hexadecimal characters (0-9 and A-F): 487329B53FC390D647A9F733677113B4A8848205917DECB5A19E82759247D976

63 random printable ASCII characters: B\)ym&bweBC%i,/3i;,[4q%E!6%EH_N;zrurWANEA.!4O}>RxLy=pH9CXYl%Y&N

63 random alpha-numeric characters (a-z, A-Z, 0-9): BqgvA4M1Bw6JcJ8jeZqtaRNG6gKN2GGulTkhGOPG8NnAsfES79BiiTmuE19G9A7

Click your web browser's "refresh" button a few times and watch the
password strings change each time.

What makes these perfect and safe?

Every one is completely random (maximum entropy) without any pattern, and
the cryptographically-strong pseudo random number generator we use
guarantees that no similar strings will ever be produced again.

Also, because this page will only allow itself to be displayed over a snoop-proof and proxy-proof high-security SSL connection, and it is marked
as having expired back in 1999, this page which was custom generated just
now for you will not be cached or visible to anyone else.

Therefore, these password strings are just for you. No one else can ever
see them or get them. You may safely take these strings as they are, or use chunks from several to build your own if you prefer, or do whatever you
want with them. Each set displayed are totally, uniquely yours — forever.

The "Application Notes" section below discusses various aspects of using
these random passwords for locking down wireless WEP and WPA networks, for
use as VPN shared secrets, as well as for other purposes.

The "Techie Details" section at the end describes exactly how these super- strong maximum-entropy passwords are generated (to satisfy the uber-geek
inside you).

note about "random" and "pseudo-random" terminology:

Throughout this page I use the shorthand term "random" instead of the
longer but more precise term "pseudo-random". I use the output of this page
— myself — for any purpose, without hesitation, any time I need a chunk of randomness because there is no better place to find anything more trusted, random and safe. The "pseudo-randomness" of these numbers does not make
them any less good.

There are ways to generate absolutely random numbers, but computer
algorithms cannot be used for that, since, by definition, no deterministic mathematical algorithm can generate a random result. Electrical and
mechanical noise found in chaotic physical systems can be tapped and used
as a source of true randomness, but this is much more than is needed for
our purposes here. High quality algorithms are sufficient.

The deterministic binary noise generated by my server, which is then
converted into various displayable formats, is derived from the highest
quality mathematical pseudo-random algorithms known. In other words, these password strings are as random as anything non-random can be.

[...]

The result of the combination of the 256-bit Rijndael/AES secret key, the unknowable (therefore secret) present value of the 128-bit monotonically incrementing counter, and the 128-bit secret Initialization Vector (IV) is 512-bits of secret data providing extremely high security for the
generation of this page's "perfect passwords". No one is going to figure
out what passwords you have just received.

How much security do 512 binary bits provide? Well, 2^512 (2 raised to the power of 512) is the total number of possible combinations of those 512
binary bits — every single bit of which actively participates in
determining this page's successive password sequence. 2^512 is
approximately equal to: 1.34078079 x 10^154, which is this rather amazing number:

13, 407, 807, 929, 942, 597, 099, 574, 024, 998, 205,
846, 127, 479, 365, 820, 592, 393, 377, 723, 561, 443,
721, 764, 030, 073, 546, 976, 801, 874, 298, 166, 903,
427, 690, 031, 858, 186, 486, 050, 853, 753, 882, 811,
946, 569, 946, 433, 649, 060, 084, 096

https://www.grc.com/passwords.htm

I checked his calculation and found one digit was incorrect. I wrote him
but didn't get a reply.

I put 32 digits of his alphanumeric generator in a password checker:

QO5Ad7TYwgbhV1PknVe45nVcz4UEePgp

Brute-force attack cracking time estimate:

Machine Time
Standard Desktop PC About 9 tredecillion years
Fast Desktop PC About 2 tredecillion years
GPU About 877 duodecillion years
Fast GPU About 438 duodecillion years
Parallel GPUs About 44 duodecillion years
Medium size botnet About 9 undecillion years

http://password-checker.online-domain-tools.com/

undecillion: a cardinal number represented in the U.S. by 1 followed by 36 zeros.

I don't know how you would crack it except by brute force. 9e36 years seems long enough, so I use his code in sensitive areas.





--
MRM

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On a sunny day (Sat, 16 Dec 2023 10:35:48 -0000 (UTC)) it happened Mike Monett VE3BTI <spamme@not.com> wrote in <XnsB0DC38DA1E73Didtokenpost@135.181.20.170>:

Mike Monett VE3BTI <spamme@not.com> wrote:

One bad character screwed the whole page. I removed the character and >reposted the text. Hope it works.

The right kind of generator isn't a digital computer but an amplifier
with gain, acting on thermal noise. A combination of one-time use and
good-enough randomness is not beatable.

For most purposes, a code that takes a long time to break is good enough.
Any data will have become useless.

Gibson Research Corporation, by Steve Gibson, produces high quality code
that is often good enough.

Home Page
https://www.grc.com/default.htm

Gibson Ultra High Security Password Generator >https://www.grc.com/passwords.htm

Some results:

Generating long, high-quality random passwords is
not simple. So here is some totally random raw
material, generated just for YOU, to start with.

Must be a joke to download the passwords or so called random code from a website!
I hope you see why?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Dec 2023 06:12:55 GMT, Jan Panteltje <alien@comet.invalid>
wrote:

On a sunny day (Fri, 15 Dec 2023 09:32:28 -0800) it happened John Larkin ><jl@997PotHill.com> wrote in <ia3pnid1el7ao2d0oorq7ibuia8fo923v0@4ax.com>:

On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs >><bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment
could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/ >>

One-time-pads are cheap and easy nowadays, and nothing can crack that.

Unless you use one multiple times.

Don't do that!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 16 Dec 2023 11:03:53 -0800, John Larkin <jl@997PotHill.com>
wrote:

On Sat, 16 Dec 2023 06:12:55 GMT, Jan Panteltje <alien@comet.invalid>
wrote:

On a sunny day (Fri, 15 Dec 2023 09:32:28 -0800) it happened John Larkin >><jl@997PotHill.com> wrote in <ia3pnid1el7ao2d0oorq7ibuia8fo923v0@4ax.com>:

On Fri, 15 Dec 2023 08:50:42 -0800 (PST), Fred Bloggs >>><bloggs.fredbloggs.fred@gmail.com> wrote:

'The encryption guarding digital communications could someday be cracked by quantum computers. Dubbed 'Q-day,' that moment
could upend military and economic security worldwide. Great powers are sprinting to get there first.'

They still have to contend with the 'harvest now, decrypt later' which has been ongoing for a while I'm sure.

https://www.reuters.com/investigates/special-report/us-china-tech-quantum/ >>>

One-time-pads are cheap and easy nowadays, and nothing can crack that.

Unless you use one multiple times.

Don't do that!

.<https://en.wikipedia.org/wiki/Venona_project>

Joe Gwinn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)