Hello!

Various governments around the world - including the US and EU - want
to have backdoors in encryption technology.

Is there anything known how FOSS developers will deal with that?

Especially if they are enforced to implement backdoors.


--
kind regards
Marco

Spam und Werbung bitte an
1713948269ichwillgesperrtwerden@nirvana.admins.ws

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

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 4/24/2024 1:47 AM, Marco Moock wrote:

Hello!

Various governments around the world - including the US and EU - want
to have backdoors in encryption technology.

Is there anything known how FOSS developers will deal with that?

Especially if they are enforced to implement backdoors.

Is there a backdoor to HMAC?

To the "algorithm" -- likely no.

In a given implementation of said algorithm in some library code -- now that
is possible. How likely is unknown. Just note the "xz" backdoor that
made the rounds a few weeks back.

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

Marco Moock wrote:

Hello!

Various governments around the world - including the US and EU - want
to have backdoors in encryption technology.

Is there anything known how FOSS developers will deal with that?

Especially if they are enforced to implement backdoors.

If I would be forced, which I doubt, I would comment the code
with something like this:

// backdoor begins here

backdoor code

// backdoor ends here

and put in the README how to exchange that code with proper one.

HTH

--
Regards
Stefan

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

Stefan Claas <pollux@tilde.club> wrote:

Marco Moock wrote:

Hello!

Various governments around the world - including the US and EU -
want to have backdoors in encryption technology.

Is there anything known how FOSS developers will deal with that?

Especially if they are enforced to implement backdoors.

If I would be forced, which I doubt, I would comment the code with
something like this:

// backdoor begins here

backdoor code

// backdoor ends here

and put in the README how to exchange that code with proper one.

Likely would not work well. Such forcing would likely also be
accompanied by a gag order preventing you from admitting the backdoor
even exists and so such comments and readme text would be a likely gag
order violation that would land you in jail.

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

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

If I would be forced, which I doubt, I would comment the code with something like this:

// backdoor begins here

backdoor code

// backdoor ends here

and put in the README how to exchange that code with proper one.

Likely would not work well. Such forcing would likely also be
accompanied by a gag order preventing you from admitting the backdoor
even exists and so such comments and readme text would be a likely gag
order violation that would land you in jail.

Well, I gues this may only apply to big FOSS projects, where they can
force teams, or an individual team member, but not the millions of FOSS programmers out there.

Another option for folks, living in West-Eurasia, might be to handle
over the correct code to people in BRICS countries and publish it there.

We should also not forget that Democrats (back then Senator Biden),
in the U.S., started the Crypto War ...

--
Regards
Stefan

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

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

If I would be forced, which I doubt, I would comment the code with
something like this:

// backdoor begins here

backdoor code

// backdoor ends here

and put in the README how to exchange that code with proper one.

Likely would not work well. Such forcing would likely also be
accompanied by a gag order preventing you from admitting the
backdoor even exists and so such comments and readme text would be a
likely gag order violation that would land you in jail.

Well, I gues this may only apply to big FOSS projects,

Your prior post did not specify FOSS vs. closed source.

where they can force teams, or an individual team member, but not the millions of FOSS programmers out there.

We might like to think there are millions of FOSS programmers, but
reality is more like this XKCD than we want to believe:

https://xkcd.com/2347/

Another option for folks, living in West-Eurasia, might be to handle
over the correct code to people in BRICS countries and publish it
there.

In essence, that is what happened with PGP, and was in part what led to
the US govt. giving up on their "crypto export bans". You should be
able to find an article on the history on the web if you want details.

We should also not forget that Democrats (back then Senator Biden),
in the U.S., started the Crypto War ...

Yes, and worries of inserting backdoors have been around since prior to
that time. Some that ultimately turned out to appear to be unfounded
(the worry that the NSA's tweak of the DES s-boxes was a hidden
backdoor, years later it turned out the tweaks increased DES's
resistance to differential attacks). Others were more explicit
(clipper chip, which explicitily contained a "govt. backdoor").

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

Chris M. Thomasson wrote:

On 4/28/2024 2:06 AM, Stefan Claas wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

If I would be forced, which I doubt, I would comment the code with
something like this:

// backdoor begins here

backdoor code

// backdoor ends here

and put in the README how to exchange that code with proper one.

Likely would not work well. Such forcing would likely also be
accompanied by a gag order preventing you from admitting the backdoor
even exists and so such comments and readme text would be a likely gag
order violation that would land you in jail.

