xkcd: Garbage Math

[Lynn McGuire]

xkcd: Garbage Math
https://xkcd.com/2295/

Ah, a subject that I am very well acquainted with. Garbage in, Garbage
out is a very well known concept in computer programming. And I've seen
a lot of garbage over the years.

And I don't even believe in the concept of garbage times zero equals a
real number (zero). Rarely is this good in my experience.

Explained at:
https://www.explainxkcd.com/wiki/index.php/2295:_Garbage_Math

Lynn

[Peter Trei]

I think this links to the previous strip.

pt

[mcdow...@sky.com]

Just to point out the universal applicability of the slogan "No Surrender!" I offer some more encouraging examples, starting off with the unassisted extraction of information from a system specifically designed not to divulge it:

The cryptanalysis of Tunny (https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Lorenz_cipher)

The monitoring of Coronavirus infection from the concentration of virus found in waste water.

The recovery of phylogenetic trees from present-day DNA

Very Long Baseline Interferometry such as https://en.wikipedia.org/wiki/Event_Horizon_Telescope

The ultimate "S**t data" - Brixmis digging up and retrieving radio callsign documents which had been used by Eastern block troops as toilet paper (which they were apparently not issued) - a web search finds https://en.wikipedia.org/wiki/Operation_Tamarisk - a short description well worth the time taken to click through to it.

[Peter Trei]

On Sunday, April 19, 2020 at 4:11:32 AM UTC-4, mcdow...@sky.com wrote:
> On Saturday, April 18, 2020 at 9:49:35 PM UTC+1, Lynn McGuire wrote:
> > xkcd: Garbage Math
> > https://xkcd.com/2295/
> >
> > Ah, a subject that I am very well acquainted with. Garbage in, Garbage
> > out is a very well known concept in computer programming. And I've seen
> > a lot of garbage over the years.
> >
> > And I don't even believe in the concept of garbage times zero equals a
> > real number (zero). Rarely is this good in my experience.
> >
> > Explained at:
> > https://www.explainxkcd.com/wiki/index.php/2295:_Garbage_Math
> >
> > Lynn
>
> Just to point out the universal applicability of the slogan "No Surrender!" I offer some more encouraging examples, starting off with the unassisted extraction of information from a system specifically designed not to divulge it:
>
> The cryptanalysis of Tunny (https://en.wikipedia.org/wiki/Cryptanalysis_of_the_Lorenz_cipher)

One of the foundational maxims of Communications Security is:

"Never underestimate the attention, risk, money and time that an opponent will put into reading traffic."

I myself a while back orchestrated the recruitment of nearly 100,000 PCs to demonstrate that
64 bit keys could be attacked by brute force.

Pt

[Paul S Person]

On Sat, 18 Apr 2020 15:49:14 -0500, Lynn McGuire
<lynnmc...@gmail.com> wrote:

>xkcd: Garbage Math
> https://xkcd.com/2295/
>
>Ah, a subject that I am very well acquainted with. Garbage in, Garbage
>out is a very well known concept in computer programming. And I've seen
>a lot of garbage over the years.

That's the optimistic version.

The realistic version is:
Anything in, garbage out.

>And I don't even believe in the concept of garbage times zero equals a
>real number (zero). Rarely is this good in my experience.
>
>Explained at:
> https://www.explainxkcd.com/wiki/index.php/2295:_Garbage_Math
>
>Lynn

--
"I begin to envy Petronius."
"I have envied him long since."

[Lynn McGuire]

I now use XX,XXX bit keys in my encoded transfers. My opponents have
given up trying to decrypt them. Instead, they now attack my software
and try replace the decryption code with their own. It is amazing the
level of effort that they will go to.

Lynn

[ozm...@gmail.com]

...heh,heh....

The quasi--central limit theorem one is one I have found useful in life.

e.g......take 50 horrid singers and a decent director, and you can get a pretty lovely choir.

It relates about now, as we thin our seedlings.

[Peter Trei]

How about 3746 singers, over the net?

https://www.youtube.com/watch?v=V3rRaL-Czxw

Pt

[ozm...@gmail.com]

.....illustrative.....

[Peter Trei]

I'm going to assume you're talking about the asymmetric keys. For symmetric keys (the
kind I was attacking) key sizes in the low hundreds are still safe.

Pt

[Lynn McGuire]

I would not assume anything.

Lynn

[Thomas Koenig]

On 2020-04-19, Lynn McGuire <lynnmc...@gmail.com> wrote:

> I now use XX,XXX bit keys in my encoded transfers. My opponents have
> given up trying to decrypt them. Instead, they now attack my software
> and try replace the decryption code with their own. It is amazing the
> level of effort that they will go to.

I encrypt every file on my computer with 128 rounds of ROT13.

[Gary R. Schmidt]

That reminds me - I was amused to learn, back in the day when it was all
new and wonderful (hah!), that communications were considered to be
"secure" under the Sarbanes-Oxley Act if the characters are sent ROT-13.

It didn't half frighten the puir wee auditor when I translated the stuff
on the fly... :->

Cheers,
Gary B-)

