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

Groups > linux.debian.user > #226371 > unrolled thread

Encrypt files on Linux, decrypt on Windows

Back to article view | Back to linux.debian.user

Contents

  Encrypt files on Linux, decrypt on Windows local10 <local10@tutanota.com> - 2020-08-21 19:50 +0200
    Re: Encrypt files on Linux, decrypt on Windows john doe <johndoe65534@mail.com> - 2020-08-21 20:20 +0200
    Re: Encrypt files on Linux, decrypt on Windows Linux-Fan <Ma_Sys.ma@web.de> - 2020-08-21 20:30 +0200
      Re: Encrypt files on Linux, decrypt on Windows David Christensen <dpchrist@holgerdanske.com> - 2020-08-21 21:20 +0200
        Re: Encrypt files on Linux, decrypt on Windows john doe <johndoe65534@mail.com> - 2020-08-21 21:20 +0200
          Re: Encrypt files on Linux, decrypt on Windows Linux-Fan <Ma_Sys.ma@web.de> - 2020-08-21 22:00 +0200
      Re: Encrypt files on Linux, decrypt on Windows Teemu Likonen <tlikonen@iki.fi> - 2020-08-21 22:40 +0200
        [OT] Linux-Fan's bad signatures (Re: Encrypt files on Linux,          decrypt on Windows) Linux-Fan <Ma_Sys.ma@web.de> - 2020-08-22 00:20 +0200
          Re: Linux-Fan's bad signatures Teemu Likonen <tlikonen@iki.fi> - 2020-08-22 09:20 +0200
            Re: Linux-Fan's bad signatures Linux-Fan <Ma_Sys.ma@web.de> - 2020-08-22 12:50 +0200
          Signing emails, was Re: General-Purpose Server for Debian Stable David Wright <deblis@lionunicorn.co.uk> - 2020-10-02 05:30 +0200
    Re: Encrypt files on Linux, decrypt on Windows Paul Johnson <baloo@ursamundi.org> - 2020-08-21 20:40 +0200
      Re: Encrypt files on Linux, decrypt on Windows Charles Curley <charlescurley@charlescurley.com> - 2020-08-21 21:10 +0200
        Re: Encrypt files on Linux, decrypt on Windows Marek Mosiewicz <marek.mosiewicz@jotel.com.pl> - 2020-08-23 11:30 +0200
          Re: Encrypt files on Linux, decrypt on Windows <tomas@tuxteam.de> - 2020-08-23 11:40 +0200
        Re: Encrypt files on Linux, decrypt on Windows Andrei POPESCU <andreimpopescu@gmail.com> - 2020-08-23 13:10 +0200
          Re: Encrypt files on Linux, decrypt on Windows Charles Curley <charlescurley@charlescurley.com> - 2020-08-23 16:40 +0200
          Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows Celejar <celejar@gmail.com> - 2020-08-25 20:20 +0200
            Re: Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows Andrei POPESCU <andreimpopescu@gmail.com> - 2020-08-26 08:30 +0200
              Re: Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows Celejar <celejar@gmail.com> - 2020-08-26 14:10 +0200
    Re: Encrypt files on Linux, decrypt on Windows Matthew Graybosch <hello@matthewgraybosch.com> - 2020-08-21 20:50 +0200
      Re: Encrypt files on Linux, decrypt on Windows <tomas@tuxteam.de> - 2020-08-21 22:00 +0200
        Re: Encrypt files on Linux, decrypt on Windows Matthew Graybosch <hello@matthewgraybosch.com> - 2020-08-21 22:20 +0200
          Re: Encrypt files on Linux, decrypt on Windows rhkramer@gmail.com - 2020-08-22 02:20 +0200
            Re: Encrypt files on Linux, decrypt on Windows Matthew Graybosch <hello@matthewgraybosch.com> - 2020-08-22 03:30 +0200
              Re: Encrypt files on Linux, decrypt on Windows <tomas@tuxteam.de> - 2020-08-22 09:40 +0200
                Re: Encrypt files on Linux, decrypt on Windows Matthew Graybosch <hello@matthewgraybosch.com> - 2020-08-23 19:10 +0200
            Re: Encrypt files on Linux, decrypt on Windows Jonathan Dowland <jon+debian-user@dow.land> - 2020-08-26 11:40 +0200
              Re: Encrypt files on Linux, decrypt on Windows Hornet <hornetmadness@gmail.com> - 2020-08-29 15:40 +0200
    Re: Encrypt files on Linux, decrypt on Windows Teemu Likonen <tlikonen@iki.fi> - 2020-08-21 21:10 +0200
      Re: Encrypt files on Linux, decrypt on Windows Teemu Likonen <tlikonen@iki.fi> - 2020-08-21 21:20 +0200
        Re: Encrypt files on Linux, decrypt on Windows David Christensen <dpchrist@holgerdanske.com> - 2020-08-21 21:30 +0200
    Re: Encrypt files on Linux, decrypt on Windows David Christensen <dpchrist@holgerdanske.com> - 2020-08-21 21:20 +0200
    Re: Encrypt files on Linux, decrypt on Windows Hans <hans.ullrich@loop.de> - 2020-08-21 22:30 +0200
      Re: Encrypt files on Linux, decrypt on Windows Hans <hans.ullrich@loop.de> - 2020-08-21 22:40 +0200
    Re: Encrypt files on Linux, decrypt on Windows Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2020-08-22 03:10 +0200
    Re: Encrypt files on Linux, decrypt on Windows deloptes <deloptes@gmail.com> - 2020-08-22 09:50 +0200
    Re: Encrypt files on Linux, decrypt on Windows mick crane <mick.crane@gmail.com> - 2020-08-22 12:20 +0200
      "What's wrong with...?" Teemu Likonen <tlikonen@iki.fi> - 2020-08-22 20:30 +0200
        Re: "What's wrong with...?" Dan Ritter <dsr@randomstring.org> - 2020-08-22 20:40 +0200
        Re: "What's wrong with...?" mick crane <mick.crane@gmail.com> - 2020-08-23 08:50 +0200
          Re: "What's wrong with...?" Jonathan Dowland <jon+debian-user@dow.land> - 2020-08-26 11:30 +0200

Page 1 of 3  [1] 2 3  Next page →

#226371 — Encrypt files on Linux, decrypt on Windows

Hi,

What would be a reasonably secure and simple way to encrypt files on Linux and then send them to a  non-technical Windows user so she would be able decrypt and read them?

Any ideas? Thanks

[toc] | [next] | [standalone]

#226374

On 8/21/2020 7:46 PM, local10 wrote:
> Hi,
>
> What would be a reasonably secure and simple way to encrypt files on Linux and then send them to a  non-technical Windows user so she would be able decrypt and read them?
>
> Any ideas? Thanks
>

Veracrypt could be one option.


--
John Doe

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

#226375

[Multipart message — attachments visible in raw view] — view raw

local10 writes:

> Hi,
>
> What would be a reasonably secure and simple way to encrypt files on Linux
> and then send them to a  non-technical Windows user so she would be able
> decrypt and read them?
>
> Any ideas? Thanks

Consider 7-Zip from Debian package p7zip-full and available for Windows
syswtems: https://www.7-zip.org/

Encrypt on Linux:
$ 7z a -ptestwort -mhe=on secret.7z secret.txt

Decrypt on Windows: Double-Click or use commandline:
% 7z x -o. secret.7z

Alternatively, you could also use aescrypt
(https://www.aescrypt.com/). It is not in Debian but supports a variety of
operating systems including Linux and Windows. GPG should also run on
Windows, but is a little harder to use IMHO.

HTH
Linux-Fan

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

#226385

On 2020-08-21 11:24, Linux-Fan wrote:
> local10 writes:
> 
>> Hi,
>>
>> What would be a reasonably secure and simple way to encrypt files on 
>> Linux
>> and then send them to a  non-technical Windows user so she would be able
>> decrypt and read them?
>>
>> Any ideas? Thanks
> 
> Consider 7-Zip from Debian package p7zip-full and available for Windows
> syswtems: https://www.7-zip.org/
> 
> Encrypt on Linux:
> $ 7z a -ptestwort -mhe=on secret.7z secret.txt
> 
> Decrypt on Windows: Double-Click or use commandline:
> % 7z x -o. secret.7z


So, the recipient must install 7-Zip on their Windows computer?


David

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

#226387

On 8/21/2020 9:11 PM, David Christensen wrote:
> On 2020-08-21 11:24, Linux-Fan wrote:
>> local10 writes:
>>
>>> Hi,
>>>
>>> What would be a reasonably secure and simple way to encrypt files on
>>> Linux
>>> and then send them to a  non-technical Windows user so she would be able
>>> decrypt and read them?
>>>
>>> Any ideas? Thanks
>>
>> Consider 7-Zip from Debian package p7zip-full and available for Windows
>> syswtems: https://www.7-zip.org/
>>
>> Encrypt on Linux:
>> $ 7z a -ptestwort -mhe=on secret.7z secret.txt
>>
>> Decrypt on Windows: Double-Click or use commandline:
>> % 7z x -o. secret.7z
>
>
> So, the recipient must install 7-Zip on their Windows computer?
>
>
> David
>

There is a portable version for Windows, if I recall correctly.

To the OP, look at creating a self extracting archive (not sure if it
works from Linux to Windows though).

--
John Doe

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

#226391

[Multipart message — attachments visible in raw view] — view raw

john doe writes:

> On 8/21/2020 9:11 PM, David Christensen wrote:
>> On 2020-08-21 11:24, Linux-Fan wrote:

[...]

>>> Encrypt on Linux:
>>> $ 7z a -ptestwort -mhe=on secret.7z secret.txt
>>>
>>> Decrypt on Windows: Double-Click or use commandline:
>>> % 7z x -o. secret.7z
>>
>>
>> So, the recipient must install 7-Zip on their Windows computer?

In that example: Yes or use a 7z.exe obtained from the website without
installation.

[...]

> To the OP, look at creating a self extracting archive (not sure if it
> works from Linux to Windows though).

It works from Linux to Windows, but it is trickier than I had imagined:

On Linux:

 * Go to https://www.7-zip.org/download.html and download 64-bit x64

 * Extract file 7z1900-x64.exe with 7z.

   $ mkdir sub
   $ 7z x -osub 7z1900-x64.exe

 * Copy 7z.sfx from the extracted installer

   $ cp sub/7z.sfx .

 * Create SFX archive for Windows

   $ 7z a -mhe=on -ptestwort -sfx7z.sfx mysfx.exe secret.txt

 * Send file `mysfx.exe` to the Windows user

On Windows:

 * Run `mysfx.exe` -- it prompts for the password (`testwort`).

I nowdays prefer the portable/installed version over SFX archives because
uncommon executables are often rejected by antivirus software (especially
.exe attachments to e-mails are prone to being deleted for security
reasons...). Although most scanners seem to be fine with a generated SFX
archive at the moment:

https://www.virustotal.com/gui/file/e2dd36862c27e1551916ed3e773a55ecedf2b35e658522fa982369cc90eaf488/detection

[...]

HTH
Linux-Fan

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

#226394

[Multipart message — attachments visible in raw view] — view raw

* 2020-08-21 20:24:29+02, Linux-Fan wrote:

> GPG should also run on Windows, but is a little harder to use IMHO.

GnuPG it is pretty hard everywhere. Your recent signatures are reported
as "bad" (at least by Notmuch and Mutt). The signed data (message)
doesn't match with the signature.

About this thread's subject: If the original requirement for "reasonable
security" means also data integrity (the content is untouched) or
authentication (the sender is verified) then this all starts to point to
digital signatures, thus OpenPGP (like GnuPG).

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

#226396 — [OT] Linux-Fan's bad signatures (Re: Encrypt files on Linux, decrypt on Windows)

[Multipart message — attachments visible in raw view] — view raw

Teemu Likonen writes:

> * 2020-08-21 20:24:29+02, Linux-Fan wrote:
>
> > GPG should also run on Windows, but is a little harder to use IMHO.
>
> GnuPG it is pretty hard everywhere. Your recent signatures are reported
> as "bad" (at least by Notmuch and Mutt). The signed data (message)
> doesn't match with the signature.

[...]

The copy I receive from the list does not verify correctly here, either.
It seems somewhere along the path the e-mails content is actually mangled.
-- some additional newlines are introduced compared to my local copy from
the "Sent" folder which verifies correctly.

Attached are `sent.txt` (and `sent.eml`) and `received.txt` -- the very same
e-mail as seen in my Sent folder and Inbox respectively... Interestingly, if
I split out the signatures and message contents, I get bad signature for
both variatns despite the fact that the e-mail client can somehow verify the
sent e-mail...

???
Linux-Fan

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

#226403 — Re: Linux-Fan's bad signatures

[Multipart message — attachments visible in raw view] — view raw

* 2020-08-22 00:17:19+02, Linux-Fan wrote:

> The copy I receive from the list does not verify correctly here,
> either.

The content between MIME separator lines are signed. The separators
itself are not part of the signature and also the last empty line is not
part of the signature.

    --=_pte5-5038-1598034269-0003
    --=_pte5-5038-1598034269-0003

In the example below the signed data begins with the "Content-Type" text
and ends with the "This is my message." plus one newline. The second
newline which creates the empty line at the end of the MIME part is not
part of the signature.

    --=_pte5-5038-1598034269-0003
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    This is my message.

    --=_pte5-5038-1598034269-0003

So if the signature is in "signature.asc" and the content between the
separator lines are in file "content.txt" this command should verify it:

    gpg --verify signature.asc content.txt

It seems that the signatures are made with "gpg --textmode" so that it
doesn't matter if the content has LF or CR + LF newlines.

Your "sent" and "received" messages even have different MIME part
headers and encoding. At least those things change after the signature
is made. See the attached "diff -u" output. But I can't verify any of
your messages even if I manually edit the MIME parts and try different
things.

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

#226410 — Re: Linux-Fan's bad signatures

[Multipart message — attachments visible in raw view] — view raw

Teemu Likonen writes:

> * 2020-08-22 00:17:19+02, Linux-Fan wrote:
>
> > The copy I receive from the list does not verify correctly here,
> > either.
>
> The content between MIME separator lines are signed. The separators
> itself are not part of the signature and also the last empty line is not
> part of the signature.

[...]

> So if the signature is in "signature.asc" and the content between the
> separator lines are in file "content.txt" this command should verify it:
>
>     gpg --verify signature.asc content.txt
>
> It seems that the signatures are made with "gpg --textmode" so that it
> doesn't matter if the content has LF or CR + LF newlines.
>
> Your "sent" and "received" messages even have different MIME part
> headers and encoding. At least those things change after the signature
> is made. See the attached "diff -u" output. But I can't verify any of
> your messages even if I manually edit the MIME parts and try different
> things.

Thank you for sharing this analysis. I was trying to figure it out but thought
the signature was only over the text and not over the headers.

I cannot get it to verify with manual editing, either. Yet somehow, my mail
client's `mimegpg` command can do it, given the unmangled .eml file -- the one
I had sent to the list also got changed during the transfer.
Attached is a compressed version in the hope that it will come across
without being changed. The file's sha256sum should be as follows:

04076b5cc68367f1bfda394ba32416891ffa1800b8f7214a04cb2fc4efa21004  sent.eml
ac2a25bc54417db2b62d883b9ef31a93d25e9afc113cd9f9d555d87d2720baa8  sent.eml.xz

The source code is available, I will just need to find some time to analyze
what it does exactly. Maybe I should ask on the e-mail client's maling list,
too...

Thanks
Linux-Fan

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

#227535 — Signing emails, was Re: General-Purpose Server for Debian Stable

On Fri 02 Oct 2020 at 01:15:36 (+0200), Linux-Fan wrote:
> Dan Ritter writes:
> > Linux-Fan wrote:
> 
> [...]
> 
> OT: Message signature is still invalid, but I could track it down to some
> weird changes in space characters between what I send to and what I receive
> from the list. I have now idea how to solve it, though...

Looking back at this signed post,
https://lists.debian.org/debian-user/2020/08/msg00741.html
I see the following lines:

On Sat 22 Aug 2020 at 00:17:19 (+0200), Linux-Fan wrote:
> Teemu Likonen writes:
> > * 2020-08-21 20:24:29+02, Linux-Fan wrote:
> 
> [...]
> 
> The copy I receive from the list does not verify correctly here, either.
> It seems somewhere along the path the e-mails content is actually mangled.
> -- some additional newlines are introduced compared to my local copy from
> the "Sent" folder which verifies correctly.
> 
> Attached are `sent.txt` (and `sent.eml`) and `received.txt` -- the very same
> e-mail as seen in my Sent folder and Inbox respectively... Interestingly, if
> I split out the signatures and message contents, I get bad signature for
> both variatns despite the fact that the e-mail client can somehow verify the
> sent e-mail...
> 
> ???
> Linux-Fan

> --=_pte5-5038-1598034269-0003
> Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit

This is the header for the "sent" file. You appear to be sending
8bit data without encoding it. AIUI that contravenes "all data signed
according to this protocol MUST be constrained to 7 bits (8-bit data
MUST be encoded using either Quoted-Printable or Base64)".

It's possible that your mailer set Content-Transfer-Encoding: 7bit
because this message happened not to contain any 8bit characters.

In my mutt, a message like that would be sent with:

  Content-Type: text/plain; charset=us-ascii
  Content-Disposition: inline

whereas one containing 8bit chars would be sent with:

  Content-Type: text/plain; charset=utf-8
  Content-Disposition: inline
  Content-Transfer-Encoding: 8bit

(Of course, I'm allowed to send 8bit because I'm not signing it.)

Whatever—somewhere in the chain of transmission, the email
gets encoded into Q-P:

> --=_pte5-5038-1598034269-0003
> Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable

Unfortunately, the Content-Transfer-Encoding is AIUI part of the
signed message, so the "received" file can never match the "sent".

For whatever reason, by the time your email reaches my mailbox, the
"sent" unencoded attachment has been encoded as Q-P, and the
"received" Q-P attachment doesn't need it. As a result, the texts
of the two attachments look very similar, with their complementary
headers. Summarising, as displayed by mutt:

    [-- Attachment #2: sent.txt --]
    [-- Type: text/plain, Encoding: quoted-printable, Size: 1.8K --]
    Content-Disposition: attachment;
      FILENAME="sent.txt"
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable

    --=_pte5-5038-1598034269-0003
→   Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
→   Content-Disposition: inline
→   Content-Transfer-Encoding: 7bit
                               ↑↑↑↑
and:

    [-- Attachment #3: received.txt --]
    [-- Type: text/plain, Encoding: 7bit, Size: 1.8K --]
    Content-Disposition: attachment;
      FILENAME="received.txt"
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: 7bit

    --=_pte5-5038-1598034269-0003
→   Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
→   Content-Disposition: inline
→   Content-Transfer-Encoding: quoted-printable
                               ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

These → lines are signed.

This is just my interpretation of RFCs 3156 and 3676. A lot of these
RFCs is about Flowed and Delsp. I've assumed that that's all being
implemented correctly. (Mixing Q-P and Flowed is tricky at best,
disallowed at worst.) BTW, I know nothing about .eml files. I'm just
happy not to see tnef files anymore.

Cheers,
David.

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

#226378

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 21, 2020 at 12:46 PM local10 <local10@tutanota.com> wrote:

> What would be a reasonably secure and simple way to encrypt files on Linux
> and then send them to a  non-technical Windows user so she would be able
> decrypt and read them?
>

GnuPG.  It's in Debian, there's Windows versions on its website, and it's
not some mystery box like Signal.

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

#226381

On Fri, 21 Aug 2020 13:31:00 -0500
Paul Johnson <baloo@ursamundi.org> wrote:

> GnuPG.  It's in Debian, there's Windows versions on its website, and
> it's not some mystery box like Signal.

++

It also has the advantage that the cryptext will stay encrypted on any
intermediate servers. WhatsApp and Signal claim their traffic is, but
one must take their word for it.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#226441

W dniu pią, 21.08.2020 o godzinie 13∶07 -0600, użytkownik Charles
Curley napisał:
> On Fri, 21 Aug 2020 13:31:00 -0500
> Paul Johnson <baloo@ursamundi.org> wrote:
> 
> > GnuPG.  It's in Debian, there's Windows versions on its website,
> > and
> > it's not some mystery box like Signal.
> 
> ++
> 
> It also has the advantage that the cryptext will stay encrypted on
> any
> intermediate servers. WhatsApp and Signal claim their traffic is, but
> one must take their word for it.
Not to mention that GPG can be used for asymmetric cryptography.
> 

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

#226442

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 23, 2020 at 11:01:34AM +0200, Marek Mosiewicz wrote:

[...]

> Not to mention that GPG can be used for asymmetric cryptography.

Yeah, but it's a "Windows user" at the other end, and (s)he's "too
dumb to install software". And "gpg is too hard".

I must say, this theme, which came up here and there tends to make
me furious. It's condescending (we know nothing about the user in
question. Heck. the original poster has thrown in a query, and for
all I can see has disappeared). And it has the potential to become
a self-fulfilling prophecy.

I stand by: recommend GPG. Come here, if you need help. Learn something
along the way. Your life will be more interesting :-)

Cheers
-- t

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

#226443

[Multipart message — attachments visible in raw view] — view raw

On Vi, 21 aug 20, 13:07:56, Charles Curley wrote:
> On Fri, 21 Aug 2020 13:31:00 -0500
> Paul Johnson <baloo@ursamundi.org> wrote:
> 
> > GnuPG.  It's in Debian, there's Windows versions on its website, and
> > it's not some mystery box like Signal.
> 
> ++
> 
> It also has the advantage that the cryptext will stay encrypted on any
> intermediate servers. WhatsApp and Signal claim their traffic is, but
> one must take their word for it.

Signal is free and open source software.

Please do feel free to inspect the source code for potential back doors 
or vulnerabilities.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#226444

[Multipart message — attachments visible in raw view] — view raw

On Sun, 23 Aug 2020 14:03:21 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> Signal is free and open source software.
> 
> Please do feel free to inspect the source code for potential back
> doors or vulnerabilities.

Thank you for the correction. https://signal.org

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#226487 — Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows

On Sun, 23 Aug 2020 14:03:21 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Vi, 21 aug 20, 13:07:56, Charles Curley wrote:
> > On Fri, 21 Aug 2020 13:31:00 -0500
> > Paul Johnson <baloo@ursamundi.org> wrote:
> > 
> > > GnuPG.  It's in Debian, there's Windows versions on its website, and
> > > it's not some mystery box like Signal.
> > 
> > ++
> > 
> > It also has the advantage that the cryptext will stay encrypted on any
> > intermediate servers. WhatsApp and Signal claim their traffic is, but
> > one must take their word for it.
> 
> Signal is free and open source software.
> 
> Please do feel free to inspect the source code for potential back doors 
> or vulnerabilities.

I do use Signal on mobile, and I want to like it, but there are a few
things about it that just really bother me (these may not be relevant
to the OPs situation):

1) The requirement of associating accounts with (real, working) phone
numbers.

2) The (current) refusal [1] to provide an option to export messages
into a format easily accessible by the user. (I know, I can read and
try to understand Signal's code, and then write my own decryptor -
thanks, Signal).

3) The strong encouragement of the use of Google's Play Store to install
the mobile app, and the strong discouragement of other, FLOSS
compatible, methods of installation. [2]

Discussion of these and many other issues with Signal: [3]

I'm just a user, and not a very advanced one at that, but I can't get
away from the feeling that Signal is somewhat user-hostile, with an
attitude of "Trust us - Moxie is a legend, our code is great (and
FLOSS), and we really care." All true, to be sure, but still.

[1] https://github.com/signalapp/Signal-Android/issues/7586
[2] https://signal.org/android/apk/
[3] https://github.com/privacytools/privacytools.io/issues/779

Celejar

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

#226493 — Re: Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows

[Multipart message — attachments visible in raw view] — view raw

On Ma, 25 aug 20, 14:17:26, Celejar wrote:
> 
> I do use Signal on mobile, and I want to like it, but there are a few
> things about it that just really bother me (these may not be relevant
> to the OPs situation):

I never claimed it's perfect, just that it's not a "black box". See also 
this comment in one of the discussions you linked that appears to be 
more balanced:

https://github.com/privacytools/privacytools.io/issues/779#issuecomment-471687384