Well, I gues this may only apply to big FOSS projects, where they can
force teams, or an individual team member, but not the millions of FOSS programmers out there.

Another option for folks, living in West-Eurasia, might be to handle
over the correct code to people in BRICS countries and publish it there.

We should also not forget that Democrats (back then Senator Biden),
in the U.S., started the Crypto War ...

Think if an algorithm A that is published for anyone to implement. Not
raw code, but the algorithm itself. A standard, like HMAC or something.
There "might" be a backdoor in the algorithm itself, however its very,
VERY, very... hard to find. This is why I asked about HMAC having a
backdoor by default. Something that dr. spoofs a lot can take advantage
of. Rich said probably not, wrt the algorithm itself...

But would a published algorithm not been more peer reviewed than later
a lot of code implementations, from various people?

--
Regards
Stefan

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

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 4/29/2024 10:45 AM, Stefan Claas wrote:

But would a published algorithm not been more peer reviewed than
later a lot of code implementations, from various people?

I hope so! I ask this question about HMAC because my experimental
encryption uses it.

There your larger concern would be someone hiding a backdoor in the
python library you utilize to perform the HMAC. I.e., someone
slipping compressed and obsfucated test files into the tests directory
for the library, then modifying the python build system in a sly way to deobsfucate and decompress the test files, yielding "backdoor code"
that is slyly inserted into the copy of the library your example on the
web loads when it does its work.

While that is tricky to keep hidden, it is by far your bigger threat
than worrying that there's a backdoor in the underlying HMAC algorithm.
The underlying algorithm (assuming it is SHA or one of the other known
ones) has likely been vetted enough that it (if followed to the letter
by a given library) does not have a probem.

But the library you use, do you carefully check just exactly what
changed when you upgrade to a new version (for whatever reason you
might upgrade to a new version)? That's the path to being backdoored, something getting slipped into the library code you are using.

And, note, the library could be backdoored such that when you feed it
data, it produces the exact expected outputs (while also doing
something else as well). Which would mean any tests you might have
yourself to verify the library produces correct hash outputs would
pass, even though the "backdoor code" got inserted.

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

Rich <rich@example.invalid> writes:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

If I would be forced, which I doubt, I would comment the code with
something like this:

...

// backdoor begins here

...

Likely would not work well. Such forcing would likely also be
accompanied by a gag order preventing you from admitting the
backdoor even exists and so such comments and readme text would be a
likely gag order violation that would land you in jail.

Well, I gues this may only apply to big FOSS projects,

Your prior post did not specify FOSS vs. closed source.

It was, however, a response to:

Is there anything known how FOSS developers will deal with that?

so there weren't many dots to join.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

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

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a public channel.......

......backdoors are the least of their worries!

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

Am 07.05.2024 18:20 Uhr schrieb Edward Teach:

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a
public channel.......

......backdoors are the least of their worries!

Isn't enough. There is a time when that message is unencrypted (e.g.
when entering it to the crypto application). The operating system can
then read the cleartext. If the backdoor is in the OS, X11 etc., it
still works here.

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

Chris M. Thomasson wrote:

On 5/8/2024 9:27 PM, Marco Moock wrote:

Am 07.05.2024 18:20 Uhr schrieb Edward Teach:

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a
public channel.......

......backdoors are the least of their worries!

Isn't enough. There is a time when that message is unencrypted (e.g.
when entering it to the crypto application). The operating system can
then read the cleartext. If the backdoor is in the OS, X11 etc., it
still works here.

Go to a 100% "clean room", cloaked, cannot receive and/or send anything...

Encrypt a message on a clean thumb drive. Take out the clean disk with a single file on it. Destroy the computer... Exit the clean room. This
disk contains an encrypted file.

Is it safe?

To expensive I would say. Better use secure pencil and paper ciphers.

BTW. You can also purchase Faraday equipment, relatively cheap and use
a second offline mini notebook with it. I purchased such things from
China[1] and the U.S.[2]

[1] <https://www.bing.com/shop?q=emf+rf+shielding+nickel+copper+fabric+from+china&FORM=SHOPPA&originIGUID=56F802844E0A485EBC37D87DA405CAC0>

[2] https://mosequipment.com/
--
Regards
Stefan

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

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/8/2024 9:27 PM, Marco Moock wrote:

Am 07.05.2024 18:20 Uhr schrieb Edward Teach:

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a
public channel.......

......backdoors are the least of their worries!

Isn't enough. There is a time when that message is unencrypted (e.g.
when entering it to the crypto application). The operating system can
then read the cleartext. If the backdoor is in the OS, X11 etc., it
still works here.