--
Waiting for a new signature to suggest itself...

[Axel Reichert]

Thomas Koenig <tko...@netcologne.de> writes:

> I encrypt every file on my computer with 128 rounds of ROT13.

That should be considered risky behavior. You will be better off
after doubling the strength of encryption by using 256 rounds of
ROT13. Paranoid people will increase this to 1024.

Best regards

Axel
--
-X- | in memoriam John Conway
--X | 1937-2020
XXX | A glider from his "Game of Life"

[Thomas Koenig]

Axel Reichert <ma...@axel-reichert.de> schrieb:

> Thomas Koenig <tko...@netcologne.de> writes:
>
>> I encrypt every file on my computer with 128 rounds of ROT13.
>
> That should be considered risky behavior. You will be better off
> after doubling the strength of encryption by using 256 rounds of
> ROT13. Paranoid people will increase this to 1024.

Are you sure?

I've read somewhere that 1024 round ROT13 is vulnerable to a plaintext
attack.

[Scott Lurndal]

Including that you know anything about encryption?

[Paul S Person]

I would assume that NSA can break any encryption system. Period.

And I would consider anyone who disagrees "insufficiently paranoid".

And also overworked: if you accept the assumption, there is no point
in trying to find an unbreakable code, because there aren't any.

Well, none that do encryption/decryption using a computer hooked up to
the Internet, anyway.

[Scott Lurndal]

Paul S Person <pspe...@ix.netcom.invalid> writes:
>On Mon, 20 Apr 2020 02:43:35 -0500, Lynn McGuire
><lynnmc...@gmail.com> wrote:
>
>
>>> I'm going to assume you're talking about the asymmetric keys. For symmetric keys (the
>>> kind I was attacking) key sizes in the low hundreds are still safe.
>>>
>>> Pt
>>
>>I would not assume anything.
>
>I would assume that NSA can break any encryption system. Period.

Consider OTP, then restate your assumption.

[Lynn McGuire]

I've been proven incompetent about encryption many times by Chinese and
Russian crackers.

I've sold one copy of my software in China. I have over a thousand
users there.

Lynn

[Lynn McGuire]

OTP = One True Pairing ???

Lynn

[Lynn McGuire]

On 4/20/2020 12:56 PM, Scott Lurndal wrote:

OTP = On The Phone ???

Lynn

[Ted Nolan <tednolan>]

In article <r7l2kp$gdt$2...@dont-email.me>,

Most likely OneTimePassword
--
columbiaclosings.com
What's not in Columbia anymore..

[Joe Pfeiffer]

Given context my money is on One Time Pad.

[Jaimie Vandenbergh]

On 20 Apr 2020 at 22:38:51 BST, "Ted Nolan <tednolan>" <Ted Nolan <tednolan>>
wrote:

One Time Pad. The pad holds the encryption key which is the same length as the
message (or longer). Each user has a copy. The messages is cryptographically
safe as long as no-one else has the pad and the message. There is no way to
brute force an attack on the encoded message.

Cheers - Jaimie
--
Tetris has taught me that accomplishments disappear and mistakes pile up.

[Mark Jackson]

One Time Pad, surely?

--
Mark Jackson - http://www.alumni.caltech.edu/~mjackson
Why have citizens when you can have customers?
- Sebastien Hayakawa (Aaron Diaz)

[Scott Lurndal]

Mark Jackson <mjac...@alumni.caltech.edu> writes:
>On 4/20/2020 4:38 PM, Lynn McGuire wrote:
>> On 4/20/2020 12:56 PM, Scott Lurndal wrote:
>>> Paul S Person <pspe...@ix.netcom.invalid> writes:
>>>> On Mon, 20 Apr 2020 02:43:35 -0500, Lynn McGuire
>>>> <lynnmc...@gmail.com> wrote:
>>>>
>>>>
>>>>>> I'm going to assume you're talking about the asymmetric keys. For
>>>>>> symmetric keys (the
>>>>>> kind I was attacking) key sizes in the low hundreds are still safe.
>>>>>>
>>>>>> Pt
>>>>>
>>>>> I would not assume anything.
>>>>
>>>> I would assume that NSA can break any encryption system. Period.
>>>
>>> Consider OTP, then restate your assumption.
>>
>> OTP = One True Pairing ???
>
>One Time Pad, surely?
>

I'm getting the impression that Lynn doesn't know how to use google.

(OTP crypto), first hit.

[Lynn McGuire]

On 4/20/2020 5:09 PM, Mark Jackson wrote:
> On 4/20/2020 4:38 PM, Lynn McGuire wrote:
>> On 4/20/2020 12:56 PM, Scott Lurndal wrote:
>>> Paul S Person <pspe...@ix.netcom.invalid> writes:
>>>> On Mon, 20 Apr 2020 02:43:35 -0500, Lynn McGuire
>>>> <lynnmc...@gmail.com> wrote:
>>>>
>>>>
>>>>>> I'm going to assume you're talking about the asymmetric keys. For
>>>>>> symmetric keys (the
>>>>>> kind I was attacking) key sizes in the low hundreds are still safe.
>>>>>>
>>>>>> Pt
>>>>>
>>>>> I would not assume anything.
>>>>
>>>> I would assume that NSA can break any encryption system. Period.
>>>
>>> Consider OTP, then restate your assumption.
>>
>> OTP = One True Pairing ???
>
> One Time Pad, surely?

Thanks !

Lynn

[Lynn McGuire]

A courteous person would not use acronyms for uncommon or industry
specific phrases.

Lynn

[hamis...@gmail.com]

This is why it's a bad idea to make up your own encryption
It's a tough area and you're much better off getting a proven implementation from elsewhere and using it.

[J. Clarke]

On Mon, 20 Apr 2020 20:06:54 -0500, Lynn McGuire

<lynnmc...@gmail.com> wrote:

>On 4/20/2020 5:29 PM, Scott Lurndal wrote:
>> Mark Jackson <mjac...@alumni.caltech.edu> writes:
>>> On 4/20/2020 4:38 PM, Lynn McGuire wrote:
>>>> On 4/20/2020 12:56 PM, Scott Lurndal wrote:
>>>>> Paul S Person <pspe...@ix.netcom.invalid> writes:
>>>>>> On Mon, 20 Apr 2020 02:43:35 -0500, Lynn McGuire
>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>>> I'm going to assume you're talking about the asymmetric keys. For
>>>>>>>> symmetric keys (the
>>>>>>>> kind I was attacking) key sizes in the low hundreds are still safe.
>>>>>>>>
>>>>>>>> Pt
>>>>>>>
>>>>>>> I would not assume anything.
>>>>>>
>>>>>> I would assume that NSA can break any encryption system. Period.
>>>>>
>>>>> Consider OTP, then restate your assumption.
>>>>
>>>> OTP = One True Pairing ???
>>>
>>> One Time Pad, surely?
>>>
>>
>> I'm getting the impression that Lynn doesn't know how to use google.
>>
>> (OTP crypto), first hit.
>
>A courteous person would not use acronyms for uncommon or industry
>specific phrases.

"One time pad" is hardly obscure. There was one Hugo winner in which
a one time pad plade a major role.
>
>Lynn
>

[Sjouke Burry]

Besides, you know there will be a backdoor from some governments.

[David Goldfarb]

In article <hg6kmr...@mid.individual.net>,

Jaimie Vandenbergh <jai...@usually.sessile.org> wrote:
>One Time Pad. The pad holds the encryption key which is the same length as the
>message (or longer). Each user has a copy. The messages is cryptographically
>safe as long as no-one else has the pad and the message. There is no way to
>brute force an attack on the encoded message.

A variation on this that I've seen used in Kim Stanley Robinson's novel
_Red Moon_ (and mentioned in one or two other places) is to use a store
of quantum-entangled photons to generate your OTP on the fly. I'm unclear
on how you tell just _which_ photon to use next, but I guess that's
an engineering detail.

--
David Goldfarb |From the fortune cookie file:
goldf...@gmail.com |
gold...@ocf.berkeley.edu |"You have at your command the wisdom of the ages."

[Torbjorn Lindgren]

David Goldfarb <goldf...@gmail.com> wrote:
>In article <hg6kmr...@mid.individual.net>,
>Jaimie Vandenbergh <jai...@usually.sessile.org> wrote:
>>One Time Pad. The pad holds the encryption key which is the same
>>length as the message (or longer). Each user has a copy. The
>>messages is cryptographically safe as long as no-one else has the
>>pad and the message. There is no way to brute force an attack on the
>>encoded message.
>
>A variation on this that I've seen used in Kim Stanley Robinson's novel
>_Red Moon_ (and mentioned in one or two other places) is to use a store
>of quantum-entangled photons to generate your OTP on the fly. I'm unclear
>on how you tell just _which_ photon to use next, but I guess that's
>an engineering detail.

It's known as Quantum Key Distribution (QKD)[1] and how it's used
depends on things like "does sending data destroy the entanglement or
not" and what bandwidth it can provide. And how secure and tamperproof
it is.

There are commercial low-bandwidth QKD systems in operation now and
the Chinese has demonstrated QKD link to Europe via the Tiangong-2
space station - easier to test experimental hardware there than having
to send up a satellite though AFAIK that is planned for later.

AFAIK these QKD systems aren't very high bitrate so they're unlikely
to be "wasted" on transmitting One Time Pads, a much more sensible use
is to send 256-bit+ keys for symmetrical keys[2].

1. https://en.wikipedia.org/wiki/Quantum_key_distribution
2. https://en.wikipedia.org/wiki/Post-quantum_cryptography#Symmetric_key_quantum_resistance

[Ross Presser]

A One Time Pad cannot be broken (if the pad is unknown) because there is
absolutely no corellation between the plaintext and cryptext. This immunity
has been mathematically proven. Making statements about encryption when
you do not know this fact is like a swarm of honeybees claiming they can
write good science fiction.

[Jaimie Vandenbergh]

Xref the webcomic Skin Horse, which has a swarm of honeybees that runs a
government agency. It's by the creator of Narbonic, for the older-school
webcomic readers.

Cheers - Jaimie
--
It's all fun and games until someone loses an eye. Then it's a scavenger
hunt.

[Paul S Person]

And what else would you expect from Commie and neo-Commie societies,
rife as they are with second-handers?

[Paul S Person]

On Mon, 20 Apr 2020 17:56:46 GMT, sc...@slp53.sl.home (Scott Lurndal)
wrote:

My intended reference was to encryption commonly used on computer
systems which do /not/ involve mailing keys to users.

Your correction, however, is appreciated.

[Paul S Person]

On 20 Apr 2020 22:06:19 GMT, Jaimie Vandenbergh

Which generally satisfies my /other/ condition, that
encryption/decryption not be done on a computer connected to the
internet.

You are thinking "well, of course it is!", but here is the problem:

if the key is stored on a computer which is attached to the internet,
then it's security depends on the security of the computer

and we all know that there are any number of ways for /that/ to be
compromised. Whereupon they don't have to use heavy-duty analysis to
get the key; they just grab it and run.

