Re: [liberationtech] [OT] Please, LibTech moderation team, put this fake address under moderation.
I am reading the list in Gmail and Shara Cruz came up as a possible connection to add as I replied to a private message. Given the subject matter, I have to wonder if this isn't something a lot more nefarious and if they are possibly trying to exploit features of WebMail apps to map out the list. They must have been sending a ton of stuff for Gmail to infer a contact. Many of the Putinbots are genuinely bots and they are being used to target folk engaged in certain types of political activity. On Tue, Feb 28, 2017 at 12:49 PM, Cecilia Tanaka wrote: > Sorry for asking it publicly, but it can be a useful warning to other > people here, considering this troll always has the same stupid > patterns. > > Shara Cruz > > This fake e-mail address is sending me bizarre messages and nude pics > since I posted on LibTech about hate crimes yesterday night. Please, > put this stupid troll under moderation in preventive care. > > It's a neo-nazi guy, a radical Trump and Putin supporter, pretending > to be a lesbian girl this time, aff... He should spend all the free > time he has in hands in a more constructive way, studying or getting a > life, for example. > > (Tip: - When I want to see a "hot naked girl", I simply use my > mirror, OK? Cry, loser.) > > Ceci > --- > "Don't let anyone rob you of your imagination, your creativity, or > your curiosity. It's your place in the world; it's your life. Go on > and do all you can with it, and make it the life you want to live." - > Mae Jemison > -- > Liberationtech is public & archives are searchable on Google. Violations > of list guidelines will get you moderated: https://mailman.stanford.edu/ > mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change > password by emailing moderator at compa...@stanford.edu. > -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
[liberationtech] [SPAM:#] Spicer: Appless Security
According to sources, there was recently a meeting held in a government I won't name at which the press secretary demanded all his staffers put their cell phones on the table so they could be examined to see if they had any apps loaded that might be used to leak. Needless to say, news of the meeting leaked almost immediately. Since I do cryptography, I am of course interested in meeting the needs of whistleblowers working for dictatorial authoritarian governments that have scant concern for rule of law. At present I am working on a scheme called the Mathematical Mesh which is designed to make cryptography easier to use. This requires an app but for configuration of the device, not for cryptography per-se. The aim is to get this embedded by platform providers. http://prismproof.org/ When I talk about this problem there is always someone who immediately says, 'well that is good but we absolutely must have a unicorn for it to be worth having'. By which they mean absolutely perfect endpoint security. No, its a stupid requirement to put on a communications protocol because it isn't a communications issue, it is purely orthogonal. So putting aside demands for the impossible, what can we do to support the whistleblowing minions of Kim Jon Un, Putin, Erdogan, Trump, Mugabwe, etc. ? Inspired by the coloured boxes of the phone phreaks: Red Crypto: Communication application provides transport layer security but not end to end security, is vulnerable to server compromise. (e.g. TLS) Blue Crypto: Communication application provides end to end security but does not protect against traffic analysis (e.g. OpenPGP, S/MIME) Magenta Crypto: Communication application providing Red + Blue features. Black Crypto: Communication capability provides Magenta crypto but does not require application loaded on end point device Gold Crypto: As for Black but runs in secure partition on trustworthy hardware. Unicorn Crypto: As for gold but guarantees hardware is not compromised in fashion that end user can verify without any third party attestation whatsoever. Is Black crypto possible? I think so. We need to extend the javascript APIs a bit though and use capabilities like the ones I am developing for the Mesh. The way I would do it is the user creates a Personal Mesh Profile and connects their devices to it. This should not be in any way unusual in itself, its just the way to configure devices to share passwords, etc. Each device that is connected to a Mesh profile has a device key (a set actually). Let us imagine that we have a Javascript mechanism that allows a JavaScript application to access a device key if and only if they are signed by a signing key that is authorized for this purpose in the user's personal profile. That would appear to be sufficient to meet the 'appless security requirement' and it is very close to what we have already in next gen javascript. What the sketch does not do is to provide complete deniability as Mallet can look at the personal profile and see that it grants access. But that is a detail that can be cleared up with some smart crypto. The name Spicer seemed like a good one for the app if it is written. -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
Re: [liberationtech] How to make the Internet secure
On Fri, Feb 3, 2017 at 9:04 AM, Rich Kulawiec wrote: > > Many of these kinds of proposals are wonderfully thought out BUT > they presume underlying network infrastructure that (a) exists > (b) has sufficient performance (c) is not heavily censored/blocked > (d) is not heavily monitored/surveilled. > Those are not the problems I am working on. I am always very clear about the fact that a security solution for people in the (currently) free world is not going to be suitable for use by activists in the non free. The point about the Mesh is to address the needs of the 70% of users who live in places where strong encryption can be used with minimal risk and to make the use of strong multi-layer security the default. > The problem with that, as everyone here probably knows all too well, > is that those assumptions are often not true. In some places, they're > less and less true by the day. > Making encryption the default for email prevents attacks like those performed by Putin/Wikileaks which is a good start. Making encryption the default for email in North America and Europe means that there is a much larger volume of encrypted traffic that will be available for the activist traffic to hide in. So even if all connections are encrypted, that won't suffice: the > endpoints won't be able to connect. That is an acceptable outcome in some situations and not in others. For these kinds of proposals to be viable under adverse circumstances -- > which are the circumstances where they NEED to be viable -- they need to > be able to work over highly intermittent/slow connections (e.g., ad hoc > connections that don't traverse any ISP's broadband infrastructure) > and over sneakernet. > > *Especially* over sneakernet: I think that's an absolute must-have. > > For example: > > 1. Mail queue written onto a USB stick or memory card or similar. > 2. It's smuggled into a location. > 3. It's plugged into a system which delivers the queue locally > and/or via wifi and/or bluetooth. > 4. Same system collects traffic going the other way, then > 2 and 1 are reversed. > Yes, that is a great architecture for some applications to solve some problems. It is not an architecture for solving the problem the Mesh is designed to address. > (As a site note, let me note that there's also good reason to think > about the Usenet flooding model, because it makes traffic analysis > difficult: everything is delivered to everyone. I wrote a proposal > a few years back to leverage Usenet news plus encryption to create a > highly asynchronous, indirect communications method that would suffice > to get email and news in/out of countries with NO external connectivity. > Plus: almost all the software already exists, it's well-understood and > mature, it scales indefinitely, works over intermittent and slow links, > works over sneakernet. Minus: arguably inefficient, somewhat vulnerable > to DoS, requires rethinking duplicate detection problem.) > That is not the problem I am trying to solve. But you could use the Mesh/Remesh tool I have built as a basis for solving it. First, consider the fact that you would need to have some form of ingress control to stop the authorities simply DoSing the network by flooding. So expect that the content is going to be limited to short text messages plus longer data objects that come from trusted sources. That is a solvable problem though, distribute some form of currency and use it to ration bandwidth. The tool I use a lot is proxy-re-encryption 'recryption' which is three key cryptography. I am, by the way -- and this is a nod to your preamble about > incrementalists and absolutists -- firmly in the middle. There are a > number of things that we're doing (and have been doing) that we need > to stop doing immediately, and some things we don't do that we need to > start doing yesterday. That's the absolutist part. The incrementalist > part says that we should not be tinkering with machinery that has proven > itself to be very robust in the face of determined attacks *unless* > the replacement parts we have in mind can demonstrate that they'll be > just as resilient. For instance, I'm highly dubious about JSON email, > which I think is far more likely to introduce gratuitous complexity, > creeping featurism, and horrible code bloat -- and thus massive security > and privacy issues -- than anything else. > JSON is a lot simpler than any of the alternatives we have used to date. Right now we use different packaging formats for each messaging modality. We use RFC822 and MIME for mail, ASN.1 for S/MIME and X.509/PKIX, Jabber uses RFC822 plus XML, plus other stuff, ... Security is layered in differently in each case, always as an afterthought and always an optional extra that barely functions and is poorly supported. One of the big problems with SMTP is that the infrastructure has ossified and it is impossible to elimina
Re: [liberationtech] How to make the Internet secure
You probably want to look at this proposal by Moxie, he has already used
the name convergence and while that project is dead, the Certificate
Transparency standard is based on it.
https://en.wikipedia.org/wiki/Convergence_(SSL)
I am not looking at the transport layer right now. If a transport offering
traffic analysis resistance is available, my tools could permit
applications to make use of it without user intervention. I work at the
message layer and up.
For example, lets say that Alice has a Mesh Mail Profile that says
1 User matches {h1, h2...} : Encrypt under public key Y, send via TORmail
2 User = {Bob, Carol} : Encrypt under public key Y, send SMTP
3 Any : Encrypt under public key X, send SMTP
Here, Alice is using separate mail for users she knows and users she does
not. This allows her to use end to end encrypted mail for all incoming mail
with the proviso that if she knows and trusts the person, the endpoint is
her inbox and otherwise it is her anti-malware service.
A select number of users can use TORmail which is a hypothetical onion
routing mail system that protects against traffic analysis. To prevent
metadata analysis, we want to conceal the identity of these people. To do
this we use a DH key agreement and a salted hash.
To send a message to Alice, Bob's client first calculates H(DH (Y,
B_Private), Salt) and sees if the value matches one of the specified hash
values. If it does, the message is sent over TOR_mail. If not, Bob's client
matches the second rule and sends the message encrypted using S/MIME and
SMTP.
The policy above can be enforced as a sending policy automatically. If
Alice's key is registered in the mail app, the message will be sent
securely with no additional effort required from Alice.
On Thu, Feb 2, 2017 at 2:05 PM, Aymeric Vitte
wrote:
> Please find here: http://www.peersm.com/Convergence.pdf a proposal
> addressing all of what you are discussing here and even more (IOT,
> crypto money, etc), writen for some fundings opportunities but that did
> not make it so far for some administrative reasons + apparently some
> misunderstanding regarding what's in there since this is addressing
> quite a lot of different non trivial topics
>
> This is not difficult to guess to whom it was sent, I have removed the
> formalism but some is still there, if someone reads it then I would be
> happy to realize that I did not write this for nothing, this does
> include some new concepts I believe
>
> There is a patent inside and I have removed what was related to it, I
> know people don't like patents here but when you try to explain some
> concepts to standard bodies, organization, lists, etc and nobody care,
> then my position is just to patent and wait quietly that one day
> inevitably something like this happens:
> https://www.w3.org/2016/01/web-component-pag-charter.html
>
> It's of course not exhaustive (gnunet is not mentioned for example), and
> I would rewrite some parts now (Ethereum could maybe better means
> Bitcoin sometimes, securing IOT concepts can probably be extended) there
> is a certain level of details but not all answers are available, this
> was supposed to be a collaborative study, which probably will not
> happen, not sending it to discuss it, open license (unlike node-Tor for
> which I am contacted quite often but no it's not open source until some
> slight budget is allocated, maybe I will put it in a bitcoin contract
> that will unlock under certain conditions so this gives the code a
> chance not to disappear forever)
>
> The "world" is trying to secure people with no budget or tools (financed
> or not) that are not usable by normal people and do not cover
> everything, of course this cannot work
>
> Le 02/02/2017 à 00:01, carlo von lynX a écrit :
> > Hello Phillip, nice reading your feedback.
> >
> > On Wed, Feb 01, 2017 at 03:21:52PM -0500, Phillip Hallam-Baker wrote:
> >> I believe that mail, chat, voice, video, blog comments and mailing
> lists
> >> are all separate messaging modalities that need to be addressed in any
> >> replacement scheme. However, there is no reason why it should not be
> >> possible to support all of these modalities in a single message format.
> > Exactly. That's what we are working on.
> >
> >> Facebook is not just a messaging infrastructure. It is also an
> >> infrastructure that allows social networks to be defined, published and
> >> applied. The main objection I have to FB is that it is walled garden.
> > secushare is a distributed multicast system without central nodes,
> > it intends to recreate a featureset like FB, Skype, Whatsapp
> > fully under control of the participants - no walled garden.
> >
> >> Establishin
Re: [liberationtech] How to make the Internet secure
On Wed, Feb 1, 2017 at 2:15 PM, carlo von lynX wrote: > Coming from: Phillip Hallam-Baker > > One of the big problems I have found in trying to argue for ways we can > > improve Internet security is that there are two camps. The > incrementalists > > will only look at solutions that provide an improvement on the status > qujo > > in one area and the perfectionists insist that any solution that does not > > solve every possible problem isn't worth considering. > > Oh! Finally the clean-slate camp is acknowledged. Back when we > participated at STRINT[1] there were only 3 of us proposing a > clean-slate approach, and we were acknowledged in the final > report with one or two lines of text. > > > How about we do both? > > Yes, indeed. But, please, don't call us perfectionists. Our only > difference from the incrementalists is the awareness that the > number of deficiencies in the current TCP/IP stack is so epic[2], > it is A LOT LESS WORK to start with a new approach. From then on > there is still plenty to be done and a lot to increment and > improve, and we don't want to wait until we achieve perfection. > The original email was sent to IETF. IETF is currently working on a replacement for TCP called QUIC which runs over UDP. This provides for multiple streams. There is also momentum behind the JSON encoding approach. My point is that I am not opposed to redesigning the application layer from scratch. But I am not going to insist on it either. I am not offering an either/or of incremental or start from scratch. I am saying that I can fix the security problems in SMTP with S/MIME or OpenPGP in a framework that then allows an easy transition to Next Gen Mail. > > Also to save time: > > > > [...] > > > > * Yes, I need help, a lot of help > > Have a look at gnunet.org. The description you make (that I > replaced with [...]) sounds like things that are already possible. > gnunet started in 2003, so it may be slightly ahead of you... Again, that was simply for IETF consumption. Without the recitation of goodness, the discussion inevitably gets dragged into the weeds by someone insisting that I have not thought of X. When chances are I have thought of X a great deal. > > OK so how is this possible? > > > > First observation is that we now have several protocols that provide > users > > with end to end security that are really easy to use. The only real > problem > > I have with those systems is that they operate inside walled gardens. > They > > are not going to be a replacement for email. > > Doing a replacement for email means doing a replacement for Facebook. > Many people are avoiding to ever start using mail, since they can do > it all on Facebook and the cumbersome aspects of mail are resolved > (instead of having to deal with user@host addresses they just click > on people). That's why secushare is working on distributed social > networking over GNUnet which as a side effect brings about the kind > of mail system we all should be using: Easier than Facebook, but > absolutely privacy-preserving. And we're not the only project heading > in that direction. There's also Patchwork, Briar... > I believe that mail, chat, voice, video, blog comments and mailing lists are all separate messaging modalities that need to be addressed in any replacement scheme. However, there is no reason why it should not be possible to support all of these modalities in a single message format. Facebook is not just a messaging infrastructure. It is also an infrastructure that allows social networks to be defined, published and applied. The main objection I have to FB is that it is walled garden. Establishing a uniform identifier that has unambiguous meaning across domains is the key to breaking up walled gardens. > 2) Extend a direct trust model into the DNS > > > > We all know about TOR and onion routing. Well what if I could have an > email > > address that included my OpenPGP fingerprint? Well we can. Just use the > > xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel > > and we can make the fingerprint the TLD: > > > > al...@example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE > > > > [...] > > This sounds like an incremental approach to me. Why not simply do the > routing by public key? Why not map the nickname or realname of a person > to their public key using a mechanism like GNS? A lot less cumbersome... The reason for not using public keys is security. I want identifiers to be stable for long lengths of time, potentially a lifetime. It should be possible to rotate public keys on a weekly basis without cost to the user. UDF fingerprints can be taken of any data object.