Go to a 100% "clean room", cloaked, cannot receive and/or send anything...

Encrypt a message on a clean thumb drive.

Where did you obtain the thumb drive?

Did you build it, from the ground up, or did you bring it into the
clean-room after purchase from a vendor?

If you purchased from a vendor, then how do you know said vendor did
not include a hardware backdoor on that thumb drive?

Take out the clean disk with a
single file on it. Destroy the computer...

How did the computer get into the clean room? How are you sure that no hardware on the computer has a backdoor, or that no software running on
the computer has a backdoor?

Exit the clean room. This disk contains an encrypted file.

Is it safe?

The answer depends upon whether the thumbdrive and/or the computer used
in the clean room contained a hardware or software back door.

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

On Thu, 9 May 2024 22:15:01 -0000 (UTC), Rich wrote:

How did the computer get into the clean room? How are you sure that no hardware on the computer has a backdoor, or that no software running on
the computer has a backdoor?

And even more problematic: electrons are constantly recycled, who can tell where they've been prior to entering the room?

--
Cri-Cri

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

Cri-Cri wrote:

On Thu, 9 May 2024 22:15:01 -0000 (UTC), Rich wrote:

How did the computer get into the clean room? How are you sure that
no hardware on the computer has a backdoor, or that no software
running on the computer has a backdoor?

And even more problematic: electrons are constantly recycled, who can
tell where they've been prior to entering the room?

You make sure to power the room with a.c., so no new electrons enter.
But better check on the copper that was used for the initial
construction.
--
*********** To reply by e-mail, make w single in address **************

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

On 10/05/2024 17:19, Stefan Claas wrote:

Chris M. Thomasson wrote:

On 5/9/2024 3:15 PM, Rich wrote:

The answer depends upon whether the thumbdrive and/or the computer used
in the clean room contained a hardware or software back door.

Hopefully, the thumbdrive is clean. If there even is such a thing...

Why not use a 3.5 inch disk drive and 3.5 inch disks? Still available
at Amazon and I think the content written on 3.5 inch disk can be easily examined with a disk editor. And they are loud, so you can hear the read/write
process. :-)

Write-once CDs are also good.

Peter Fairbrother

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

Chris M. Thomasson wrote:

On 5/9/2024 3:15 PM, Rich wrote:

The answer depends upon whether the thumbdrive and/or the computer used
in the clean room contained a hardware or software back door.

Hopefully, the thumbdrive is clean. If there even is such a thing...

Why not use a 3.5 inch disk drive and 3.5 inch disks? Still available
at Amazon and I think the content written on 3.5 inch disk can be easily examined with a disk editor. And they are loud, so you can hear the read/write process. :-)

--
Regards
Stefan

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

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/9/2024 3:15 PM, Rich wrote:

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/8/2024 9:27 PM, Marco Moock wrote:

Am 07.05.2024 18:20 Uhr schrieb Edward Teach:

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a
public channel.......

......backdoors are the least of their worries!

Isn't enough. There is a time when that message is unencrypted (e.g.
when entering it to the crypto application). The operating system can
then read the cleartext. If the backdoor is in the OS, X11 etc., it
still works here.

Go to a 100% "clean room", cloaked, cannot receive and/or send anything... >>>
Encrypt a message on a clean thumb drive.

Where did you obtain the thumb drive?

Did you build it, from the ground up, or did you bring it into the
clean-room after purchase from a vendor?

If you purchased from a vendor, then how do you know said vendor did
not include a hardware backdoor on that thumb drive?

Take out the clean disk with a
single file on it. Destroy the computer...

How did the computer get into the clean room? How are you sure that no
hardware on the computer has a backdoor, or that no software running on
the computer has a backdoor?

The computer would have to be clean.

Did you manufacture the computer yourself? Or did you buy it from Acme
corp?

If you bought it from Acme Corp, how do you know that Acme Corp did not
install a hardware backdoor in the computer?

Did you install the OS yourself, or let Acme install it?

If you let Acme install the OS, how do you know that Acme did not
install a hidden software backdoor?

If you installed the OS yourself, where did you get the files?

Did you create them all yourself, or use a distribution collection?

If you used a distribution collection, how do you know that your
distribution did not install a software backdoor in the OS during the
install process?

However, once its in the room, it
cannot communicate with the outside world, and gets utterly destroyed
after the encryption process. Turned into ashes.

That just means that it is no longer avaiable for inspection. But that
fact is of no help in determining if there was a backdoor somewhere
/during/ the encryption process.