You could, of course, do it on a computer /not/ connected to the
internet. The problem then is, how do you safely transfer it to a
computer that is so that it can be sent onwards? And the response back
again so it can be decrypted?

BTW, I was actually thinking of a book code as an exception. No need
to get the one-time-pads out to the users with a book code.

[Lynn McGuire]

I've even had the foreign crackers email me as they cracked our old
encryption. A prof in Russia used it for course material back in the
Win16 days.

Now the guys in San Francisco, I alerted the FBI who arrested them and
put them in jail for ten+ years. I also sued a couple of companies in
California who were using their cracked versions and received a couple
of nice settlements.

Lynn

[Lynn McGuire]

Hmmm. Did I state that I was an expert on encryption ?

I view myself as a Jack of all trades and the master of none.

Lynn

[Scott Lurndal]

No, Ross conflated you with Paul Person, whose statement about
the NSA breaking any encryption was clipped by someone along the line.

[Robert Carnegie]

This does depend on generating a truly random One Time Pad.
This may be, usually is, impractical to do in large volume.
(People do things with a Geiger counter, or lava lamps...)

If you want a lot of "random" numbers, they're probably going
to be generated in a computer using a mathematical formula
which may even be known. What should be not known is a
random starting point for the formula. In other words, roughly,
there's a (not really) infinite sequence of "random" numbers that
the formula generates, and you use a starting point in that
sequence that is randomly selected, and either that information,
or the "random" numbers that emerge, are shared in advance with
the receiver - so the "random" values that you use as a OTP
"should" be unknown and remain unknown even when a third party
is receiving your encrypted messages.

Should.

[Ross Presser]

I apologize. It's hard to keep track of multi-quotes in Google Groups, and
I gave up on a real newsfeed years ago.

[Ross Presser]

I am acquainted with the theory of cryptographically secure PRNGs (though
I would not claim to be an expert by any means).

Two sites that can provide (or at least claim to provide) free "true"
randomness:
https://random.org
https://www.fourmilab.ch/hotbits/

Of course, accumulating enough random bits from these to make a useful
OTP is difficult; in the end, you're probably going to use a CPRNG seeded
from true randomness.

[Scott Lurndal]

Most modern processors have started to include true random number
generators, usually accessed via a non-privileged instruction, e.g.:

https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide

[Scott Lurndal]

The above reference has an excellent description of the differences
between PRNGS and TRNGs.

[Paul S Person]

On Tue, 21 Apr 2020 12:44:04 -0500, Lynn McGuire

Good for you!

Over here we /respect/ property rights.

[Paul S Person]

I suspect that you are the victim of mis-attribution. Depending on who
you are responding to.

And, if the pad is loaded into a computer which is connected to the
internet, it can be /stolen/. This is why we are warned about opening
attachments and phishing, among other things.

You don't have to break a key to read an encrypted message. It may not
be as satisfying -- it may even feel like cheating -- but you can, in
some cases, /steal/ the key instead.

[Paul S Person]

It's no picnic trying to straighten out one in Agent even after you
finally find the one post that has what you need in complete detail.

I know -- I've done it. Once.

[Peter Trei]

Those are fine for toy applications were security doesn't actually matter.

If you actually care, you spend the money to make your own pads. The assumption is that
every output from those sites is recorded, and those who want to listen will just try all the
outputs.

...and you don't transmit a pad via email or snail mail. It's carried by a courier, known to you.

Pt

[Peter Trei]

More to the point, if you decrypt on an Internet connected computer an attacker can just read the plaintext. When you're serious about things you move the message with a USB to a dedicated machine that's always off-line to decrypt and read.

Pt

[Lynn McGuire]

Requiring going offline is not practical with commercial software.

We have been thinking about not allowing our software to run until a
successful decryption of the password is performed and then download a
crucial part, such as a Win32 DLL. We are already a 140+ MB download
that expands to 300 MB so another small DLL would not be a significant
burden. But getting through some of our customers firewalls is tricky,
especially at the refineries.

Lynn

[Quadibloc]

On Monday, April 20, 2020 at 10:28:11 AM UTC-6, Paul S Person wrote:

> I would assume that NSA can break any encryption system. Period.

> And I would consider anyone who disagrees "insufficiently paranoid".

There are lots of encryption systems even the NSA can't break.

However, because of that, they've moved on to finding other ways to do their
jobs - that's why they've been hacking computers and putting backdoors into
encryption systems.

Expecting the NSA to be able to decrypt text enciphered in, say, AES with a long
key through a ciphertext-only attack... is unrealistic. The bad news, of course,
is that because the NSA knows this, it has, with a great deal of success, found
other ways around the problem.

As with the NSA, so, to an even greater extent, with hackers - so once you've
decided on a reasonable encryption algorithm, what you really need to concern
yourself with is overall system security. Using a super-duper encryption
algorithm won't help you if one phishing E-mail can lead to all your plaintexts
being sent to the hacker.

John Savard

[Quadibloc]

On Monday, April 20, 2020 at 4:09:53 PM UTC-6, Mark Jackson wrote:

> One Time Pad, surely?

Of course, but then somebody's going to bring up VENONA. However, numbers typed by
people told to type random digits on a typewriter aren't genuinely random, and
one-time pads used twice aren't (one-time pads).

John Savard

[Quadibloc]

On Tuesday, April 21, 2020 at 10:03:41 AM UTC-6, Ross Presser wrote:

> A One Time Pad cannot be broken (if the pad is unknown) because there is
> absolutely no corellation between the plaintext and cryptext. This immunity
> has been mathematically proven.

But there _is_ the bit-flipping attack. Which can be blocked by using a *second*
one-time pad; use the first one to add, and the second one to multiply.

Then, even if you have a known plaintext, not knowing the key, you will be
unable to alter the ciphertext to represent another plaintext.

John Savard

[Quadibloc]

On Wednesday, April 22, 2020 at 12:20:22 PM UTC-6, Peter Trei wrote:

> ...and you don't transmit a pad via email or snail mail. It's carried by a
> courier, known to you.

While other forms of encryption are inferior to the one-time-pad, as they can
all be broken in theory, even in that case, one ought to only send out the one-
time-pad in an encrypted form, so that the courier will have nothing worth
betraying.

Despte the fact that mathematicians might someday discover an easy way to factor
the products of large primes and/or a solution to the discrete logarithm problem
(and then there are elliptic curves and lattice-based public-key systems), thus
making the "magic screw" objection not without validity...

ensuring that a courier has nothing worthwhile to betray is still useful, as
John Walker proved.

John Savard

[Robert Carnegie]

Enthusiasm persists amongst spooky TLAs worldwide for legislation
that requires encryption products to include "back door" access
so that the spooks can read all the messages. Resistance to this,
worldwide, varies. Or so the "The Register" news website tells
me, as developments occur.

[Robert Carnegie]

But the random data that you download from there
comes encryp...... oh. ;-)

[Quadibloc]

On Wednesday, April 22, 2020 at 2:18:56 PM UTC-6, Lynn McGuire wrote:

> We have been thinking about not allowing our software to run until a
> successful decryption of the password is performed and then download a
> crucial part, such as a Win32 DLL. We are already a 140+ MB download
> that expands to 300 MB so another small DLL would not be a significant
> burden. But getting through some of our customers firewalls is tricky,
> especially at the refineries.

While making E-mail sent to people - if the threat model is that the hackers can
only read the E-mails, and can't hack either your or the recipient's computer -
secure is trivial, protecting software isn't, because here the hackers have
access.

The best practice I can suggest is:

Ship the software in an encrypted form, without including the decryption key
anywhere with the product.

If you do that, how does the customer get to use the software?

Well, it comes with an installer. The installer randomly generates a serial
number, the customer phones in and gets an activation key.

The trick is that the "activation key", in addition to telling the installer
(which the hackers, of course, will have disassembled, so they know exactly what
it does) "yes", this is the right activation key, would also contain the key for
decrypting the software.

