From michael at briarproject.org Wed Jan 16 03:32:50 2019 From: michael at briarproject.org (Michael Rogers) Date: Wed, 16 Jan 2019 11:32:50 +0000 Subject: [messaging] some news from e-mail e2e-encryption and chat happenings In-Reply-To: <20181221185855.GV11730@beto> References: <20181221185855.GV11730@beto> Message-ID: <5b1cdc26-dc3a-8455-2337-4671ef9dbeed@briarproject.org> On 21/12/2018 18:58, holger / xenia wrote: > - the DeltaChat "Robustness and Usability" OTF-funded project > released their results on 16 UX-oriented interviews with activists, > trainers and journalists in Ukraine. It is about routine workflows > with various devices, messaging and email apps, as well as their risk perceptions, > needs and desires. The report presents 10 take-aways to influence > DeltaChat's Chat-over-Email messenger efforts -- most takeaways and contextualizations > are interesting for all kinds of other messenging apps and crypto protocols as well: > > https://delta.chat/assets/blog/dcneedfindingreport.pdf Hi Holger, Xenia, I just wanted to say a quick thank you for publishing this needfinding report. It's an excellent document that's been useful for setting Briar's development priorities for the next year. Cheers, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x11044FD19FC527CC.asc Type: application/pgp-keys Size: 17118 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From oottela at cs.helsinki.fi Thu Jan 24 07:27:39 2019 From: oottela at cs.helsinki.fi (Markus Ottela) Date: Thu, 24 Jan 2019 17:27:39 +0200 Subject: [messaging] TFC - Onion routed messaging with endpoint security Message-ID: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> Hi! The traffic here is quite low so I hope it's ok if I post my work: TFC (https://github.com/maqp/tfc) is something I've worked on since spring 2012. The idea was to create a messaging system that splits the TCB on two airgapped computers that communicate with a networked computer via unidirectional gateways. To enforce the unidirectional behavior it's using a simple circuit that for each direction uses an optocoupler as an optical repeater in the middle of a serial gateway: The photoelectric effect in LEDs is inefficient, and the photodiodes do not emit light, so the IC only works in one way. This hardware layout prevents remotely inserted malware from entering the Source Computer (that outputs ciphertexts). It also prevents the malware from exfiltrating keys/plaintexts from the Destination Computer (that decrypts incoming messages). The Networked Computer only ever sees non-sensitive data like ciphertexts and public keys. On Networked Computer the relay program runs a v3 Onion Service and web clients needed to request data from Onion Services of contacts. In this respect it's similar to Ricochet: There is no server in the middle to tap. As for cryptographic primitives, TFC uses single X448 (OpenSSL implementation) that by default prompts the user to verify base10 fingerprints. XChaCha20-Poly1305 (libsodium implementation) has per-message forward secrecy that relies on BLAKE2b hash ratchet. Keys are generated with GETRANDOM syscall. All sensitive persistent data on endpoints is encrypted with the same XChaCha, and the key for it is derived from salt and password using Argon2d. Since during key exchange the public key needs to be typed manually into the Source Computer, DH ratchet and thus future secrecy isn't practical. The user can of course re-exchange keys whenever they like it. The lack of future secrecy is compensated by the architecture that prevents key exfiltration. The application is written in Python (3.6), is FOSS, and the HW is Free Hardware Design (circuit diagrams and step-by-step build instructions are available). The code has type annotations and I've tried to make good unit tests for it. For metadata protection I tried to make TFC to install anonymously. Onion Services hide geo-location and identity of the users. I've also added an optional traffic masking feature that locks Transmitter Program to a selected contact/group, and sends a continuous stream of noise packets to those recipients. Files and messages are inserted into the noise stream when needed. This should hide quantity, schedule, and type of communication even from an adversary that compromises the Networked Computer of sender / recipient. It's not perfect however. There's a bunch of attack vectors from Source Computer compromise during install to covert exfiltration channels in Destination Computer. I've tried to be as thorough as possible about these risks in the threat model / security design articles, which you can find from the project's wiki: https://github.com/maqp/tfc/wiki Any feedback / criticism is more than welcome! Markus From dawuud at riseup.net Thu Jan 24 12:56:31 2019 From: dawuud at riseup.net (dawuud) Date: Thu, 24 Jan 2019 20:56:31 +0000 Subject: [messaging] TFC - Onion routed messaging with endpoint security In-Reply-To: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> Message-ID: <20190124205631.cj43zl2dlik7oi73@computer> Hi Markus, It's kinda cool your thorough defense of endpoint security. Certainly I agree with you that endpoint security is important. But since we are on a mailing list that is obstensibly about solving messaging problems I will focus my comments on these issues instead. I'd like to point out that the secure messaging problem isn't really solved yet because there is currently no deployed encrypted messaging applications that provide traffic analysis resistance against global adversaries. This of course includes Tor which can trivially be broken in just a few seconds using timing correlation. And to make a more nuanced point, so called "secure messaging" applications should be using multiple security domains; currently this is my main criticism of Signal messenger besides requiring the use of phone numbers. I feel totally justified on harping on this one point until we arrive at a good solution because ex-NSA director, Michael Hayden is famously quoted as having said: "We kill people based on meta-data". Onion services do hide geographical location from adveraries that are unable to break Tor. But is this really an appropriate threat model? Do you think colluding nation state adversaries cannot break Tor? The conclusions of the academic literature on these points are quit clear and there is over 37 years of published academic literature on the topic of anonymous messaging. Many of these papers describe systems that have far stronger threat models than Tor, things like: * decryption mix networks * verified mix shuffles * private information retrieval * dining cryptographer networks * broadcast based designs (with trial decryption) * oblivious random access memory * secure multi-party computation I don't understand why you decided to use the term "traffic masking". Isn't this "traffic padding"? Without a proper statistical model to assist in tuning it's not clear how much this will help. I should mention that Tor Project is very interested in using traffic padding in future versions of Tor and they wish to encourage academics to explore this possibility. Clearly, it will take at least one PhD worth of research to establish safety margins in the use of traffic padding for Tor and I suspect discrete network event simulators will help with this. Cheers, David On Thu, Jan 24, 2019 at 05:27:39PM +0200, Markus Ottela wrote: > Hi! > > The traffic here is quite low so I hope it's ok if I post my work: > > TFC (https://github.com/maqp/tfc) is something I've worked on since spring > 2012. The idea was to create a messaging system that splits the TCB on two > airgapped computers that communicate with a networked computer via > unidirectional gateways. To enforce the unidirectional behavior it's using a > simple circuit that for each direction uses an optocoupler as an optical > repeater in the middle of a serial gateway: The photoelectric effect in LEDs > is inefficient, and the photodiodes do not emit light, so the IC only works > in one way. > > This hardware layout prevents remotely inserted malware from entering the > Source Computer (that outputs ciphertexts). It also prevents the malware > from exfiltrating keys/plaintexts from the Destination Computer (that > decrypts incoming messages). The Networked Computer only ever sees > non-sensitive data like ciphertexts and public keys. > > On Networked Computer the relay program runs a v3 Onion Service and web > clients needed to request data from Onion Services of contacts. In this > respect it's similar to Ricochet: There is no server in the middle to tap. > > As for cryptographic primitives, TFC uses single X448 (OpenSSL > implementation) that by default prompts the user to verify base10 > fingerprints. XChaCha20-Poly1305 (libsodium implementation) has per-message > forward secrecy that relies on BLAKE2b hash ratchet. Keys are generated with > GETRANDOM syscall. All sensitive persistent data on endpoints is encrypted > with the same XChaCha, and the key for it is derived from salt and password > using Argon2d. > > Since during key exchange the public key needs to be typed manually into the > Source Computer, DH ratchet and thus future secrecy isn't practical. The > user can of course re-exchange keys whenever they like it. The lack of > future secrecy is compensated by the architecture that prevents key > exfiltration. > > The application is written in Python (3.6), is FOSS, and the HW is Free > Hardware Design (circuit diagrams and step-by-step build instructions are > available). The code has type annotations and I've tried to make good unit > tests for it. > > For metadata protection I tried to make TFC to install anonymously. Onion > Services hide geo-location and identity of the users. I've also added an > optional traffic masking feature that locks Transmitter Program to a > selected contact/group, and sends a continuous stream of noise packets to > those recipients. Files and messages are inserted into the noise stream when > needed. This should hide quantity, schedule, and type of communication even > from an adversary that compromises the Networked Computer of sender / > recipient. > > It's not perfect however. There's a bunch of attack vectors from Source > Computer compromise during install to covert exfiltration channels in > Destination Computer. I've tried to be as thorough as possible about these > risks in the threat model / security design articles, which you can find > from the project's wiki: https://github.com/maqp/tfc/wiki > > Any feedback / criticism is more than welcome! > > Markus > > _______________________________________________ > Messaging mailing list > Messaging at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From holger at merlinux.eu Thu Jan 24 14:10:01 2019 From: holger at merlinux.eu (holger krekel) Date: Thu, 24 Jan 2019 23:10:01 +0100 Subject: [messaging] metadata does not kill (was: Re: TFC - Onion routed messaging with endpoint security) In-Reply-To: <20190124205631.cj43zl2dlik7oi73@computer> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> Message-ID: <20190124221001.GV25650@beto> On Thu, Jan 24, 2019 at 20:56 +0000, dawuud wrote: > I feel totally justified on harping on this one point until we arrive > at a good solution because ex-NSA director, Michael Hayden is famously > quoted as having said: "We kill people based on meta-data". Well, the important part of this sentence is: "We kill people". And the reasoning behind is arbitrary and not as rational as it sounds. An algorithmic AI feeding on perforated, inconsistent massive data heaps, for computing kill markers on device users and then targetting all people around a marked device ... has this anything to do with a fair trial? And how to even precisely separate metadata from content? The pervasive advertisements in Youtube's movies for children -- could they be the actual content of this Google operation? Whereas movies (some think it's the content) with their views, clicks, likes, messages are merely metadata for this logic that targets children, optimizes for value extraction? In any case, you can perfectly hide messages and metadata in plain sight if you share a private context with your communication partner. And not even a godlike algorithmic AI could capture the full meaning of collected plain messages. Maybe mixnets can help to further confuse targetting algos but the idea to use "metadata" to kill people is already pretty confused to begin with. holger -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From hello at lennartoldenburg.de Sat Jan 26 16:20:57 2019 From: hello at lennartoldenburg.de (Lennart Oldenburg) Date: Sun, 27 Jan 2019 01:20:57 +0100 Subject: [messaging] TFC - Onion routed messaging with endpoint security In-Reply-To: <20190124205631.cj43zl2dlik7oi73@computer> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> Message-ID: <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> Hi David, Could you (or the larger group here) point me to the paper that trivially deanonymizes Tor users with timing attacks in a few seconds once conducted by a global adversary? I heard that argument before and am currently trying to find the academic reference it is based on. Thanks a lot in advance! Best Lennart On 24/01/2019 21.56, dawuud wrote: > > Hi Markus, > > It's kinda cool your thorough defense of endpoint security. > Certainly I agree with you that endpoint security is important. > But since we are on a mailing list that is obstensibly about > solving messaging problems I will focus my comments on these issues instead. > > I'd like to point out that the secure messaging problem isn't really solved yet > because there is currently no deployed encrypted messaging applications that provide > traffic analysis resistance against global adversaries. This of course includes Tor > which can trivially be broken in just a few seconds using timing correlation. > And to make a more nuanced point, so called "secure messaging" applications > should be using multiple security domains; currently this is my main criticism > of Signal messenger besides requiring the use of phone numbers. > > I feel totally justified on harping on this one point until we arrive > at a good solution because ex-NSA director, Michael Hayden is famously > quoted as having said: "We kill people based on meta-data". > > Onion services do hide geographical location from adveraries that > are unable to break Tor. But is this really an appropriate threat model? > Do you think colluding nation state adversaries cannot break Tor? > The conclusions of the academic literature on these points are quit clear > and there is over 37 years of published academic literature on the topic > of anonymous messaging. Many of these papers describe systems that > have far stronger threat models than Tor, things like: > > * decryption mix networks > * verified mix shuffles > * private information retrieval > * dining cryptographer networks > * broadcast based designs (with trial decryption) > * oblivious random access memory > * secure multi-party computation > > I don't understand why you decided to use the term "traffic masking". > Isn't this "traffic padding"? > > Without a proper statistical model to assist in tuning it's not clear > how much this will help. I should mention that Tor Project is very > interested in using traffic padding in future versions of Tor and > they wish to encourage academics to explore this possibility. Clearly, > it will take at least one PhD worth of research to establish safety > margins in the use of traffic padding for Tor and I suspect discrete network event > simulators will help with this. > > > Cheers, > David > > On Thu, Jan 24, 2019 at 05:27:39PM +0200, Markus Ottela wrote: >> Hi! >> >> The traffic here is quite low so I hope it's ok if I post my work: >> >> TFC (https://github.com/maqp/tfc) is something I've worked on since spring >> 2012. The idea was to create a messaging system that splits the TCB on two >> airgapped computers that communicate with a networked computer via >> unidirectional gateways. To enforce the unidirectional behavior it's using a >> simple circuit that for each direction uses an optocoupler as an optical >> repeater in the middle of a serial gateway: The photoelectric effect in LEDs >> is inefficient, and the photodiodes do not emit light, so the IC only works >> in one way. >> >> This hardware layout prevents remotely inserted malware from entering the >> Source Computer (that outputs ciphertexts). It also prevents the malware >> from exfiltrating keys/plaintexts from the Destination Computer (that >> decrypts incoming messages). The Networked Computer only ever sees >> non-sensitive data like ciphertexts and public keys. >> >> On Networked Computer the relay program runs a v3 Onion Service and web >> clients needed to request data from Onion Services of contacts. In this >> respect it's similar to Ricochet: There is no server in the middle to tap. >> >> As for cryptographic primitives, TFC uses single X448 (OpenSSL >> implementation) that by default prompts the user to verify base10 >> fingerprints. XChaCha20-Poly1305 (libsodium implementation) has per-message >> forward secrecy that relies on BLAKE2b hash ratchet. Keys are generated with >> GETRANDOM syscall. All sensitive persistent data on endpoints is encrypted >> with the same XChaCha, and the key for it is derived from salt and password >> using Argon2d. >> >> Since during key exchange the public key needs to be typed manually into the >> Source Computer, DH ratchet and thus future secrecy isn't practical. The >> user can of course re-exchange keys whenever they like it. The lack of >> future secrecy is compensated by the architecture that prevents key >> exfiltration. >> >> The application is written in Python (3.6), is FOSS, and the HW is Free >> Hardware Design (circuit diagrams and step-by-step build instructions are >> available). The code has type annotations and I've tried to make good unit >> tests for it. >> >> For metadata protection I tried to make TFC to install anonymously. Onion >> Services hide geo-location and identity of the users. I've also added an >> optional traffic masking feature that locks Transmitter Program to a >> selected contact/group, and sends a continuous stream of noise packets to >> those recipients. Files and messages are inserted into the noise stream when >> needed. This should hide quantity, schedule, and type of communication even >> from an adversary that compromises the Networked Computer of sender / >> recipient. >> >> It's not perfect however. There's a bunch of attack vectors from Source >> Computer compromise during install to covert exfiltration channels in >> Destination Computer. I've tried to be as thorough as possible about these >> risks in the threat model / security design articles, which you can find >> from the project's wiki: https://github.com/maqp/tfc/wiki >> >> Any feedback / criticism is more than welcome! >> >> Markus >> >> _______________________________________________ >> Messaging mailing list >> Messaging at moderncrypto.org >> https://moderncrypto.org/mailman/listinfo/messaging >> >> _______________________________________________ >> Messaging mailing list >> Messaging at moderncrypto.org >> https://moderncrypto.org/mailman/listinfo/messaging From dawuud at riseup.net Sat Jan 26 19:30:10 2019 From: dawuud at riseup.net (dawuud) Date: Sun, 27 Jan 2019 03:30:10 +0000 Subject: [messaging] TFC - Onion routed messaging with endpoint security In-Reply-To: <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> Message-ID: <20190127033010.ml6kcx7jyptqghnu@computer> Hi Lennart, Thanks for publicly posting this question. Below are some papers. Perhaps I have missed something and someone on this list will hopefully decide to be helpful and tell us. Roger of Tor Project wrote a blog post on this topic: https://blog.torproject.org/one-cell-enough-break-tors-anonymity In that post he mentioned several papers: The Traffic Analysis of Continuous-Time Mixes by George Danezis https://www.freehaven.net/anonbib/cache/danezis:pet2004.pdf Approximating a Global Passive Adversary Against Tor by Chakravarty, Sambuddho; Stavrou, Angelos; Keromytis, Angelos D. https://academiccommons.columbia.edu/doi/10.7916/D82J6QBM How Much Anonymity does Network Latency Leak? by NICHOLAS HOPPER EUGENE Y. VASSERMAN ERIC CHAN-TIN https://www.freehaven.net/anonbib/cache/tissec-latency-leak.pdf I continued looking for more papers and found this: Analyzing the Effectiveness of Passive Correlation Attacks on the Tor Anonymity Network by Sam DeFabbia-Kane https://pdfs.semanticscholar.org/17a6/736b5b8d9a2e516adbebb338e3265681b1c9.pdf Sincerely, David On Sun, Jan 27, 2019 at 01:20:57AM +0100, Lennart Oldenburg wrote: > Hi David, > > Could you (or the larger group here) point me to the paper that > trivially deanonymizes Tor users with timing attacks in a few seconds > once conducted by a global adversary? > > I heard that argument before and am currently trying to find the > academic reference it is based on. > > Thanks a lot in advance! > > Best > Lennart > > On 24/01/2019 21.56, dawuud wrote: > > > > Hi Markus, > > > > It's kinda cool your thorough defense of endpoint security. > > Certainly I agree with you that endpoint security is important. > > But since we are on a mailing list that is obstensibly about > > solving messaging problems I will focus my comments on these issues instead. > > > > I'd like to point out that the secure messaging problem isn't really solved yet > > because there is currently no deployed encrypted messaging applications that provide > > traffic analysis resistance against global adversaries. This of course includes Tor > > which can trivially be broken in just a few seconds using timing correlation. > > And to make a more nuanced point, so called "secure messaging" applications > > should be using multiple security domains; currently this is my main criticism > > of Signal messenger besides requiring the use of phone numbers. > > > > I feel totally justified on harping on this one point until we arrive > > at a good solution because ex-NSA director, Michael Hayden is famously > > quoted as having said: "We kill people based on meta-data". > > > > Onion services do hide geographical location from adveraries that > > are unable to break Tor. But is this really an appropriate threat model? > > Do you think colluding nation state adversaries cannot break Tor? > > The conclusions of the academic literature on these points are quit clear > > and there is over 37 years of published academic literature on the topic > > of anonymous messaging. Many of these papers describe systems that > > have far stronger threat models than Tor, things like: > > > > * decryption mix networks > > * verified mix shuffles > > * private information retrieval > > * dining cryptographer networks > > * broadcast based designs (with trial decryption) > > * oblivious random access memory > > * secure multi-party computation > > > > I don't understand why you decided to use the term "traffic masking". > > Isn't this "traffic padding"? > > > > Without a proper statistical model to assist in tuning it's not clear > > how much this will help. I should mention that Tor Project is very > > interested in using traffic padding in future versions of Tor and > > they wish to encourage academics to explore this possibility. Clearly, > > it will take at least one PhD worth of research to establish safety > > margins in the use of traffic padding for Tor and I suspect discrete network event > > simulators will help with this. > > > > > > Cheers, > > David > > > > On Thu, Jan 24, 2019 at 05:27:39PM +0200, Markus Ottela wrote: > >> Hi! > >> > >> The traffic here is quite low so I hope it's ok if I post my work: > >> > >> TFC (https://github.com/maqp/tfc) is something I've worked on since spring > >> 2012. The idea was to create a messaging system that splits the TCB on two > >> airgapped computers that communicate with a networked computer via > >> unidirectional gateways. To enforce the unidirectional behavior it's using a > >> simple circuit that for each direction uses an optocoupler as an optical > >> repeater in the middle of a serial gateway: The photoelectric effect in LEDs > >> is inefficient, and the photodiodes do not emit light, so the IC only works > >> in one way. > >> > >> This hardware layout prevents remotely inserted malware from entering the > >> Source Computer (that outputs ciphertexts). It also prevents the malware > >> from exfiltrating keys/plaintexts from the Destination Computer (that > >> decrypts incoming messages). The Networked Computer only ever sees > >> non-sensitive data like ciphertexts and public keys. > >> > >> On Networked Computer the relay program runs a v3 Onion Service and web > >> clients needed to request data from Onion Services of contacts. In this > >> respect it's similar to Ricochet: There is no server in the middle to tap. > >> > >> As for cryptographic primitives, TFC uses single X448 (OpenSSL > >> implementation) that by default prompts the user to verify base10 > >> fingerprints. XChaCha20-Poly1305 (libsodium implementation) has per-message > >> forward secrecy that relies on BLAKE2b hash ratchet. Keys are generated with > >> GETRANDOM syscall. All sensitive persistent data on endpoints is encrypted > >> with the same XChaCha, and the key for it is derived from salt and password > >> using Argon2d. > >> > >> Since during key exchange the public key needs to be typed manually into the > >> Source Computer, DH ratchet and thus future secrecy isn't practical. The > >> user can of course re-exchange keys whenever they like it. The lack of > >> future secrecy is compensated by the architecture that prevents key > >> exfiltration. > >> > >> The application is written in Python (3.6), is FOSS, and the HW is Free > >> Hardware Design (circuit diagrams and step-by-step build instructions are > >> available). The code has type annotations and I've tried to make good unit > >> tests for it. > >> > >> For metadata protection I tried to make TFC to install anonymously. Onion > >> Services hide geo-location and identity of the users. I've also added an > >> optional traffic masking feature that locks Transmitter Program to a > >> selected contact/group, and sends a continuous stream of noise packets to > >> those recipients. Files and messages are inserted into the noise stream when > >> needed. This should hide quantity, schedule, and type of communication even > >> from an adversary that compromises the Networked Computer of sender / > >> recipient. > >> > >> It's not perfect however. There's a bunch of attack vectors from Source > >> Computer compromise during install to covert exfiltration channels in > >> Destination Computer. I've tried to be as thorough as possible about these > >> risks in the threat model / security design articles, which you can find > >> from the project's wiki: https://github.com/maqp/tfc/wiki > >> > >> Any feedback / criticism is more than welcome! > >> > >> Markus -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From grarpamp at gmail.com Sat Jan 26 23:05:32 2019 From: grarpamp at gmail.com (grarpamp) Date: Sun, 27 Jan 2019 02:05:32 -0500 Subject: [messaging] TFC - Onion routed messaging with endpoint security In-Reply-To: <20190127033010.ml6kcx7jyptqghnu@computer> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> <20190127033010.ml6kcx7jyptqghnu@computer> Message-ID: DeepCorr: Strong Flow Correlation Attacks on Tor Using Deep Learning https://arxiv.org/pdf/1808.07285 Some assert that the only way to beat this class (general timing and traffic analysis) is with full time regulated fill traffic. Then people cry bandwidth... before realizing the selectability of the committed rate is pursuant to their needs, and being no more than they can get, or would use, over non-fill nets anyways. Or with a, unusable for low latency..., random store forward lossy additive mixes... being a non general and gappy form of fill anyway. Are there any papers covering potential schemes for managing traffic fill (negotiation of rates, dynamic yielding to take on wheat presented, hop by hop vs network wide awareness and control mechanisms, dropping nodes that fail to fill per negotiation, etc)? From dawuud at riseup.net Sun Jan 27 01:13:52 2019 From: dawuud at riseup.net (dawuud) Date: Sun, 27 Jan 2019 09:13:52 +0000 Subject: [messaging] TFC - Onion routed messaging with endpoint security In-Reply-To: References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> <20190127033010.ml6kcx7jyptqghnu@computer> Message-ID: <20190127091352.x2ehzvc4psmnnuu2@computer> The recently published anonymity trilemma paper is fascinating, and points out the tradeoff between bandwidth, latency and anonymity; note the very interesting graph at the top of page 16, and that Loopix holds an interesting position on this graph: Anonymity Trilemma: Strong Anonymity, Low Bandwidth Overhead, Low Latency—Choose Two by Debajyoti Das, Sebastian Meiser, Esfandiar Mohammadi, Aniket Kate https://eprint.iacr.org/2017/954.pdf The recent Loopix paper explores this tradeoff in the context of a continuous time mix strategy called the Poisson mix: The Loopix Anonymity System by Ania M. Piotrowska, Jamie Hayes, Tariq Elahi, Sebastian Meiser, George Danezis https://www.esat.kuleuven.be/cosic/publications/article-2830.pdf No need to cry about bandwidth usage if we are willing to sacrifice the low latency and replace it with "medium latency". Instead of using constant time padding or decoy traffic we can instead make use of a Poisson process which samples from an exponential distribution. Loopix clients use a FIFO queue for sending messages where items are removed from the queue and sent based on time intervals from the Poisson process. If queue is empty send decoys. Unsure how well this will work on phones... (especially dubious if they go to sleep) Hopefully in the coming years we will see more research into these tradeoffs and concrete tuning parameters for Loopix and other similar designs. :) Like Holger Krekel said, perhaps mixnets can help. This is our long term plan. For short term solutions of course use Tor! (Tor is very obviously the best currently deployed anonymous communication protocol) ♥λⒶ 😼 enjoy the reads Cheers, David On Sun, Jan 27, 2019 at 02:05:32AM -0500, grarpamp wrote: > DeepCorr: Strong Flow Correlation Attacks on Tor Using Deep Learning > https://arxiv.org/pdf/1808.07285 > > Some assert that the only way to beat this > class (general timing and traffic analysis) is > with full time regulated fill traffic. > Then people cry bandwidth... before realizing the > selectability of the committed rate is pursuant > to their needs, and being no more than they can > get, or would use, over non-fill nets anyways. > Or with a, unusable for low latency..., random store > forward lossy additive mixes... being a non general > and gappy form of fill anyway. > > Are there any papers covering potential schemes for > managing traffic fill (negotiation of rates, dynamic > yielding to take on wheat presented, hop by hop > vs network wide awareness and control mechanisms, > dropping nodes that fail to fill per negotiation, etc)? > _______________________________________________ > Messaging mailing list > Messaging at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hello at lennartoldenburg.de Mon Jan 28 02:02:38 2019 From: hello at lennartoldenburg.de (Lennart Oldenburg) Date: Mon, 28 Jan 2019 11:02:38 +0100 Subject: [messaging] TFC - Onion routed messaging with endpoint security In-Reply-To: <20190127091352.x2ehzvc4psmnnuu2@computer> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> <20190127033010.ml6kcx7jyptqghnu@computer> <20190127091352.x2ehzvc4psmnnuu2@computer> Message-ID: <2f20ab9f-ef93-bc3b-2f9d-067f064cddf1@lennartoldenburg.de> Thanks for all the recommendations everyone! On 27/01/2019 10.13, dawuud wrote: > > The recently published anonymity trilemma paper is fascinating, and > points out the tradeoff between bandwidth, latency and anonymity; note > the very interesting graph at the top of page 16, and that Loopix > holds an interesting position on this graph: > > Anonymity Trilemma: Strong Anonymity, Low > Bandwidth Overhead, Low Latency—Choose Two > by Debajyoti Das, Sebastian Meiser, Esfandiar Mohammadi, Aniket Kate > https://eprint.iacr.org/2017/954.pdf > > > The recent Loopix paper explores this tradeoff in the context of a > continuous time mix strategy called the Poisson mix: > > The Loopix Anonymity System > by Ania M. Piotrowska, Jamie Hayes, Tariq Elahi, Sebastian Meiser, George Danezis > https://www.esat.kuleuven.be/cosic/publications/article-2830.pdf > > No need to cry about bandwidth usage if we are willing to sacrifice > the low latency and replace it with "medium latency". Instead of using > constant time padding or decoy traffic we can instead make use of a Poisson > process which samples from an exponential distribution. Loopix clients use a > FIFO queue for sending messages where items are removed from the queue and sent > based on time intervals from the Poisson process. If queue is empty send decoys. > > Unsure how well this will work on phones... (especially dubious if they go to sleep) > Hopefully in the coming years we will see more research into these tradeoffs > and concrete tuning parameters for Loopix and other similar designs. :) > > Like Holger Krekel said, perhaps mixnets can help. This is our long term plan. > For short term solutions of course use Tor! (Tor is very obviously the best currently deployed anonymous communication protocol) > > ♥λⒶ 😼 enjoy the reads > > Cheers, > David > > > On Sun, Jan 27, 2019 at 02:05:32AM -0500, grarpamp wrote: >> DeepCorr: Strong Flow Correlation Attacks on Tor Using Deep Learning >> https://arxiv.org/pdf/1808.07285 >> >> Some assert that the only way to beat this >> class (general timing and traffic analysis) is >> with full time regulated fill traffic. >> Then people cry bandwidth... before realizing the >> selectability of the committed rate is pursuant >> to their needs, and being no more than they can >> get, or would use, over non-fill nets anyways. >> Or with a, unusable for low latency..., random store >> forward lossy additive mixes... being a non general >> and gappy form of fill anyway. >> >> Are there any papers covering potential schemes for >> managing traffic fill (negotiation of rates, dynamic >> yielding to take on wheat presented, hop by hop >> vs network wide awareness and control mechanisms, >> dropping nodes that fail to fill per negotiation, etc)? >> _______________________________________________ >> Messaging mailing list >> Messaging at moderncrypto.org >> https://moderncrypto.org/mailman/listinfo/messaging > > _______________________________________________ > Messaging mailing list > Messaging at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging From torfone at ukr.net Sun Mar 3 23:40:26 2019 From: torfone at ukr.net (Van Gegel) Date: Mon, 04 Mar 2019 09:40:26 +0200 Subject: [messaging] tDH extended with SPEKE In-Reply-To: <2f20ab9f-ef93-bc3b-2f9d-067f064cddf1@lennartoldenburg.de> References: <8024e946-4810-9cd8-887f-612a45a86fa8@cs.helsinki.fi> <20190124205631.cj43zl2dlik7oi73@computer> <375c6c48-a2f7-6585-abff-cffb0e148d3b@lennartoldenburg.de> <20190127033010.ml6kcx7jyptqghnu@computer> <20190127091352.x2ehzvc4psmnnuu2@computer> <2f20ab9f-ef93-bc3b-2f9d-067f064cddf1@lennartoldenburg.de> Message-ID: <1551684751.416548214.j1nzwvjf@frv53.fwdcdn.com> Hello all! Recently I chose the Initial Key Exchange procedure for my project and compare the properties of known protocols. I found that tDH has certain minor flaws that can be fixed.   The one flaw is the weak PFS of sender’s ID protection: Eve intercepts Alice’s connection to Bob and claims as Bob. She follows the tDH protocol, receives the authenticator and aborts. Later, by revealing Bob’s private key, Eve can check Alice participation in this past session.   Many other protocols also inherit this flaw. For example, see the Noise Structure Document: http://www.noiseprotocol.org/noise.html chapter 7.8. “Personality hiding” Authors are going to use signatures in the future. But to use signatures we need the full format of the points (both x and y coordinates or at least a sign of y), which is incompatible with X25519 Montgomery format.   There is an elegant way to fix this flaw by extending tDH using the SPEKE protocol performed in parallel. SPEKE will only require a Hash2Point implementation based on Elligator2. This is easy to implement with elementary field math of X25519. Alice is originator and connect to Bob. SPEKE base point is derived from the value B * x == X * b where x is ephemeral key of Alice.  Both sides compute SPEKE public keys using random ephemeral private keys independent of DH ephemeral private keys (x and y). The parties exchange DH and SPEKE keys simultaneously. SPEKE shared secret can be used to explicitly protect the sender's ID  and is also included into  tDH hash (there will now be four elements) to provide PFS of implicit ID protecting.   SPEKE has only recently become free so perhaps other effective combinations can be used to develop protocols with good properties. Can in be applied in practice? Best regards, Van Gegel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grarpamp at gmail.com Mon Mar 11 01:02:33 2019 From: grarpamp at gmail.com (grarpamp) Date: Mon, 11 Mar 2019 04:02:33 -0400 Subject: [messaging] Cryptocurrency Mixnets Strong Privacy Quantum Blockchains In-Reply-To: References: Message-ID: > wrote: > https://www.technologyreview.com/s/608041/first-quantum-secured-blockchain-technology-tested-in-moscow/ Moscow has not been friendly towards non-Fiat cryptocurrency. The actual paper... Quantum-secured blockchain - Kiktenko https://arxiv.org/abs/1705.09258 And the only cryptocurrencies people should trust will be the Distributed P2P Transaction Mineable AnonPriv Cryptocurrencies, aka not Fiat, else there's no point, just use GovCoin, BankCoin, or CorpCoin, they're all the same... ShitCoin. > This technology, if it exists, which I doubt, secures the channels > through which crypto coins are sent Considering end users won't be able to buy the quantum hardware, optical links, etc needed for the QKD anytime soon... privacy coins over Mix Darknets WiFi are for now at least reasonable channel security for some use cases. This paper blurbs Zcash and Loopix ... Extending the Anonymity of Zcash - Kappos, Piotrowska https://arxiv.org/abs/1902.07337 And note that software PQC for all the parts... secure keying, algos, passphrases, blockchain bits, etc, is also rolling.. https://en.wikipedia.org/wiki/Post-quantum_cryptography https://pqcrypto.org/ https://csrc.nist.gov/Projects/Post-Quantum-Cryptography infohash:B07C61F8452F23B9D9936551D1A6DE7CF61FDD9F infohash:3233EBD08587C5E8B806B2B5375BF4975E8A2519 > Which messages are then added to the blockchain in the clear, for > everyone to see, forever. Which means it's no better than Fiat, thus pointless. At last survey long ago, afaik only the Zero Knowledge Proof ZKP family of coins, Zcash.io ZEC, Zencash ZEN, Zclassic ZCL, etc, had actually put the entire transaction behind strong cryptography... senders, receivers, amounts, change, etc. Monero XMR, the CoinJoin family, etc, are all doing other approaches. And there's no real reason to hold anything other than the UTXO database set. Lots of projects are working on distributed consensus state machines now... https://blog.acolyer.org/2019/03/08/a-generalised-solution-to-distributed-consensus/ https://news.ycombinator.com/item?id=19343398 With luck everything in cryptocurrency will be far more advanced, anon / private, scalable, and adopted by 2029. Someone really should maintain a list of cryptocurrency projects that are seriously working on these topics instead of being just another ICO, token, centralized censorable spyable Fiat, etc. From dawuud at riseup.net Mon Mar 11 13:24:19 2019 From: dawuud at riseup.net (dawuud) Date: Mon, 11 Mar 2019 20:24:19 +0000 Subject: [messaging] Cryptocurrency Mixnets Strong Privacy Quantum Blockchains In-Reply-To: References: Message-ID: <20190311202419.32zzkseyo46rmlcd@computer> > Extending the Anonymity of Zcash - Kappos, Piotrowska > https://arxiv.org/abs/1902.07337 Cool! Btw Ania Priotrowska is also the main author of the Loopix paper and one of the minds behind the Katzenpost design. Cheers, David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bidabahia at gmail.com Thu Mar 28 06:47:44 2019 From: bidabahia at gmail.com (B Da Bahia) Date: Thu, 28 Mar 2019 13:47:44 +0000 Subject: [messaging] Two-party consensual file access Message-ID: Hello list, I'm looking for a cryptographic algorithm to solve the following problem: Alice and Bob (untrusting partners) want to cooperate to open an encrypted file located at either one's computer. No party should be able to open it without the other party's consent. No trusted third parties are allowed to intervene in the protocol. Could anyone provide useful references to explore? thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at links.org Thu Mar 28 15:36:42 2019 From: ben at links.org (Ben Laurie) Date: Thu, 28 Mar 2019 22:36:42 +0000 Subject: [messaging] Two-party consensual file access In-Reply-To: References: Message-ID: Who encrypted this file? On Thu, 28 Mar 2019 at 13:48, B Da Bahia wrote: > Hello list, > I'm looking for a cryptographic algorithm to solve the following problem: > Alice and Bob (untrusting partners) want to cooperate to open an encrypted > file located at either one's computer. No party should be able to open it > without the other party's consent. No trusted third parties are allowed to > intervene in the protocol. > Could anyone provide useful references to explore? > thanks in advance! > > _______________________________________________ > Messaging mailing list > Messaging at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidwong.crypto at gmail.com Thu Mar 28 17:26:25 2019 From: davidwong.crypto at gmail.com (david wong) Date: Thu, 28 Mar 2019 17:26:25 -0700 Subject: [messaging] Two-party consensual file access In-Reply-To: References: Message-ID: <4D8ABFD0-A4A1-4E70-8710-57F92B2A9D09@gmail.com> Shamir sharing scheme to split the key in two. Send your half to the other one to let them decrypt it. David Sent from my iPhone > On Mar 28, 2019, at 3:36 PM, Ben Laurie wrote: > > Who encrypted this file? > >> On Thu, 28 Mar 2019 at 13:48, B Da Bahia wrote: >> Hello list, >> I'm looking for a cryptographic algorithm to solve the following problem: >> Alice and Bob (untrusting partners) want to cooperate to open an encrypted file located at either one's computer. No party should be able to open it without the other party's consent. No trusted third parties are allowed to intervene in the protocol. >> Could anyone provide useful references to explore? >> thanks in advance! >> >> _______________________________________________ >> Messaging mailing list >> Messaging at moderncrypto.org >> https://moderncrypto.org/mailman/listinfo/messaging > _______________________________________________ > Messaging mailing list > Messaging at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging -------------- next part -------------- An HTML attachment was scrubbed... URL: From max at skibinsky.com Thu Mar 28 20:28:41 2019 From: max at skibinsky.com (Max Skibinsky) Date: Thu, 28 Mar 2019 20:28:41 -0700 Subject: [messaging] Two-party consensual file access In-Reply-To: <4D8ABFD0-A4A1-4E70-8710-57F92B2A9D09@gmail.com> References: <4D8ABFD0-A4A1-4E70-8710-57F92B2A9D09@gmail.com> Message-ID: As Ben mentioned, who encrypts the file is crucial differentiator. Either you can accept one party knows contents of the file beforehand, or you need to solve quite different challenge first — how file content is created in the encrypted form without either party ever having full plaintext. If it is acceptable that one party does encryption as the first step, then indeed *n/n* Shamir schema is the way to go. We did a lot of thinking how an application for Shamir split/storage/restore of high-value files should work, you can take a look at our whitepaper , section 4 outlines some practical storage scenarios. - Max blog | linkedin On Thu, Mar 28, 2019 at 5:26 PM david wong wrote: > Shamir sharing scheme to split the key in two. Send your half to the other > one to let them decrypt it. > > On Mar 28, 2019, at 3:36 PM, Ben Laurie wrote: > > Who encrypted this file? > > On Thu, 28 Mar 2019 at 13:48, B Da Bahia wrote: > >> Hello list, >> I'm looking for a cryptographic algorithm to solve the following problem: >> Alice and Bob (untrusting partners) want to cooperate to open an >> encrypted file located at either one's computer. No party should be able to >> open it without the other party's consent. No trusted third parties are >> allowed to intervene in the protocol. >> Could anyone provide useful references to explore? >> thanks in advance! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iang at cs.uwaterloo.ca Fri Mar 29 10:27:45 2019 From: iang at cs.uwaterloo.ca (Ian Goldberg) Date: Fri, 29 Mar 2019 13:27:45 -0400 Subject: [messaging] Two-party consensual file access In-Reply-To: References: <4D8ABFD0-A4A1-4E70-8710-57F92B2A9D09@gmail.com> Message-ID: <20190329172745.GN31115@cs.uwaterloo.ca> On Thu, Mar 28, 2019 at 08:28:41PM -0700, Max Skibinsky wrote: > As Ben mentioned, who encrypts the file is crucial differentiator. Either > you can accept one party knows contents of the file beforehand, or you need > to solve quite different challenge first — how file content is created in > the encrypted form without either party ever having full plaintext. > > If it is acceptable that one party does encryption as the first step, then > indeed *n/n* Shamir schema is the way to go. We did a lot of thinking how > an application for Shamir split/storage/restore of high-value files should > work, you can take a look at our whitepaper > , section 4 outlines some practical > storage scenarios. Why would you use Shamir for an "n/n" situation? You can use much simpler schemes if you don't need the flexibiliy and robustness of Shamir. In this particular case, you can even just do "encrypt the file with Alice's public key, and then that ciphertext (at least the part encrypting the underlying symmetric key) with Bob's public key", assuming the two parties allowed to decrypt are known at encryption time. Also unstated is whether it's important that, say, Alice be able to prove she performed her stage of the decryption successfully. That can also be pretty straighforward with ZKPs if the public-key encryption is something ElGamal based or similar. - Ian From bidabahia at gmail.com Fri Mar 29 11:15:11 2019 From: bidabahia at gmail.com (B Da Bahia) Date: Fri, 29 Mar 2019 18:15:11 +0000 Subject: [messaging] Two-party consensual file access In-Reply-To: <20190329172745.GN31115@cs.uwaterloo.ca> References: <4D8ABFD0-A4A1-4E70-8710-57F92B2A9D09@gmail.com> <20190329172745.GN31115@cs.uwaterloo.ca> Message-ID: Thank you Ian and others. And apologies for the understatement of the problem. Let me try one more time. The whole idea is to allow consensual creation and reproduction of confidential content. Both Alice and Bob could create content involving both of them (contracts, videos, collaborating editions, etc) in either one's computing device, for which none of them has privileged (root) access. Trusted software runs on both devices. Content is generated in say, Alice's device once Bob has granted his consent for that. Right after content creation, it should be immediately encrypted and stored that way and replicated on both devices, controlled by the trusted software. If later on, any of them wants to open that content, he/she would have to request for the other party's consent again. And in that situation, through some secret sharing technique, reproduction would occur for a limited time on the petitioner's device under the control of the trusted software. While file is open/reproduced, no on-device recording mechanisms is allowed. I've thought about a relatively simple (and most probably awful) solution. Both parties have their pair of Pub & Priv keys created and managed by the trusted software on each device. Trusted software maintains a database of file metadata (with both parties pub keys, and a nonce randomly assigned to every new file's entry) replicated on both devices. Alice and Bob generate their subkeys for symmetric de/encryption by digitally signing each file's metadata. Encryption/Decryption keys are merely the concatenation of both parties subkeys. Consent request includes digitally signing part of file's metadata, and the action verb (create, open, export, etc). Consent reply includes digitally signing the file's metadata. I'm sure this is horrible and that's why I requested for some pointers from people with more experience than me. Thanks! On Fri, Mar 29, 2019 at 5:27 PM Ian Goldberg wrote: > On Thu, Mar 28, 2019 at 08:28:41PM -0700, Max Skibinsky wrote: > > As Ben mentioned, who encrypts the file is crucial differentiator. Either > > you can accept one party knows contents of the file beforehand, or you > need > > to solve quite different challenge first — how file content is created in > > the encrypted form without either party ever having full plaintext. > > > > If it is acceptable that one party does encryption as the first step, > then > > indeed *n/n* Shamir schema is the way to go. We did a lot of thinking how > > an application for Shamir split/storage/restore of high-value files > should > > work, you can take a look at our whitepaper > > , section 4 outlines some practical > > storage scenarios. > > Why would you use Shamir for an "n/n" situation? You can use much > simpler schemes if you don't need the flexibiliy and robustness of > Shamir. In this particular case, you can even just do "encrypt the file > with Alice's public key, and then that ciphertext (at least the part > encrypting the underlying symmetric key) with Bob's public key", > assuming the two parties allowed to decrypt are known at encryption > time. > > Also unstated is whether it's important that, say, Alice be able to > prove she performed her stage of the decryption successfully. That can > also be pretty straighforward with ZKPs if the public-key encryption is > something ElGamal based or similar. > > - Ian > _______________________________________________ > Messaging mailing list > Messaging at moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grarpamp at gmail.com Mon Apr 1 19:45:59 2019 From: grarpamp at gmail.com (grarpamp) Date: Mon, 1 Apr 2019 22:45:59 -0400 Subject: [messaging] Loki.network, Crypto Network HW Links, Anti Vampire and Sybil Nets, Actors Everywhere Message-ID: > I am personally convinced that a flat traffic shape will only dare > attackers to cut links between parts of the network, effectively > making an even larger traffic shape to corrilate with. Today if play the cut links game, eventually a toggled link will expose the traffic you seek, because there's no fill between nodes that automatically takes its place. Your global monitor sees a respective signal slump among the nodes making up the subject path, each node distinguishable by time deltas. Such signal the adversary was probably clocking into it themselves for easier recognition anyway... fetch 1MB, fetch 1MB, fetch 1MB, fetch 1MB... oh noes. Tor's hidden services are total sitting ducks because of this. Same for likely all current overlay networks in production regardless of whatever service they provide... from traffic, messaging, storage, cryptocurrency, and so on. There are surely better links from the bib space, yet here are some concepts on generated buckets, retiming, how they can contain full time "empty" fill that yields to wheat demand on the line, traffic contracts, etc therein... https://en.wikipedia.org/wiki/Generic_cell_rate_algorithm If all the nodes are independantly maintaining independant traffic contracts between their physical and/or logical peers, cut links won't do hardly as much impact if anything at all... A \ B + -----> M -----> { U V W X Y Z } C + D / If nodes ABCD on the left are trafficing through M cloud fanning out to the right mesh towards UVWXYZ, then adversary cutout of D is not visible beyond M if M makes up for D's packet slack on its left contract by continuing to emit the same amount as fill to fulfill its right contract. M could variously blackball A for non contractual suspect misbehaviour... weird rates, timing anomalies, uptimes, etc. M could signal BC that they can now renegotiate upwards with M since M now has more rate free on its left. If M is cut out, the left renegotiates with some L or N nodes via new northern or southern arc routes. The "shape" or "bitrate" of the contracts could be negotiated as need be, "flat" might not be necessary, so long as the contract is upheld and policed by all participants to it. Contracts could be one to one, one to many, many to many, physical next IP hop to hop, logical overlay address to address, multiplex, simplex, tunneled, shared, etc. And pertain to bitrates, timing, uptime, any sort of constraints, metadata, etc. This also makes Sybil's life more difficult... it must now own the full path or it will lose sight due to contracts with non Sybil nodes in the path who are also meshed and contracted out to other non Sybils around ot. Sybil must also uphold all its own contracts or get dropped by other nodes. > I am not convinced low latency systems can be immune to traffic shape > corrilation and hence that being said Copper, Fiber, Radio, etc.. so long as it's quality line rate hardware that can keep up with its advertised rate, their time to transfer data is dependant only on distance, not on how full the line is. Such network hardware is agnostic... fill, wheat... it all gets there in the same time. When people say "X latency network overlay", they're really referring to the cost of software processing their overlay design on their crappy stack of PC / Phone CPU hardware. And in their transport protocols running on the same... TCP, UDP, etc... all the way down the stack until it hits the real network hardware, which will either happily accept and ship the packet, or drop it. When people cry about "bandwidth", all they need to do in a fill model is allocate whatever bitrate to it they like and forget it. They're not going to get more bitrate from their ISP than they paid for, and they'll probably contract to the overlay under that so they can do other things with their line. And they're not going to get more wheat bytes across the overlay than a 100% wheat ratio (fill yields to wheat demand) within their contract to the overlay, even if they do disconnect from their byte transfer based ISP / Phone afterwards. Research would need done into routing models needed to transit traffic across the overlay. ie: TCP can readily jam more yet slower circuits through a full pipe, UDP mix gets dropped routed or reserved for. Raw IP becomes interesting. As a network HW project for defense in depth... If hardware makers would add line rate encryption and fill silicon to every physical port on every switch, router, and NIC... mandatory on by default per physical link... that would kill off a lot of vampires. An open IETF RFC spec for that would cost under $1 per port to integrate into existing silicon port fab worldwide, plus electricity to drive the port which would be estimated as part of the RFC process. Modular agility would not cost much more at scale. Assuming line rate hardware, there's no latency impact here either. > I think state actors are out > of scope of the current threat model of llarp. If any network application involves free speech, politics, money aka cryptocurrency, business, journalism, industry, messaging, personal affairs, data storage and transfer, basically anything at all... you can be absolutely certain that many State and Other Actors have a serious continuum of interest in it. Is it the responsibility of each application to develop their own solutions to the threat? No... probably not when many such apps ride on, aggregate muddily over, and depend on networks. All apps can contribute to the development of a diversity sound number of strongly resistant networks that they can then utilize and endorse as they would their own. Be they overlays on top of the internet, enhancements to the internet, or new guerrilla physical plant... That process of people contributing to original and ongoing development of new strong networks that are not susceptible to such Basic Bitch Adversaries as Global Vampires, is something more should consider. Same for likely figuring out how to get the deployment Social aspects right so you can circle the network wagons against Sybil. > This may or may not change. Pity the fool who changes even one satoshi based on the worthless drivel herein :) From grarpamp at gmail.com Tue Apr 2 15:19:29 2019 From: grarpamp at gmail.com (grarpamp) Date: Tue, 2 Apr 2019 18:19:29 -0400 Subject: [messaging] Crypto Network HW Links, Anti Vampire and Sybil Nets, Actors Everywhere Message-ID: > If the state is out to get you I'd just assume that everything arround you > is rooted and a wire tap and act accordingly. Doesn't have to be anyone doing anything wrong. Anyone following geopolitics knows that surveillors can reap just aggregate spying and turn that into realtime influence messaging to their own purpose. "Looks like a lot of overlay users are visiting a node known for artwork. Let's craft on that." "Cryptocurrency rising... Let's craft that." "Here's todays daily statistical and Markov report... Craft it." > assume that everything arround you is rooted and a wire tap Is this not entirely possible for all users of technology around the globe today? Snowden and everyone else before and since told you that you're all being tapped, datamined, controlled, and used. But most still don't believe it, or do anything to directly end it, all you do is drop some tools, while leaving all the taps, entities, activities, policies, still in place. Oops. Recall that you have all still started up exactly ZERO projects that are combining all these elements... #OpenFabs , #OpenHW , #OpenSW , #OpenDev , #OpenBiz , #OpenAudits , etc So you still clearly have zero knowledge of what's actually in your CPU's, your NIC's, your storage, your networks, or any reason to explicitly trust them. You're all April's Fools still stupidly placing faith in secrets [1] even after endless stream of their lies exposed by exploits, be they cataloged by CVE or even network TV news. [1] Be they commercial, [geo]political, etc. >> Be they overlays on top of the internet, >> enhancements to the internet, >> or new guerrilla physical plant... >> >> That process of people contributing to >> original and ongoing development of new >> strong networks that are not susceptible to such >> Basic Bitch Adversaries as Global Vampires, >> is something more should consider. > Indeed, we'll get there eventually. > I am just a guy that made a thing because I thought it was cool. Yes. Hopefully more will see the need to make cool and different things that can all be competed, evaluated, merged together, and even happily and graciously abandoned and joined up for the next where needed, in order to help get everyone there. This applies outside the Tubes as well. >> Same for likely figuring out how to get >> the deployment Social aspects right so >> you can circle the network wagons against Sybil. > Let the record show that I am not the one making the sybil resistance claims > it's the coin team that is. I doubt them as well but I am open to being > surprised. I orignally had another model in mind for mitigating bad actors > on the network that I still plan on implementing (eventually) > Effectively it's a f2f mesh connectivity layer to help hide traffic shape. There's certainly no lack of pure f2f, or p2p dht, or central, or hybrid tools out there in history. Models, threats, and use cases all being tested and mashed together is good, and fun to do :) Sybil is extremely hard to protect against and root out, since all Sybil needs is Money, and an Excuse to be there. As noted in tor lists since years, the solution to Sybil might not be as complete with only "in network" methods. It will more likely require at least some in real life Web of Trust, Humans asserting over the nodes they run, the software analysing that web, making node selections based on that metadata. "I know her, she works at the store, he's at my meetup group, they're a local company, etc...", and so on, a mesh of persons to persons, running nodes and fiber, all around the planet. You're probably going to need to force Sybil to become a verifiable IRL Human Being... because right now all she needs is money, and her bags are full of it. In a 1 million node network, if half of the nodes are from WoT verified humans, each human runs 10 nodes, and only 50% the users prefer to make exclusive use of the WoT... that's 25k unique logical nodes now showing themselves as being more than just a completely anonymous potentially adversarial [point] source of money renting out boxes around the globe. Can 2.5% of the nodes making up any of todays transport, cryptocurrency, or application network overlays be said to be sufficiently trusted? Do any even need to be? In addition to signing human WoT data in the network layers, you could also start pushing analysis of node metadata into subscribable routing metrics... where are the nodes located, OS, uptime patterns, spec conformance, degrees of WoT such as non IRL nyms, and how strong each asserters verification and assertion policy framework is, etc. All of this and more could raise Sybil's cost and exposure risk qute significantly, perhaps to futility. Everytime the Sybil WoT subject hits the lists it's met with abject silence [or "Johnny can't..."] Is this due to fear of associating with a node (or trying to protect the node by not associating) such that if the node is taken down the operator can walk away or redeploy anon elsewhere? Is that not what Zero Knowledge is for, to allow everyone immunity to say "It's just bits, we have no knowledge or control"? Are advancements toward solving Vampire and Sybil really thought that horrifically "unusable" and "costly"? Or that some won't find them perfectly acceptable? Are the elevated levels of technical, philosophical, educational, and operational participation potentially required all nodes and any solutions thought to be impossible to achieve? Is it easier to just skate by on the odds and continue throwing the victims under the bridge as acceptable losses? > I am not arrogant enough to claim to be able to repell state actors from > sqaure one. Not meaning to have refer to Loki, or any project, but to all nets... We know that, other than routine protocol, code, and human exploits (those three all still being quite sufficient at times), adversaries remaining credible tools against Overlay Networks themselves seem to be Vampire and Sybil. And fake Law, no? It's not only State Actors... any global, regional, or even local tier-n ISP can be an adversary partner Vampire... all you need is to be, or have access to, some pipes... and a willingness to be, or be friendly to, some power, or to wish to gain from your own Vamping. And any NGO or person can be a Sybil... all that takes is money, and in many cases, amusingly little. When head down in code and ops, a bit of talk on the metas is good now and then. Mine should of course be disregarded entirely. From christian.t.weissmann at campus.tu-berlin.de Thu Aug 29 07:17:13 2019 From: christian.t.weissmann at campus.tu-berlin.de (=?utf-8?B?V2Vpw59tYW5uLCBDaHJpc3RpYW4gVGplcms=?=) Date: Thu, 29 Aug 2019 14:17:13 +0000 Subject: [messaging] Private key backup on-boarding prototype survey Message-ID: <92B3225D-B7D0-4EB5-A219-B87FF9CED3EA@campus.tu-berlin.de> Hi PGP community, My name is Chris and I am currently writing my master's thesis at the TU Berlin in co-operation with the FU Berlin. My goal is to research how to remove hurdles that discourage people from using PGP to encrypt their email. Currently I am looking into introducing a secret sharing scheme that helps with secure distributed backups of the private key. If you don’t know what secret sharing is, no worries, that’s what I am trying to explain. Therefore I created a small on-boarding prototype for this feature that I would love your feedback on. Below the prototype you can see the link to the survey which has around 10 mostly multiple-choice questions about the topic and some demographics at the end. Of course the input is anonymized and used only within my research purpose. For the start I would implement the feature in the PGP supporting email client which is being developed by the Freie Universität Berlin. In case you are interested in what this idea develops into, there is the option to add your email to a list that I will update about my findings at the end of the project. To find the prototype click the following link: https://letterbox-app.org/survey/backup/ Best regards, Christian Weißmann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From max at skibinsky.com Sat Sep 7 14:23:12 2019 From: max at skibinsky.com (Max Skibinsky) Date: Sat, 7 Sep 2019 14:23:12 -0700 Subject: [messaging] Private key backup on-boarding prototype survey In-Reply-To: <92B3225D-B7D0-4EB5-A219-B87FF9CED3EA@campus.tu-berlin.de> References: <92B3225D-B7D0-4EB5-A219-B87FF9CED3EA@campus.tu-berlin.de> Message-ID: > My goal is to research how to remove hurdles that discourage people from using PGP to encrypt their email. > Currently I am looking into introducing a secret sharing scheme that helps with secure distributed backups of the private key. If you Hi Chris, just noticed this. We are working on general (not PGP-specific) commercial app [1,2] that splits any keys/files/photos into Shamir's shards and monitors the health of distributed shard backup stored on friends & family mobile devices. Based on your description, sounds like our app will just work out of the box for you: drop PGP key (or any valuable key) into the app or take a pic of backup QR and then we take care of everything else, including the disaster recovery when your original phone is destroyed. - Max [1] https://apps.apple.com/app/vault12-crypto-security/id1451596986 [2] https://play.google.com/store/apps/details?id=com.vault12.vault12 From me at rhapsodhy.hu Sun Dec 1 13:44:50 2019 From: me at rhapsodhy.hu (Peter Parkanyi) Date: Sun, 1 Dec 2019 21:44:50 +0000 Subject: [messaging] Zero-metadata object store Message-ID: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> Hi, My project is not strictly messaging-related, but I think this is still the most fitting forum. For the past few months I have been working on the design and implementation for an object store that hides as much metadata as practical, while keeping it fast. Zerostash stores all data in 4MiB blobs that look random from the outside. I use Argon2 and libsodium’s key derivation APIs to make all of this addressable through a user password, and lz4 inside ChaCha-Poly for encrypting the blobs. The code is very PoC quality, but I’ve focused on giving a performant implementation over cleanliness for now. On a MacBook Pro, I can achieve write speeds of ~300MiB/s, and unpack at around 400MiB/s for a large number of small files. At the moment single file is bound to a single thread, so you will not be blown away by performance on large files. I’ve uploaded the specification and code to https://github.com/rsdy/zerostash, and would be grateful for some feedback. Cheers, Peter From mb at 3nsoft.com Sun Dec 1 15:54:13 2019 From: mb at 3nsoft.com (Mikalai Birukou) Date: Sun, 1 Dec 2019 18:54:13 -0500 Subject: [messaging] Zero-metadata object store In-Reply-To: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> References: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> Message-ID: <5d1666bd-1fde-0627-3b57-b86035fed16d@3nsoft.com> > My project is not strictly messaging-related, but I think this is still the most fitting forum. Your gut feeling is right, this is an appropriate place. Secure messaging starts from users using some key material. As a modern user I have several devices. I want my stuff to be synced, and I should be able to loose my devices. End-to-end encrypted storage that is safe to sync to some server is immensely useful for keeping these key material. > Zerostash stores all data in 4MiB blobs that look random from the outside. I use Argon2 and libsodium’s key derivation APIs to make all of this addressable through a user password, and lz4 inside ChaCha-Poly for encrypting the blobs. Do metadata objects contain file tree information? Is file tree continuously packed into mobjects, i.e. many folders' data is placed into every mobject? Or, is it a one mobject per folder structure? Suppose that I sync objects onto server. Suppose also that one of the files there is big, like GBs BIG. What will happen if I change some 100 bytes in the middle? What objects change? Are there new objects create? What should be send to server for sync? Is it correct that for reading a small section of a multi-GB file, I'll have to download from server and to decrypt all 4MB of some dobject? > I’ve uploaded the specification and code to https://github.com/rsdy/zerostash, and would be grateful for some feedback. Is it possible to give object ids and some keys as a way of sharing only part of the file tree, without giving out key material for other parts of the tree? Cause https://github.com/rsdy/zerostash#key-management reads like there's one data key (derived subkey). Quote from https://github.com/rsdy/zerostash#data-objects """The key to encrypt each chunk is Blake2s(plaintext) XOR Argon2(user key)""" Is it a plaintext of content? When decrypting, I don't know content, hence, key must be in some mobject. Why can't it be a randomly generated key, stored in mobject, providing the same claimed feature: """therefore compromising a user key in itself does not necessarily result in full data compromise without access to indexing metadata.""' How are nonces generated? Cheers. From me at rhapsodhy.hu Sun Dec 1 16:44:47 2019 From: me at rhapsodhy.hu (Peter Parkanyi) Date: Mon, 2 Dec 2019 00:44:47 +0000 Subject: [messaging] Zero-metadata object store In-Reply-To: <5d1666bd-1fde-0627-3b57-b86035fed16d@3nsoft.com> References: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> <5d1666bd-1fde-0627-3b57-b86035fed16d@3nsoft.com> Message-ID: <3BF426A0-731F-47D5-9323-CAFF6D0D9970@rhapsodhy.hu> Hi Mikalai, > Do metadata objects contain file tree information? > > Is file tree continuously packed into mobjects, i.e. many folders' data is placed into every mobject? Or, is it a one mobject per folder structure? > File system information and keying information are in mobjects, and they are continuously packed. The aim is to sync the repo index independently from any other content using as little bandwidth as possible. > Suppose that I sync objects onto server. Suppose also that one of the files there is big, like GBs BIG. What will happen if I change some 100 bytes in the middle? What objects change? Are there new objects create? What should be send to server for sync? There’s a rolling hash that creates smaller chunks from a large file. This means that a 100 byte change would realistically change the flow of chunks from that point onwards until the hash syncs up again. A new object is made with the new chunks, and the file metadata is changed. Mobjects are easy to rewrite, and version control is also easy to add because the object format is flexible. > > Is it correct that for reading a small section of a multi-GB file, I'll have to download from server and to decrypt all 4MB of some dobject? Data objects are encrypted chunk-by-chunk with a different key, so you could e.g. create a server that supports HTTP range requests to serve only the part of a dobject that’s referenced by the index. > >> I’ve uploaded the specification and code to https://github.com/rsdy/zerostash, and would be grateful for some feedback. > > Is it possible to give object ids and some keys as a way of sharing only part of the file tree, without giving out key material for other parts of the tree? Cause https://github.com/rsdy/zerostash#key-management reads like there's one data key (derived subkey). The data key changes from chunk to chunk, so you could create an index that only lists the relevant chunks and share only that with someone else. That would leak the data key, but will not make any other data accessible in the stash without relevant metadata. > > Quote from https://github.com/rsdy/zerostash#data-objects """The key to encrypt each chunk is Blake2s(plaintext) XOR Argon2(user key)""" Is it a plaintext of content? When decrypting, I don't know content, hence, key must be in some mobject. Why can't it be a randomly generated key, stored in mobject, providing the same claimed feature: """therefore compromising a user key in itself does not necessarily result in full data compromise without access to indexing metadata.""' It could be, at the cost of metadata size and performance. I am looking into solutions to this, but for single-user cross-device syncing I didn’t consider this a big issue. > > How are nonces generated? Chunk nonces are `objectid XOR chunk size`, where chunk size is 4 bytes in little endian. Meta object nonces are the lower 12 bytes of the object id. Peter From mb at 3nsoft.com Sun Dec 1 16:55:58 2019 From: mb at 3nsoft.com (Mikalai Birukou) Date: Sun, 1 Dec 2019 19:55:58 -0500 Subject: [messaging] Zero-metadata object store In-Reply-To: <90CA4629-53A4-413D-8E57-83A416B20E17@parkanyi.eu> References: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> <5d1666bd-1fde-0627-3b57-b86035fed16d@3nsoft.com> <90CA4629-53A4-413D-8E57-83A416B20E17@parkanyi.eu> Message-ID: <9fa2ba40-5d51-eada-034f-75d8a0afed3e@3nsoft.com> >> How are nonces generated? > Chunk nonces are `objectid XOR chunk size`, where chunk size is 4 bytes in little endian. Meta object nonces are the lower 12 bytes of the object id. Is there a scenario in which nonce is reused with the same key on a different version of an object? What about file operation in which some internal 100 bytes change? Total length of the file stays same. Will nonce be same? From me at rhapsodhy.hu Mon Dec 2 01:22:56 2019 From: me at rhapsodhy.hu (Peter Parkanyi) Date: Mon, 2 Dec 2019 09:22:56 +0000 Subject: [messaging] Zero-metadata object store In-Reply-To: <9fa2ba40-5d51-eada-034f-75d8a0afed3e@3nsoft.com> References: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> <5d1666bd-1fde-0627-3b57-b86035fed16d@3nsoft.com> <90CA4629-53A4-413D-8E57-83A416B20E17@parkanyi.eu> <9fa2ba40-5d51-eada-034f-75d8a0afed3e@3nsoft.com> Message-ID: > > Is there a scenario in which nonce is reused with the same key on a different version of an object? > > What about file operation in which some internal 100 bytes change? Total length of the file stays same. Will nonce be same? If a chunk changes, their hash changes, therefore their encryption key changes. Files are always broken up into chunks, and zerostash won't rewrite an existing chunk, because it could be referenced by other files, so the nonce changes, too. From mb at 3nsoft.com Mon Dec 2 07:08:19 2019 From: mb at 3nsoft.com (Mikalai Birukou) Date: Mon, 2 Dec 2019 10:08:19 -0500 Subject: [messaging] Zero-metadata object store In-Reply-To: <90CA4629-53A4-413D-8E57-83A416B20E17@parkanyi.eu> References: <2CD4534F-E8FA-4E4F-9237-E41DA741E7B0@rhapsodhy.hu> <5d1666bd-1fde-0627-3b57-b86035fed16d@3nsoft.com> <90CA4629-53A4-413D-8E57-83A416B20E17@parkanyi.eu> Message-ID: <2d93cfd9-264d-f349-9032-a2296c61dcbe@3nsoft.com> Peter, >> Do metadata objects contain file tree information? >> >> Is file tree continuously packed into mobjects, i.e. many folders' data is placed into every mobject? Or, is it a one mobject per folder structure? >> > File system information and keying information are in mobjects, and they are continuously packed. The aim is to sync the repo index independently from any other content using as little bandwidth as possible. Question about dobjects, objects with data chunks. Does dobject carry chunks from one file, or, can it have chunks from different files? I am trying to picture it. If mobjects and dobjects carry data from different files, then will it be correct to think about zerostash like they are disk segments? Disk segments are always same size, and they may keep data from different files. Is disk analogy correct? Longer question with context: We have the following scenario for sync-ed fs. User has two devices, and some program runs on both of them. This program may be changing same files. Server is used to setup transaction walls on objects using object ids. { So far we use model with file stored in 1 or more objects, and not many files in same object. https://github.com/3nsoft/xsp-files#xsp-file-format provides packing bytes without knowledge of a file system. File system is formulated inside of a client project, with the following interface https://github.com/3nsoft/core-platform-electron/blob/master/src/api-defs/web3n.d.ts#L151 . Each object changes in a transaction allowing for a strict version changes. Server api has transaction-related replies like in https://github.com/3nsoft/spec-server/blob/master/src/lib-common/service-api/3nstorage/owner.ts#L205 } Is it possible to have a similar transaction identification and change signalling using info available on the server (e.g. object ids), so that client with knowledge of mapping between this info and files can identify file system events, and be aware of current writes to server?