Humm... Damn.

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

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

So, is there a way to use a clean room, a clean computer and a clean
medium to store the encrypted file? Assuming clean means clean... ;^o

If you assume that "clean means clean" as to the computer hardware then
you don't necessarily need a "clean room" [1]. You just need the
hardware and software you are using at the time to be clean (as in free
of backdoors).

If they are free of backdoors at the time you are using them then your
actions on them disappear into history unrecorded (beyond whatever
outputs you intentionally made a record of).



[1] If you are being surveiled sufficient that some agency is
monitoring the RF emissions from your computer, at the same time you
encrypt whatever it is you are encrypting, with sufficient detail to
know what you are up to, then you likely have much bigger problems well
beyond whether Acme Corp installed a backdoor into your computer.

Plus keep in mind that "clean room" usually refers to particulate
contaminants, the phrase you likely are looking for is "Faraday cage".

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

On Fri, 10 May 2024 13:21:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 5/9/2024 3:15 PM, Rich wrote:

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/8/2024 9:27 PM, Marco Moock wrote:

Am 07.05.2024 18:20 Uhr schrieb Edward Teach:

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a
public channel.......

......backdoors are the least of their worries!

Isn't enough. There is a time when that message is unencrypted
(e.g. when entering it to the crypto application). The operating
system can then read the cleartext. If the backdoor is in the OS,
X11 etc., it still works here.

Go to a 100% "clean room", cloaked, cannot receive and/or send
anything...

Encrypt a message on a clean thumb drive.

Where did you obtain the thumb drive?

Did you build it, from the ground up, or did you bring it into the clean-room after purchase from a vendor?

If you purchased from a vendor, then how do you know said vendor did
not include a hardware backdoor on that thumb drive?

Take out the clean disk with a
single file on it. Destroy the computer...

How did the computer get into the clean room? How are you sure
that no hardware on the computer has a backdoor, or that no
software running on the computer has a backdoor?

The computer would have to be clean. However, once its in the room,
it cannot communicate with the outside world, and gets utterly
destroyed after the encryption process. Turned into ashes.

Humm... Damn.

Exit the clean room. This disk contains an encrypted file.

Is it safe?

The answer depends upon whether the thumbdrive and/or the computer
used in the clean room contained a hardware or software back door.

Sorry I started this thread......in my world "private encryption" only
needs to be private for twenty-four hours.....maybe less!!!

After that.......it doesn't matter who knows.................

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

On 05/06/2024 20:02, Edward Teach wrote:

On Fri, 10 May 2024 13:21:15 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 5/9/2024 3:15 PM, Rich wrote:

Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:

On 5/8/2024 9:27 PM, Marco Moock wrote:

Am 07.05.2024 18:20 Uhr schrieb Edward Teach:

Backdoors.

When people use PRIVATE ENCRYPTION BEFORE any messaging enters a
public channel.......

......backdoors are the least of their worries!

Isn't enough. There is a time when that message is unencrypted
(e.g. when entering it to the crypto application). The operating
system can then read the cleartext. If the backdoor is in the OS,
X11 etc., it still works here.

Go to a 100% "clean room", cloaked, cannot receive and/or send
anything...

The magic word is "air-gapped".

Plus "Faraday caged". Though a faraday cage can transmit magnetic
fields, so "magnetically shielded". And the power supply can transmit
info, so "internally powered". And to stop remote
over-the-shoulder-surfing, "opaque". "Soundproof", of course. Und so weiter.

Encrypt a message on a clean thumb drive.

A writable CD is better, less places to put a hardware back door. A
blowtorch works well for later secure deletion of the CD. For those who
might object to the fumes, you could print out the ciphertext as a
series of QR type codes on paper, then burn them.



However even then a backdoor might reveal the key in the ciphertext in
eg padding, nonces, through limiting possible key selections etc. etc;
perhaps in encrypted form so only the unintended recipient can read it,
and to make it look random as good ciphertext should look and thus
harder to detect.

That might sound complicated but if you know which encryption algorithms
are to be used and have hardware or software access to the computer
before the encryption is done it is fairly straightforward to implement.

Sorry I started this thread......in my world "private encryption" only
needs to be private for twenty-four hours.....maybe less!!!

After that.......it doesn't matter who knows.................

For the rest of us mortals (or perhaps more importantly, for our
clients), it can be a matter of life and death, for a lifetime.


100% security is very very very hard, often impossible. Yet security is
still a Boolean (tenth law).

Peter Fairbrother

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