But all this achieves is forcing the hackers to purchase _one_ copy of your
software before they can crack it. With encryption as the only tool available,
you can't really do better than that.

Now, if you had a way to avoid giving out activation keys except to legitimate
customers not _in_ Russia or China, though, it could be enough.

John Savard

[Robert Carnegie]

Presuming that your USB device is (a) what it appears to be
and (b) secure. Some of them can even be reprogrammed with
nasty firmware. Attacking the operation that you describe
is something I'm going to leave to the spooks to work out.

[Lynn McGuire]

They will share the decryption key. Been there, done that.

Lynn

[Peter Trei]

It doesn't work that way. What are you going to encrypt the OTP with, and how
does *that* key get to the recipient, and how strong is it?

If you're really worried, send two or more pads, by separate couriers,
traveling separately, and XOR them all together to get the pad you use for
encryption. An adversary would have to get all of them.

pt

[Peter Trei]

That's true. There's lots of ways to get something across an air gap.
A DVD, for example.

[Peter Trei]

IP protection isn't my area, but could you put some critical, but low-data, proprietary function of your product on a server under your control, and
require all installations to call out to your server for that function?

pt

[Torbjorn Lindgren]

Robert Carnegie <rja.ca...@excite.com> wrote:
>This does depend on generating a truly random One Time Pad.
>This may be, usually is, impractical to do in large volume.
>(People do things with a Geiger counter, or lava lamps...)
>
>If you want a lot of "random" numbers, they're probably going
>to be generated in a computer using a mathematical formula
>which may even be known. What should be not known is a
>random starting point for the formula. In other words, roughly,
>there's a (not really) infinite sequence of "random" numbers that

Most (all?) modern CPUs have special intructions that produce random
numbers that are seeded using TRUE random data (a couple of different
methods have been used, quantum shot noise is one example), including
regular automatic reseeding (again using true random data).

Intel added their RDRAND instruction with Sandy Bridge in 2012 for
example and most other CPUs got something similar sometime in the
2012-2016 time span. So there's still quite a number of machines out
there that won't have this.

Also, not everyone trust Intel/AMD/ARM/... to do this correctly (or
not include a "NSA override" toggle that would make it look fine but
not be random after it has been set)...

These sources don't generate true random data fast enough to use as
the sole source of data (partly because they occupy a miniscule part
of the chip) which is why they're used the way I described above to
get around that.

