Keith C. Perry via plug on 1 Dec 2021 15:59:58 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] kernel, rpm, croc, du, encrypted


I really don't see the point of this either...

The idea of creating "strong security" with "weak passwords" is cryptographic concept that exists and is used in a number of ways already.  I had not heard of PAKE either but after reading the wiki link and another linked paper (https://link.springer.com/chapter/10.1007%2F978-3-642-22137-8_23) abstract, it seems like they are trying to solve / create a PKI system without calling it PKI.  There seems to have been concerns about some of the methods used (e.g. J-PAKE, EKE, SPEKE) but there does appear to be research into revisions such as J-PAKE which is in OpenSSL and OpenSSH as an experimental authentication protocol (https://en.wikipedia.org/wiki/Password_Authenticated_Key_Exchange_by_Juggling).

I know a lot of people have adopted cloud this and that so maybe it makes more sense there but this is not something that seems all that compelling relative to current solutions in general.  I haven't heard technical or non-technical people clamoring for efficient file transfer solutions in over a decade.

Another thing I would point out is that this is still a single layer approach.  Increasingly more security constructs are being upgraded to multi-factor implementations.  I use scp and sftp a lot at apparently there is a way to do 2FA already there (which I didn't know but now will checking out soon than later to see how it works).


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Managing Member, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167 
www.daotechnologies.com

----- Original Message -----
From: "Rich Freeman via plug" <plug@lists.phillylinux.org>
To: "Walt Mankowski" <waltman@pobox.com>
Cc: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Wednesday, December 1, 2021 5:26:30 PM
Subject: Re: [PLUG] kernel, rpm, croc, du, encrypted

On Wed, Dec 1, 2021 at 4:05 PM Walt Mankowski via plug
<plug@lists.phillylinux.org> wrote:
>
> Ah, I see, I hadn't read the examples very closely. Now that I have, I
> have more questions:

I did a TINY bit of research as I was curious.  Do not consider this
as some kind of personal endorsement.  It does use technologies I was
previously unaware of.

>
> * Where are the files being stored?

The files are directly streamed through a relay unless both ends are
on the same LAN.  They are not intended to be stored.  Of course, the
relay could store the encrypted stream without your knowledge.

The relay is FOSS and you can use your own.  By default it uses a
central relay operated by the developer.

> * What port are they using?

The relay apparently uses TCP ports 9009-9013 by default.  This can be tweaked.

> * How long do the files stay there?

In theory they aren't intended to be stored.  Of course anybody with
access to your traffic, including the relay, can store it forever.

> Assuming they're just using key/value pairs and accessing it over
> https, this sounds like a security nightmare. It sounds like if anyone
> can guess the codeword they can download the file, potentially
> forever. Is there really no authentication component?

They're using a technology called PAKE [1], which apparently uses the
passphrase as part of the key exchange mechanism to exchange a much
stronger session key.  I didn't read all the gory details of the math
but Wikipedia suggests the concept is sound.  Apparently the key
exchange mechanism can defeat an MITM, so the connection is
effectively secured by a full-length session key and not just the
passphrase.  In theory that means that attacking any stored network
streams is no different from attacking any other intercepted SSL/etc
traffic.

Now, whether their implementation is secure I couldn't say, but it
seems to be backed by some concepts that sound reasonable.  This is
the first I've heard of PAKE though.

One obvious shortcoming is that it sounds like all the traffic goes
through the relay.  It would be better if the relay facilitated
discovery but the clients were able to find some way to directly
connect.  That would obviously depend on the firewall configs.
Otherwise the relay becomes a bottleneck.

1 - https://en.wikipedia.org/wiki/Password-authenticated_key_agreement
-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug