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