As you mention the same thing has been done using various external
sources of randomness that are too big to put into a CPU like lava
lamps, dices and geiger counters (they're all very low bit-rate too).

In all these cases a lot of processing is needed to make sure the data
is truly random (another reason why it's slow, many measurements is
often needed to generate enough entropy for it to be fully random).

>the formula generates, and you use a starting point in that
>sequence that is randomly selected, and either that information,
>or the "random" numbers that emerge, are shared in advance with
>the receiver - so the "random" values that you use as a OTP
>"should" be unknown and remain unknown even when a third party
>is receiving your encrypted messages.

There's dedicated hardware random sources (since at least 2001) using
similar methods if you need much higher bitrates of true random data
than the CPUs or sources discussed earlier provides.

I suspect it's possible to find something that can generate large
"true random" OTP's quickly if you so desire and have a substantial
budget (IE not country should have issues with that part).

[Lynn McGuire]

See answer above. "But getting through some of our customers firewalls

is tricky, especially at the refineries."

Lynn

[J. Clarke]

You could do it the "modern" way and change over to a cloud-based
model.

[Peter Trei]

Same problem. A competent operation restricts access to their internal networks, and access out from them. Doing so is literally my job at the moment.

Pt

Pt

[Paul S Person]

If course, if the machine that /is/ connected is infected, the USB
might be compromised. And so on.

Is anyone out there beginning to understand what I mean when I say
that a /sufficiently/ paranoid person, figuring that NSA can break any
security in existence [if done by/on computers, as opposed to
manually-encrypted/decrypted OTP or book code systems], would simply
not even worry about it.

He would, of course, continue to favor secure websites, but that
security is intended to deter thieves, not governments.

[Paul S Person]

On Wed, 22 Apr 2020 14:33:08 -0700 (PDT), Quadibloc
<jsa...@ecn.ab.ca> wrote:

>On Wednesday, April 22, 2020 at 2:18:56 PM UTC-6, Lynn McGuire wrote:
>
>> We have been thinking about not allowing our software to run until a
>> successful decryption of the password is performed and then download a
>> crucial part, such as a Win32 DLL. We are already a 140+ MB download
>> that expands to 300 MB so another small DLL would not be a significant
>> burden. But getting through some of our customers firewalls is tricky,
>> especially at the refineries.
>
>While making E-mail sent to people - if the threat model is that the hackers can
>only read the E-mails, and can't hack either your or the recipient's computer -
>secure is trivial, protecting software isn't, because here the hackers have
>access.
>
>The best practice I can suggest is:
>
>Ship the software in an encrypted form, without including the decryption key
>anywhere with the product.
>
>If you do that, how does the customer get to use the software?
>
>Well, it comes with an installer. The installer randomly generates a serial
>number, the customer phones in and gets an activation key.

If the serial number is random, how can your server tell it isn't
dealing with an unlicensed copy, which will have it's /own/ random
serial number?

>The trick is that the "activation key", in addition to telling the installer
>(which the hackers, of course, will have disassembled, so they know exactly what
>it does) "yes", this is the right activation key, would also contain the key for
>decrypting the software.

And when the software needs to be reinstalled because of a glitch that
wiped the hard drive, will this still work?

>But all this achieves is forcing the hackers to purchase _one_ copy of your
>software before they can crack it. With encryption as the only tool available,
>you can't really do better than that.
>
>Now, if you had a way to avoid giving out activation keys except to legitimate
>customers not _in_ Russia or China, though, it could be enough.

You /could/ go back to some of the early computer games' practices.

OK, actually burning a hole in the media and writing the software to
not work unless it is there is not really practical any more.

But including a special booklet of unphotocopyiable material and
requiring the user to find a bit of it, read it with the one set of
special colored glasses included that makes the text readable and type
in what he finds there might still work. You might not need to mail it
/if/ you can provide an image that, even when printed, works the same
way. I'm thinking here that a binary image file is rather hard to read
text encoded in binary in the image which is needed to run the program
from, although I could be wrong about that.

Be irritating as hell for legitimate users, though.

[Paul S Person]

I suspect that, in the long run, "Resistance Is Futile".

And this illustrates what insufficient paranoia produces: a lot of
worry, a lot of angst, a lot of anger, and a lot of wasted effort.

IMHO, of course. Some may not call it wasted.

[Lynn McGuire]

1.3 million lines of F77 and C++ code with over 50 years of software
development. 150+ dialogs. Nope. Unless it was just a plain old
Windows host where you run Win32 in a browser.

Lynn

[J. Clarke]

On Thu, 23 Apr 2020 14:29:05 -0500, Lynn McGuire

Or 2 or 10 or a million. That's the thing about the cloud--you've got
as much computing power as you're willing to pay for.
>
>Lynn

[hamis...@gmail.com]

If the cloud host will provide the environment you're running it on

I'm pretty confident that this is an application not a web application and running an application on the cloud is dubious

Converting an application to a web application is painful and whether his clients would be willing to move across is open to question

[synthi...@yahoo.com]

I used one-time paper tape with my teletype in my old spy days. I was told it was good, but not absolute because in theory small imperfections in the psuedo-randomizer could turn up with very heavy analysis. I probably remembered this when I came up with my one clever programming trip for good rando seed numbers.

I'm sure I've mentioned before how the chi-com would reassemble documents that had gone through a common shredder. Now we have fluffers.

And thanks so much for the cold war spy program notes. I was doing mostly legal clean things. Shows what happens when the evil bad guy doesn't treat his flunkies well enough to give them toilet paper.

At then end of wwII the sides exchanged Military Liason Missions to smooth over problems between commies and the west. I had some tiny bit of work involving that. Soviet Military Liason Mission; "SmellM". United States Military Liason Mission; "You SMSmellM".

Nils