[hm] comunicaciones seguras (Re: Riseup comprometido)

Lun Ene 9 16:57:17 CET 2017

On 09/01/17 03:19, Pedro wrote:
> Puedo empezar por... estoy harto!
> Tenemos un montón de problemas tecnosociales, y todavía discutiendo a
> través de cuál canal de comunicación nos comunicamos. Por suerte lo
> del correo está muy instaurado, no se puede decir lo mismo de
> "empoderado".
>
> Al pequeño debate entre: cuentas email en servidores autogestionados o
> montarnos nuestros propios servidores de correo: Las dos cosas. Pero
> está bastante desequilibrado. Hay poca gente lo tengan propio, una
> pequeña ayudita [-1]
>
> Siguiendo la conversación.
>
> Algunos de nosotros de forma más o menos consensuada nos estamos
> moviendo en torno a 2 soluciones:
>
> Matrix: estilo clásico federado de internet, como en correo
> electrónico (contra: fuerte arraigo al DNS). Por qué matrix? Cantidad
> implementaciones de clientes y servidores [0]. Esto es: cada uno puede
> tener su propio servidor de matrix, y a parte, que haya salas de
> grupos en determinados servidores. Por qué habrá tantas
> implementaciones de servidores y clientes en matrix? Porque es
> sencillo, y esto es bueno. También tiene muchos enlaces con otros
> protocolos: IRC, XMPP, etc. Lo encuentro una evolución interesante del
> chat público con todas las nuevas ventajas que han ido incorporando
> los nuevos tipos de chats. Para chats seguros, los de riot.im/app ya
> tienen funcionando una comunicación extremo a extremo que funciona en
> chats de grupos.
>
> Retroshare nuevo estilo de comunicaciones seguras y completamente
> descentralizadas. Es a todas todas mejor que Matrix. Por otro lado,
> las implicaciones de su uso rompen bastante el esquema al que estamos
> acostumbrados. Nosotros comiendo canapés (cliente) y un camarero con
> la bandejita al lado (servidor). En ese sentido, o dejamos el cliente
> casi siempre encendido, o montamos un servidor casi siempre encendido
>
>
>
> De bitmessage he dejado de leer el white paper [1] cuando he llegado a:
>
> "We propose a message transfer mechanism similar to Bitcoin’s
> transaction and block transfer system [8] but with a proof‐of‐work for
> each message"
>
> No es que tenga mucha idea de bitcoin, pero hay varias cosas que no me
> hacen gracia sobre bitcoin aplicado a mensajes:
> - base de datos única con todos los mensajes. Ok, estos mensajes están
> cifrados. Pero que estén todos juntitos y constantemente bien
> recopilados no me hace mucha gracia.

¿Cuál es el problema?
Yo no me he leído el código -en primer lugar porque no sé-, así es que
no voy a defender Bitmessage, pero en Bitcoin cada nodo tiene la
blokchain entera. Y eso que es pasta, no mensajes.

> - que no es exactamente "anónimo", son seudónimos, como las
> carteras/cuentas de bitcoin, lo cual entiendo que te va a estar
> obligando a ir cambiando de cuentas para tener un "nuevo seudónimo".

Sí, Bitcoin no tiene nada de anónimo, pero Bitmessage no es Bitcoin, y
que yo sepa no es un fork. Yo no conozco ninguna herramienta de
mensajería asíncrona más anónima que Bitmessage (aunque no la torifiques
cambiándole los Proxy settings, que es algo que te permite hacer
fácilmente).

El mayor problema que yo le veo ahora a Bitmessage es que los mensajes
de cada thread no llegan siempre perfectamente ordenados. Poner un
timestamp podría ser demasiado metadata. Si alguien conoce en qué
segundo se ha enviado algo y controla más de un nodo, podría observar
cómo se propaga ese mensaje por la red. Creo que están estudiando
diferentes formas de solucionarlo.

Yo no sé qué prefiero, no conozco Matrix y en Retroshare aún tengo
pendiente volver a hacer pruebas con la mensajería asíncrona, pero me
gusta el debate, estaría bien dejar el correo, sobre todo les que lo
tenemos en máquinas ajenas.

>
> [-1]
> ** autoemail
> *** docker-mailserver
> https://github.com/tomav/docker-mailserver
> https://github.com/tomav/docker-mailserver/wiki
> https://github.com/tomav/docker-mailserver/tree/master/test
> *** mail in a box
> https://mailinabox.email/
> *** nsa proof your email in 2 hours
> http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
> *** sovereign
> https://github.com/sovereign/sovereign
> *** modoboa
> https://github.com/modoboa/modoboa
> *** iredmail
> permite estar basada en sogo / debian
> http://www.iredmail.org/download.html
>
> [0] http://matrix.org/docs/projects/try-matrix-now.html
> [1] https://bitmessage.org/bitmessage.pdf
>
> 2017-01-02 14:36 GMT+01:00 al <al en blogmail.cc>:
>> On 02/01/17 00:24, Amuza wrote:
>>>
>>> On 01/01/17 18:50, al wrote:
>>>> On 31/12/16 20:51, meskio wrote:
>>>>> Quoting ale (2016-11-25 10:56:12)
>>>>>> Pues eso, hay cierto revuelo online acerca de los servicios de RiseUp,
>>>>>> que están potencialmente comprometidos, dado que no han actualizado su
>>>>>> 'canary'. Supuestamente están bajo una 'gag order', una orden judicial
>>>>>> que les impide expresarse al respecto de una investigaciń en curso, que
>>>>>> con toda probabilidad todavía no ha llegado al punto de comprometer los
>>>>>> servidores. En esa situación una de las posibilidades es que riseup
>>>>>> desactive servidores/servicios.
>>>>>> En este contexto, los usuarixs de riseup deberían hacer backup y pensar
>>>>>> en correos alternativos.
>>>>>>
>>>>>> Más info:
>>>>>> https://c4ss.org/content/47015
>>>>> No creo que haga falta dejar de usar los servicios de riseup, aunque hacer
>>>>> backups y borrar emails de la cuenta siempre es un buen consejo
>>>>> independientemente del canario.
>>>> Estoy de acuerdo contigo, Meskio, pero también estoy de acuerdo en que
>>>> "pensar en correos alternativos" es una buena idea general. Esté o no
>>>> comprometido RiseUp no tiene sentido dejar en manos de una única
>>>> organización norteamericana decenas de miles de correos de activistas
>>>> haciendo un uso clientelar. Por un lado es un caramelito para las
>>>> organizaciones de vigilancia masiva, al mismo tiempo que es una
>>>> responsabilidad enorme para una organización relativamente pequeña
>>>> sustentada en gran parte por voluntarios, por otro lado siempre es
>>>> recomendable distribuir la información y con ella también el
>>>> conocimiento de cómo montar servicios. La soberanía tecnológica también
>>>> es uno de los valores a tener en cuenta a parte de la seguridad y la
>>>> privacidad.
>>>>
>>>> Consumo local, quilómetro cero, autogestión,
>>>> do-it-yourself/do-it-with-others y empoderamiento tecnológico son
>>>> conceptos muy afines que reforzamos en el Hackmeeting.
>>>>
>>>> Por otro lado se entiende que RiseUp den servicio a colectivos de
>>>> lugares donde realmente es complicado por falta de infraestructuras
>>>> eléctricas, de comunicaciones, de censura,... de lugares realmente
>>>> peores que el nuestro, pero en nuestro ámbito realmente no es tan
>>>> complicado.
>>>>
>>>> Si alguna persona/colectivo quiere montarse su propio servicio de
>>>> comunicación yo me ofrezco a echar una mano, seguramente más personas de
>>>> esta lista también.
>>> ¿Y qué os parece probar Bitmessage [1]?
>>>
>>> Yo llevo tiempo usándolo y todo parece funcionar correctamente.
>>>
>>> Bitmessage es la única herramienta descentralizada que conozco para
>>> mensajería asíncrona que funciona bien. Retroshare se supone que también
>>> tiene mensajería asíncrona, pero hice varias pruebas y nunca funcionó.
>> Usa las identidades (de la pestaña "people") en vez de los nodos (de la
>> pestaña "Network").
>>
>> Si tienes como contacto un nodo "Just Relay It", de los que siempre
>> están conectados (o que nunca se rompa la cadena de contactos
>> conectados) el mensaje asíncrono llegará. Piensa que no hay un servidor
>> central, por lo que no puede hacer "magia" si desconectas tu nodo antes
>> de que el mensaje le haya llegado a la identidad final o a uno de
>> posibles nodos intermedios hasta ella (y así sucesivamente).
>>
>>> (Si a alguien le ha funcionado alguna vez la mensajería asíncrona en
>>> Retroshare, por favor que me lo diga! Estoy buscando una herramienta
>>> descentralizada de mensajería asíncrona que funcione tanto en Internet
>>> como en una LAN sin Internet)
>>>
>>> Si queréis probar Bitmessage, he creado un chan (Channel o Lista de
>>> Correo Descentralizada) llamada "Hackmeeting Iberia" con dirección
>>> BM-2cWdBcmBcAim1QXcSSvGk1UL49EZGnGWeG
>>>
>>> He escrito aquí los datos del chan porque asumo que éste sería público,
>>> tal y como lo es esta lista de correo que estamos usando ahora.
>>>
>>>
>>> Amuza
>>> BM-2cUsCCqmCMUqbozY1L16zWTgHnAEnb6mbz
>>>
>>>
>>> [1] https://bitmessage.org
>>>
>>>>> Esta muy bien el articulo en the intercept sobre el tema (en ingles lo siento):
>>>>> https://theintercept.com/2016/11/29/something-happened-to-activist-email-provider-riseup-but-it-hasnt-been-compromised/
> _______________________________________________
> HackMeeting mailing list
> HackMeeting en listas.sindominio.net
> https://listas.sindominio.net/mailman/listinfo/hackmeeting