As far as I can tell Signal is still miles ahead of WhatsApp, Telegram, 
Snapchat, etc. and it's still challenging to get others to use it[1].

One might find that with the "perfect" communication tool there is no 
one to communicate with :) 


[1] I basically had to "blackmail" my close family and friends by 
refusing to install WhatsApp on my private phone.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#226499 — Re: Signal [Was:] Re: Encrypt files on Linux, decrypt on Windows

On Wed, 26 Aug 2020 09:29:06 +0300
Andrei POPESCU <andreimpopescu@gmail.com> wrote:

> On Ma, 25 aug 20, 14:17:26, Celejar wrote:
> > 
> > I do use Signal on mobile, and I want to like it, but there are a few
> > things about it that just really bother me (these may not be relevant
> > to the OPs situation):
> 
> I never claimed it's perfect, just that it's not a "black box". See also 

I know - I just took advantage of your comment to take the opportunity
to vent some of my frustration with Signal.

> this comment in one of the discussions you linked that appears to be 
> more balanced:
> 
> https://github.com/privacytools/privacytools.io/issues/779#issuecomment-471687384

More balanced, perhaps - there is considerable debate in that thread -
but I still side with the naysayers (the following quotes are from
that comment, not you):

> For instance, we showed that users can simply register a random phone

I agree that we shouldn't discourage Signal, and certainly not
encourage the vastly less free alternatives to it. But we also
shouldn't give it a free pass on what I consider to be its somewhat
anti-FLOSS / user hostile attitudes.

> services since the developer buys from Amazon, drinks Coca-Cola, or
> runs Windows 10 isn't about the actual service but about political
> beliefs.

These is a plain silly analogy. I don't care much about what *the
developer* uses in his personal life, and I don't even care that much
about what he uses to develop and host the software. I *do* care about
what he makes (or strongly encourages) users use, such as the Play
Store, Google Accounts, reCAPTCHAS, etc., as mentioned by the OP in
that thread.

[Back to quoting Andrei.]

> As far as I can tell Signal is still miles ahead of WhatsApp, Telegram, 

Certainly.

> Snapchat, etc. and it's still challenging to get others to use it[1].

> One might find that with the "perfect" communication tool there is no 
> one to communicate with :) 

;)

> [1] I basically had to "blackmail" my close family and friends by 
> refusing to install WhatsApp on my private phone.

I refuse to install WhatsApp as well - but that just means that I miss
some stuff, and have to trouble people to manually email me other
stuff ...

> Kind regards,

Celejar

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web