/tech/ - Technology

Brought to you by archive.org

Posting mode: Reply

Check to confirm you're not a robot
Name
Email
Subject
Comment
Password
Drawing x size canvas
File(s)

Remember to follow the rules

Max file size: 350.00 MB

Max files: 5

Max message length: 4096

Manage Board | Moderate Thread

Return | Catalog | Bottom

Expand All Images


Communication best practices Anonymous 07/31/2017 (Mon) 02:09:16 [Preview] No. 10507
I would like to open this thread to discuss the best practices of communication, essentially the three forms: archive sharing, text/image and voip (video conference).

The software has to be:
- Decentralized or distributed
- End to End encrypted
- Open Source

Prefered if:
- Audited / Formal methods (proof/verification)
- Anonymous
- Don't leak much matadata
- Good coding practices (privsep, sandboxing, etc).


For archive sharing:
- Retroshare
- Tahoe-LAFS
- IPFS

For messaging:
- Ricochet
- Briar
- Matrix
- XMPP with OMEMO

For VOIP/Video conference:
- Jitsi


Signal Protocol, ZRTP and WireGuard Protocol seems to be the best choices. But Signal Protocol has poor implementations and uses XMPP (leaks metadata).
Feel free to point better solutions...


Anonymous 07/31/2017 (Mon) 14:28:09 [Preview] No. 10508 del
>ricochet
hard dependency on the qt toolkit, developer doesn't care, points to other forks which are dead, I don't see how this is better than tox with tor or why has it been shilled so much
>matrix
the only god damned client who has encryption possibilities is the electron bloated one, stop promoting this shit, it's not even distributed at the moment.


Anonymous 07/31/2017 (Mon) 19:10:17 [Preview] No. 10512 del
IPFS

Twister

Tox

Honourable mention:
GNUnet


Anonymous 08/01/2017 (Tue) 00:02:24 [Preview] No. 10520 del
>>10508
So we're only left with tox? I liked the idea of retroshare.


Anonymous 08/01/2017 (Tue) 05:18:10 [Preview] No. 10521 del
I would consider voip independently. It is very unlike the other two, which don't require any real-time interaction between producers and consumers of bits and thus can (and probably should) be implemented conceptually as dead drops.


Anonymous 08/01/2017 (Tue) 21:31:47 [Preview] No. 10529 del
I only shared my opinion regarding the ones I looked into and I've used. I haven't used retroshare and I didn't analize it so I can comment on it.


Anonymous 08/02/2017 (Wed) 07:27:08 [Preview] No. 10532 del
>>10529
IMO retroshare tries to do too much, how can you securely trust something that implements so many features. Either their team is fucking huge or they are over ambitious.


Anonymous 08/08/2017 (Tue) 01:10:01 [Preview] No. 10580 del
>>10508
>hard dependency on the qt toolkit
True.
>developer doesn't care, points to other forks which are dead
True. I asked myself about a TUI version on Github, got only an unofficial port of it.
>I don't see how this is better than tox with tor
Metadata. Although Ricochet uses weak crypto, unlike Tox that uses libsodium (very mature library, but also probably has issues on Tox implementation of this lib), Tox leaks more metadata than Ricochet and, as we could see on NSA documents, metadata can be even more harmful to track and fuck you than the data itself.
>why has it been shilled so much
Same reason above, metadata.
>>matrix
>it's not even distributed at the moment.
Good point. I'm not promoting it, I just want to know what is the best practices now and call for the attention on this board to communicate securely.
Also, I'll use an 'request to authority' here: the modern crypto mailing list shill Matrix all the way, and this list has many well known cryptologists. I don't use it, though.


Anonymous 08/08/2017 (Tue) 01:12:36 [Preview] No. 10581 del
>>10521
>I would consider voip independently
Fair enough. VOIP is also more difficult on timing attacks...
I just put it on this list because some people need video conference software.

>>10532
>how can you securely trust something that implements so many features.
Agreed. The surface attack is huge on Retroshare. It's also not anonymous by default. But it's better than most of the others, except maybe Tahoe-LAFS, but it's more difficult to use for normies.
>their team is fucking huge
It's not.



OP here: So, any alternatives? We're left with Signal/Tox and that's it for now? I'm looking hopefully to Briar Project, seems to have a good concept behind it, I don't know about the implementation, though. "Ring" seems interesting too.

People really should start to look on formal methods. Many technologies advanced since then and today there's dependent-type languages and protocols (capability-based and component-based software engineering) that offer better flexibility and security. Also, isolation principles are not going mainstream as it should be. No gnu/linux system have an alternative to openbsd pledge by default (as far as I know) and that should be the default on all systems.


Endwall 08/08/2017 (Tue) 02:05:46 [Preview] No. 10584 del
Set up a tor mail server using postfix or OpenSMTPd, with dovecot for imap or pop.

You may contact me anonymously at endwall@tmg3kli67jlbcduh.onion
Use endmail.sh to send mail to this account.
http://42xlyaqlurifvvtq.onion/endwall_pgp.asc

Encrypt with pgp and send messages and files by email on a tor hidden mail service on port 25.

Everyone should do this. Then just share your hidden service address and handle.

http://42xlyaqlurifvvtq.onion/endware/endmail.sh

http://42xlyaqlurifvvtq.onion/endware/endfix.cf

http://42xlyaqlurifvvtq.onion/content/dovecot/

Try it out!


Anonymous 08/08/2017 (Tue) 02:16:48 [Preview] No. 10585 del
You're right, I forgot about metadata.
I used to be so enthusiastic about privacy related software and now I feel so fucking hollow. Literally nothing is good enough and nobody cares anymore.
I don't know what to recommend op except to mention firejail even though it's not the same thing as pledge.


Endwall 08/08/2017 (Tue) 02:52:22 [Preview] No. 10586 del
STEP 1) install postfix

$ su
# torsocks pacman -S postfix dovecot
# ...

# cd /etc/postfix/
# cp endfix.cf /etc/postfix/main.cf

STEP 2) Install dovecot

# cd /etc/dovecot/
# mkdir -p conf.d
# cp dovecot.conf /etc/dovecot/dovecot.conf
# cp *.conf /etc/dovecot/conf.d/
# cp *.ext /etc/dovecot/conf.d/

STEP 3) Make ssl self signed certificates for postfix and dovecot and place these in the appropriate directory
This might require entropy so you might need to run haveged first

# torsocks pacman -S haveged
# haveged

# mkdir -p /etc/pki/tls/certs
# mkdir -p /etc/pki/tls/keys
# cd /etc/pki/tls/keys
# openssl req -x509 -newkey rsa:4096 -keyout postfix.key -out postfix.crt -days 365 -nodes
# openssl req -x509 -newkey rsa:4096 -keyout dovecot.key -out dovecot.crt -days 365 -nodes
# mv postfix.crt ../certs/
# mv dovecot.crt ../certs/

or use libressl or gnutls and create the same certificates

now go back and edit /etc/postfix/postfix.cf and /etc/dovecot/dovecot.conf to reflect the location of the certificates and keys

STEP 3) start the services

# systemctl enable postfix
# systemctl start postfix

# systemctl enable dovecot
# systemctl start dovecot

or the openrc equivalent to enable and start the services.

STEP 4) Setup tor for mail hidden service

# mkdir -p /srv/tor/mail

Add this to your torrc file and start tor

nano /usr/local/etc/tor/torrc

HiddenServiceDir /srv/tor/mail/
HiddenServicePort 25 127.0.0.1:25

your hidden service name will be generated and placed in the directory /srv/tor/mail/hostname

# cat /srv/tor/mail/hostname

This is the hostname for your mail server. Go and edit /etc/postfix/main.cf to reflect this.

Do Not Share the private key from this directory with anyone, and change the permisions to read only with no access to other.

# chmod o-rwx /srv/tor/mail
# chmod g-rwx /srv/tor/mail
# chmod u-wx /srv/tor/mail

STEP 5) Select a strong password for a new user account

# passgen --bytes 33

Write this down in a passbook and add a few random numbers and letters from your mind in here as well.
Alternatively store your keys in a gpg encrypted file on an airgapped computer with a memorizable password to open the file.

STEP 5) Create a new user with your anonymous handle /name

# useradd anon12345foo -m -s /bin/bash
# password:
# verify password:

STEP 6) Restart the services
You might have to postmap the file recipient access

# cd /etc/postfix
# echo "anon12345foo permit" >> recipient_access
# postmap recipient_access
# echo "127.0.0.1 permit" >> client_access
# echo "192.168.1.32 permit" >> client_access
# postmap client_access
# postmap aliases
# postmap access
# postmap virtual

# systemctl restart postfix
# systemctl restart dovecot

# systemctl status postfix
# systemctl status dovecot

STEP 7) Setup imap retrieval with clawsmail, etc. using the name and paswsword, or don't use dovecot just read it from the maildir directly or use Mutt.

Go into claws-mail options and add a new account ...

STEP 8) create a pgp public key using RSA 4096

sign in as anon12345foo

$ gpg --generate-key

$ save the public key

STEP 9) distribute the hiddenservic name your handle and the public key.

STEP 10) Check your mail using claws-mail or use mlogz.sh to look at activity on your mail server for new incomming mail.

STEP 11) send mail to other tor hidden service mail servers using endmail.sh

There might be errors or omissions in the above but I think that's the general process. Now you have a tor hidden service mail server, that uses a selfsigned certificate and you have a gpg public key. you use tor and ssl and gpg to secure your email communications, and you are known by your handle and hidden service .onion address. Get burned ?
# rm -rf /srv/tor/mail/hostname
# rm -rf /srv/tor/mail/privatekey

and restart tor to start over

# userdel -rf anon12345foo
# useradd anon142boo -m -s /bin/bash

and edit /etc/postfix/main.cf and /etc/dovecot/dovecot.conf to reflect the new hidden service name.


Anonymous 08/08/2017 (Tue) 02:59:03 [Preview] No. 10587 del
>>10585
>I used to be so enthusiastic about privacy related software and now I feel so fucking hollow. Literally nothing is good enough and nobody cares anymore.

Indeed. I think it's the moment of realization, when we understand that computing was developed with the mote "get the work done" and not "do in the right way". As we can see today, there's no fundamental basis on computing, no real basis standard formal specification, it's on "designed by commit". It's probably a common phenomena, a bell curve, when you start to learn about computing in general, just like in Yerkes-Dodson law:
https://en.wikipedia.org/wiki/Yerkes–Dodson_law

>>10584
SMTP is an old protocol. Should not be used if you want more security/privacy, even on Tor.
There's alternative for emails, like Bitmessage or Pond (although Pond is an abandonware now, very suspicious actually)...


Endwall 08/08/2017 (Tue) 03:34:08 [Preview] No. 10589 del
>>10587

the message is encrypted with RSA:4096 , then it is sent over tor (with 6 hops) end to end encrypted, connects to a mail server that supplies a session key with RSA:4096 SSL. No metadata is revealed to an Eve's dropper. Only your hidden service address and your username are revealed to anyone you communicate with, and if you get burned you delete those and start over.

You have GPG RSA:4096 SSL RSA:4096 and Tor with 6-12 hops protecting the communication.

How does this fail?


Endwall 08/08/2017 (Tue) 04:24:35 [Preview] No. 10590 del
>>10587
>>10589

All 3 encryptions would have to fail simultaneouly. Do the gpg encryption and decryption on an airgapped non intel architecture computer running OpenBSD with full disk encryption. Super Mega Maximum Communication Security Protocol (SMMCSP) (TM). Game Over NSA.


Anonymous 08/08/2017 (Tue) 05:02:19 [Preview] No. 10591 del
>>10589
>How does this fail?
Ok, here we go again.

The two fundamental flaws are:
- Your method uses self-handled PKI. It will only work if, and only if, you are sure the pubkey you got is from the right person you're trying to contact. If you didn't get this from his hand (printed on paper on a cryptoparty, for example), you can not be sure you're contacting the right person. That's why forward-secrecy was invented.

- Your method is too complicated and, thus, is prone to many human errors. If you have a tech-naive person to contact, you cannot make sure she/he will do the right thing. That's why we have automation.


The technical flaws:
- You talk about openbsd, but your instructions above use pacman
- You talk about TLS crypto, but you're already using PGP, so it not important. You're also using a outdated piece of shit (OpenSSL)
- Your instruction uses root for all the processes. It's dangerous and most of it could be done without root, on an unprivileged user
- This:
>add a few random numbers and letters from your mind in here [passphrase] as well.
What this even mean? If you don't trust your (P)RNG, your crypto is already fucked
- And this:
># rm -rf /srv/tor/mail/hostname
No need for root, this folder should be owned by the user. Also, you're not writing above the file (use shred or the option "-P" on rm if on OpenBSD to safe-deleting files)

- You're using GnuPG. There's better tools for this now, like reop (from tedu@)


tl;dr
Your approach ignores all the advances in secure communication in the last decade and stays on 90's. It uses outdated protocols, is too difficult and prone to human errors. You may be sure you're applying it correctly, but you can't be sure the other person is not simply leaking it's private key and destroying your security/privacy.
It's also unrealistic. No one in right mind would do this for trivial communication:
<Do the gpg encryption and decryption on an airgapped non intel architecture


Anonymous 08/08/2017 (Tue) 05:13:39 [Preview] No. 10592 del
>>10589
Also, I'm not in position to tell you or anyone how to think, and may be labeled as pretentious, but: try to simplify your cognitive process... see, simplify is not suffer from parsimony (reductionism / reductio ad absurdum), it's to compact your thinking to the basic principles (just like in lossless compression). Your approach fail (from my perspective) because your cognitive process is addictive and not subtractive, you want more and more security so you try to research and extract the least bit of configurations and optimizations, but you may fail to perceive that computing security works by the most simple method (see the concepts of least privilege principle and attack surface principle, although you probably have already read about it). I'm saying it because I was exactly like that when I studied security concepts, always trying to find the more complex approach (that may fall into the security through obscurity and not on the kerckhoffs' principle)...


Endwall 08/08/2017 (Tue) 06:47:32 [Preview] No. 10593 del
On my desk in front of me sits an HP AlphaServer DS15 running OpenBSD 6.1, stacked ontop of that sits a SunBlade150 UltraSparc IIi 550MHz with OpenBSD 6.1, both are unfortunately connected to the internet. Under my foot sits a piece of shit intel computer with intel ME and Parabola GNU/Linux, I'm typing on it currently.

Substitute the command pkg_add. You can substitute my shitty parabola arch computer that I'm typing on for the other computers on my desk and use OpenSMTP instead of postfix, and tweak the SMMSCP for your use case. I'm using Parabola for the transmission computer because it's up and running (and has been since last summer with the exact protocol I mentioned minus the airgap) and I use it everyday (although I haven't recieved any mail in months).

To my left knee is a Sunblade100 UltraSparc IIi 500MHz running openBSD 6.1 that is full disk encrypted. This will be running as an airgapped decryption,codding,writing,planning,workstation, on the desk behind me.

This protocol deals with the problem of keylogging and malware on the transmission computer permenantly, forever. You're going to have to be Superman to exfiltrate data off of my SunBlade100 with OpenBSD 6.1 airgapped by read only floppy disks.

>add a few random numbers and letters from your mind in here [passphrase] as well.
> What this even mean? If you don't trust your (P)RNG, your crypto is already fucked

It means use passgen on the airgap, and then insert a few letters and numbers in random places in the password you generated. Going from psuedo random to now really random. In fact that's how I make my passwords I run passgen a few times and dart my eyes around the screen picking up blocks of 5 letter characters and string 6 or so blocks together to make the passwords. Works great. Diceware but faster.

> well if you don't even trust...

No I don't.

> Your method uses self-handled PKI. It will only work if, and only if, you are sure the pubkey you got is from the right person you're trying to contact. If you didn't get this from his hand (printed on paper on a cryptoparty, for example), you can not be sure you're contacting the right person. That's why forward-secrecy was invented.

Two anonymous people are talking on the internet, they don't have to meet, they never should meet, they shouldn't know each other or ever meet in person. The TLS certificate is there for you to check session to session to make sure you're talking to the same server, also using TLS with RSA:4096 adds another layer of encryption higher than Tor's low end 1024 bit encryption. Use a different program like libressl or gnutls if you don't trust openSSL. Tor (modded for 6 hops) adds weak encryption (SHA1 RSA 1024) plus anonymity ( 12 hops between hidden services if both do the mod from os).

- You talk about TLS crypto, but you're already using PGP, so it not important. You're also using a outdated piece of shit (OpenSSL)

It is important, it lets me know that I'm talking to the same server every time I contact that person. Also if someone magically breaks Tor and redirects me to their server and somehow also tricked me (I don't notice that the TLS certificate has inexplicably changed) but I forward the encrypted message, they still can't decrypt it. The man in the middel needds to break Tor, steal the SSL certificate and the private key of the counterparty. They would have to be sitting with the user log on on that computer or have appropriated /confiscated the computer from the counterparty (Law Enforcement). Use LibreSSL, or GnuTLS instead, but same principal, I'll rewrite my guide later.

- You talk about openbsd, but your instructions above use pacman

Yeah and...? you can use debian for the transmision computer and openBSD for the decryption center which only needs

# pkg_add gpg

Or use openBSD on both systems substitute pacman with pkg_add.


Endwall 08/08/2017 (Tue) 06:52:47 [Preview] No. 10594 del
>- You're using GnuPG. There's better tools for this now, like reop (from tedu@)

gpg works or have you broken RSA? News to me, and everyone else.

But OK thanks for the tip I'll check out reop, (it's not in the parabola repo). RSA works, RSA on an airgap works even better.

Also make up your mind :

- Your method is too complicated and, thus, is prone to many human errors. If you have a tech-naive person to contact, you cannot make sure she/he will do the right thing. That's why we have automation.

Which non technical person knows about reop?

I'm contacting someone from the tech world who knows how to use gpg, let the lamerz use gtk fischer price blue haired fagware. gpg is the industry standard. I automated the transmission with endmail.sh .

>It's also unrealistic. No one in right mind would do this for trivial communication:
>Do the gpg encryption and decryption on an airgapped non intel architecture

I will and I am going to do this. I don't trust any operating system or computer with an RJ45 cable plugged in, and if you do, you're not thinking it through. And I don't trust x86-64 or any computer manufactured after 2005 period. I've been keylogged, I've been malwared, it happens. If your message is important, sensitive, life sensitive, liberty sensitive, encrypt and decrypt on an airgap. If it's just your grocery list or an initial conversation I suppose you can encrypt and decrypt on the transmission computer. If it gets serious switch keys to something airgapped.

If you're encrypting and decrypting on an intel computer manufactured after 2005 running linux or running any operating system with a continuous broadband internet connection plugged in, then you don't care about the message integrity. I wouldn't trust my life or liberty to that kind of situation, I don't care who coded the operating system, how correct the code is, or how many audits have been performed. The hardware is fucked.

>but you can't be sure the other person is not simply leaking it's private key and destroying your security/privacy.

Correct, I assume that the counterparty is a fuckhead out to get me that will leak the communication if incentivized to do so (manually by decrypting the message and forwarding it to Law Enforcement). Which is why I don't do computer crime or do crime facilitated by my computer. And also why there will be anonymous hidden services, anonymous user names like anon345245, burnability ( oh you've been untrustworthy, OK I shutdown the hidden server delete it and restart, change my username and make a new gpg key pair on the air gap and move on).


Endwall 08/08/2017 (Tue) 07:09:15 [Preview] No. 10595 del
>>10592
No

It uses Security by actual physical isolation. Hardest of the hardcore.
Provides anonymity through Tor (12 hops)
it provides

All of which can be implimented with 4 tools:

1) base install of a *nix operating system in text mode
2) gnu privact guard (gpg) on the airgapped encryption decryption system
3) TLS 1.2 using RSA 4096 and postfix alows for certificate comparison (am I connecting to the same server every time? or being tricked?)
4) Anonymity ( and weak encryption SHA1 RSA 1024) using Tor network with 12 hops

Minimal instalation:

Computer 1 (Transmision computer)
1. Base install of *Nix in TEXT MODE no GUI / or use a GUI (whatever)
2. pkg_add postfix (or OpenSMTPd) tor torsocks swak, (openssl or gnutls or libressl)
3. endget endmail.sh, endfix.cf (for postfix)

Computer 2 (Decryption/Encryption Station)
1. Base install of *Nix + Full disk encryption in TEXT MODE no GUI
2. pkg_add gpg
3. Unplug computer from internet forever

Move keys and messages by read only 3.5" floppy disk files.

Very simple. Simplicity on Simplicity. Very Safe. Saftey on Safety.

SMMCSP brought to you by the Endware Development Team (c) 2017.


Endwall 08/08/2017 (Tue) 07:17:30 [Preview] No. 10596 del
>No but I want to be able to have voice to voice communication

What part of anonymity are you mis understanding? Lets add video chat while we're at it.

> Exactly I'll wear a Guy Fawkes mask...it' will be super anonymous guys.

Uh huh...

>No but I want gtk and radio buttons, in a streamlined interface all on my Intel core i8 18 core 2017 iMac with built in video conference camera.

Are you serious? So what happens to your encryption when there is keylogging malware implanted on your computer either by inclusion in the operating system base, or by accidental addition through package loading? does reop protect against this? How about when they turn on your camera remotely and start taking pictures of you while you type about ( Insert treason,sedition or crime here).


> Haha I've got it covered that's why I have the Guy Fawkes mask remember.

Uh huh...

OK well good luck with crypto cat I've gotta go. C Ya ~!

> : P eace bro Y


Anonymous 08/08/2017 (Tue) 09:11:02 [Preview] No. 10597 del
>>10593
>>10594
>>10595
>>10596
T-thanks, you just destroyed the thread.
You're probably a markov-chain bot (most of what you've said came from comments I did myself here on /tech/ and on 8ch /tech/), but if you're not, you need treatment. You probably hear it a lot, I know it, but you're having a dissociative personality disorder (derealization/depersonalization) and/or you're very suggestive to what others say. Contrary to what our culture say today, it's not a "cool" think. It's not cyberpunk, it's just idiot.

But, I'll answer you since other people read this board and may fall into your misinformed comments:
>No I don't [trust in PRNG].
That's my point. If you don't trust your PRNG, you're already fucked. It means absolutely nothing your effort, because cryptography works by generating random numbers. If they are deterministic, then you're fucked and all your crypto is broken. You should read about cryptography and how it works.

>Which non technical person knows about reop?
None. That's why I've said your method is shit.

>I'm contacting someone from the tech world who knows how to use gpg
I'll let it clear: I don't give a shit. You're talking about real-world crypto communication. The kind of crypto that a journalist without technology knowledge can use to not be murdered by some fucked up agency.

>I don't trust any operating system or computer with an RJ45 cable plugged in
And you should not. But you're being an idealist. Again, we're talking about realistic usage.

>Which is why I don't do computer crime or do crime facilitated by my computer.
You lose the battle. If you're restraining yourself, they already won. The basic idea behind our study on computing security is to prevent this from happening, preventing people to stop saying what they want just because they fear the worst.

>all the things about your hardware
Cool. So you have an SPARC64 running on OpenBSD? Nice. As you probably already know, your firmware and BIOS are not open source and it's not audited. Check OpenSPARC project, you may be able to flash it. Also, hardware trojans.



Now, please, fuck off. You're flooding this thread with your ignorance.
If you're going to reply, do it briefly please.


Endwall 08/08/2017 (Tue) 09:59:41 [Preview] No. 10598 del
>>10597

>You're probably a markov-chain bot (most of what you've said came from comments I did myself here on /tech/ and on 8ch /tech/), but if you're not, you need treatment. You probably hear it a lot, I know it, but you're having a dissociative personality disorder (derealization/depersonalization) and/or you're very suggestive to what others say. Contrary to what our culture say today, it's not a "cool" think. It's not cyberpunk, it's just idiot.

>You're probably a markov-chain bot

Are u nu here?

>>>/os/

The Endware Hidden Service
http://42xlyaqlurifvvtq.onion

>Now, please, fuck off. You're flooding this thread with your ignorance.
> If you're going to reply, do it briefly please

OK here goes nothing:
gpg works,tls works, air gap decryption/encryption works, Tor works. Use my method if you're serious about security, don't use my method if you're not. You can get my files from The Endware Hidden Service.

>Which non technical person knows about reop?
None. That's why I've said your method is shit.

But you just said that you want non-technical people to use the crypto...??

According to you gpg,tls, tor , and air gapping (all industry standard) are all bad.
I'm not debating you, you're wrong.

>Check OpenSPARC project, you may be able to flash it.
That's good advice. I have 3 2U Sun T1000s sitting in my basement, they're very loud and I'll liberate them/ flash their bios when I have the time. I bought them for $12 + shipping on Ebay.

I'm done, that was my response. Bye now!


Anonymous 08/08/2017 (Tue) 10:13:28 [Preview] No. 10599 del
>>10596

What's wrong with Cryptocat?? I use Cryptocat!

I like Cryptocat it has... cats...and crypto!

https://en.wikipedia.org/wiki/Cryptocat


Anonymous 08/08/2017 (Tue) 10:29:42 [Preview] No. 10600 del
>>10591

>Your method uses self-handled PKI. It will only work if, and only if, you are sure the pubkey you got is from the right person you're trying to contact. If you didn't get this from his hand (printed on paper on a cryptoparty, for example), you can not be sure you're contacting the right person. That's why forward-secrecy was invented.

You don't understand what forward secrecy is.

It does not--and was not intended to--solve the key distribution problem.


Anonymous 08/08/2017 (Tue) 10:58:28 [Preview] No. 10601 del
>>10600
True. Sorry. Got confused, since I don't read about this in about a year.
Let me redo it:
>That's why CONIKS was invented.
https://blog.okturtles.com/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/
>>10598
>According to you gpg,tls, tor , and air gapping (all industry standard) are all bad.
I haven't said that. Don't try to control the dynamics of my rhetoric so you can convince dumb people to use your shitty scripts.
I haven't said OpenPGP doesn't work. I've said it's a 90's idea, that got superseded by new ideas. I haven't said TLS and Tor don't work, I have said that if your (P)RNG is broken then any crypto will work. Last, I haven't said Air-gapping don't work and I don't even need to argument that, because you just have to read is said above.

>>10599
From EFF SMS:
>"Cryptocat was removed as the service has been suspended."
Can't be good.
https://www.eff.org/node/82654


Anonymous 08/08/2017 (Tue) 13:57:32 [Preview] No. 10606 del
How does WireGuard compare to OpenVPN?


Anonymous 08/08/2017 (Tue) 14:19:36 [Preview] No. 10607 del
Ok, so after reading for a few hours and going on the basis I got this meta-view:
- Most of the strong-crypto messengers uses Double Ratchet
- Signal protocol is the most well developed (so far). It has specifications and is developed/tested by many respected people.

Some software and notes about them (I'll just note about desktop clients, since smartphone is cancer and should not be used anyway):

- Signal: very good security (on protocol-side, it's the best option now). Has a unofficial cli client, but is written in Java. The official desktop client is bloated as fuck and has no privsep (as far as I know). Uses XMPP servers (very bad, from my perspective). Not on Tor by default. Leaks metadata.

- OMEMO: an implementation of signal protocol. Same issues as above, minus all the benefits (auditing). Can't see way use it, unless some good CLI client implementation rise from it's community

- Matrix: experimental, but has a solid foundation protocol. Many respected people are starting to advocate for it. It's in development, though, and the only client (Riot) is not capable of doing much.

- Wire: seems good, based on signal protocol principles. Written in Haskell (yuuhay). The UNIX client is in development [2]. Though: It's not really distributed, has no privsep, the GUI seems bloated as fuck too, no Tor by default, leaks metadata.

- Ricochet: weak crypto, but leaks very few metadata. No privsep, bloated GUI.

- Tox: I have no formed opinion on it. Have no specification as Signal protocol and leaks metadata. Can't see way use it, unless you want an alternative to Signal.

- Briar Project: still in beta, but will probably replace Ricochet (I hope so). Has better crypto. Same problems: no privsep and bloated gui



My conclusion for now (I'm not an expert, take it as an opinion): text through Ricochet, Signal for image/video; wait for Briar.

Being idealist, someone will develop a software in next decade that works on mesh anonymous P2P, based on Signal Protocol/ZKP/CONIKS[3], using PQcrypto, that has formal proofs/verification, good coding security (safe language, capability-based, strong isolation, privsep, W^X, encrypt database by default, etc), that leaks no metadata and have no bloated interface.
But... I'm being idealist :^)


[1] https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm
[2] https://github.com/wireapp/wire-desktop
[3] https://coniks.cs.princeton.edu/


Anonymous 08/08/2017 (Tue) 14:25:14 [Preview] No. 10608 del
>>10606
You're talking about apples and oranges.
OpenVPN uses weak cryptography through TLS and has a bloated and insecure implementation.
WireGuard uses formally verified protocols, with good coding practices.
Where you can, use WireGuard. It's the "next big thing" on secure VPN, no other software is better than WG (so far) if you can sacrifice flexibility for real secure software, not even OpenIKED.


Anonymous 08/08/2017 (Tue) 21:44:59 [Preview] No. 10617 del
(3.38 MB 480x270 olympicvomiting.gif)
>>10606
>>10608

>WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come.


Anonymous 08/08/2017 (Tue) 21:58:40 [Preview] No. 10619 del
>>10617
See this:
https://www.wireguard.com/formal-verification/

They're being conservative and/or they did not updated the website since the formal proofs came out.


Anonymous 08/08/2017 (Tue) 22:18:18 [Preview] No. 10621 del
>>10619
The protocol has been verified. The code has not.

You are doling out dangerous advice.

Once again:

>WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come.

From their own homepage.

I recognize you and your obsession with formal verification. If you think it's so important, you should at least learn enough about it to be able to understand what's being verified and what that means.


Anonymous 08/08/2017 (Tue) 22:28:46 [Preview] No. 10622 del
>>10619
>>10621

BTW, the TLS protocol (which is what OpenVPN uses) has also been formally verified with Tamarin, just like the Wireguard protocol.

https://tamarin-prover.github.io/manual/book/001_introduction.html

So, if your criterion for judging the security of a piece of VPN software is that the protocol it uses has been formally verified with Tamarin, then Wireguard and OpenVPN are equivalent, by your measure.


Anonymous 08/08/2017 (Tue) 22:44:42 [Preview] No. 10623 del
>>10621
I know what's being verified.
>It has not undergone proper degrees of security auditing
>proper degrees
I would rather suggest this software than OpenVPN or other experimental things (like cypherpunks GoVPN). The main VPN software I recommend is OpenIKED, but haven't seem so much development (last commit on reyk@ github is from 2015). It also relies on IPsec, and there's some informations from Bruce Schneier that IPsec has been engineered by NSA to be weak.

WireGuard it's also very small (4000LOC)and easy to audit (since it already has specifications and formal proof of the protocol). Related [1].

You have other alternative, that has security auditing?

I do agree, though, that my affirmation above is misinformed, although I've not said that it "has proper auditing" in first place.


ps. yes, I'm obsessed with formal methods.


[1] https://news.ycombinator.com/item?id=11996201


Anonymous 08/08/2017 (Tue) 22:49:38 [Preview] No. 10624 del
>>10622
Good point. Except that TLS is shit.


Anonymous 08/08/2017 (Tue) 23:32:47 [Preview] No. 10625 del
>>10623

>I know what's being verified.
You do now, because I explained it to you. It's very clear from your previous post that you didn't before, when you were saying that the developers' warning about the WIP state of the code was outdated "since the formal proofs came out."

You consistently misunderstand security topics. Like forward security earlier in the thread. I remember our conversations many months ago where you made similar mistakes.

There's nothing inherently wrong with making innocent mistakes. We're only human, after all. The problem is that you go on to make questionable recommendations based on your incomplete or inaccurate understanding of what you're talking about. Like recommending Wireguard when its own developers warn, with emphasis, not to rely on it right now.

You need to up your game if you're going to be in the habit of making recommendations like you do.


Anonymous 08/09/2017 (Wed) 00:16:16 [Preview] No. 10626 del
>>10625
>The problem is that you go on to make questionable recommendations based on your incomplete or inaccurate understanding
Good point. I've never said I'm an expert (actually I pointed I'm not on >>10607).

Ok, now let's keep the thread on track.


Endwall 08/09/2017 (Wed) 04:01:00 [Preview] No. 10631 del
Reop
Reasonable Expectation of Privacy
http://www.tedunangst.com/flak/post/reop

https://www.tedunangst.com/flak/files/reop-2.1.0.tgz

https://www.tedunangst.com/flak/files/reop-3.0-snapshot.tar.gz

Developed on OpenBSD. Uses libsodium.

Development is now halted. Fixing the remaining problems is quite challenging to do securely. A future better version of reop would be incompatible with existing releases. (This doesn’t mean they are insecure, just that the design doesn’t accommodate new features easily.) The current release accomplishes what I set out to accomplish. With that in mind, I think it’s best to stop here. Maybe someday I’ll give it another go, but for now, adios. Posted 2014-04-01 12:32:27 by tedu Updated: 2015-09-08 18:19:18


Endwall 08/09/2017 (Wed) 04:09:24 [Preview] No. 10632 del
>>10631
http://www.tedunangst.com/flak/post/reop
" limitations There’s no support for key revocation, or long chains of certificates, or partial trust, or key servers. For the most part, I think this is feel good wankery that doesn’t accomplish as much as one would like. I wonder how many people have ever revoked their PGP keys to see how it works in practice. The reop trust model is very simple. You can probably even understand it. Keys don’t expire. If we expand the scope of inquiry slightly to TLS certs, I’ve lost count of the problems I’ve seen caused by prematurely expiring certs. Number of times an expired cert has saved my ass? Zero. This is arguably shortsighted, I know. You can’t embed a JPG selfie into reop keys. Not even a tiny one. reop doesn’t include a Tempest resistant font for viewing top zecret messages. "


Endwall 08/09/2017 (Wed) 04:17:09 [Preview] No. 10633 del
REOP
$ mkdir -p ~/src/
$ cd ~/src/
$ endget https://www.tedunangst.com/flak/files/reop-3.0-snapshot.tar.gz
$ tar -xvf reop-3.0-snapshot.tar.gz
$ cd reop
$ ./configure
$ make
$ ./reop --help
$ cd ~/bin
$ ln -s ~/src/reop/reop reop
$ reop --help


Anonymous 08/09/2017 (Wed) 04:21:00 [Preview] No. 10634 del
>>10631
>Development is now halted
Yes, the he already accomplished what he wanted. Differently from OpenSMTPD, where I used the argument about unmaintained code, reop is really simple and does nothing but to be a interface for libsodium.
>limitations
All the limitations is on asymmetric encryption. I'm not suggesting use it for this, I'm suggesting use it only for symmetric encryption (AES256).


Endwall 08/09/2017 (Wed) 04:30:08 [Preview] No. 10635 del
REOP
Generate a key pair
$ cd ~
$ mkdir -p crypto
$ cd crypto
$ mkdir -p reop
$ cd reop
$ pwd
$ ~/crypto/reop
$ reop -G -i endwall -p endwall_reop.asc -s endwall_reop.key
Enter a passphrase:

Open new window
$ passgen --bytes 33

Enter a passphrase:
Confirm passpharse:

$ ls
endwall_reop.asc endwall_reop.key

$ cat endwall_reop.asc
-----BEGIN REOP PUBLIC KEY-----
ident:endwall
RWRDUz2hYCKPSkvmTHOjvELRrb9aW553ihvqAdkEp4DsVunupcIWFvn8N60ZX/acw4tfXqsnS1+O
9kMAHxwyAJKYrEGIaGP7ODKtQg==
-----END REOP PUBLIC KEY-----


Anonymous 08/09/2017 (Wed) 04:56:52 [Preview] No. 10636 del
>>10634

>I'm not suggesting use it for this, I'm suggesting use it only for symmetric encryption (AES256).

In that case, why bother using reop at all? There are dozens of tools that do AES256 encryption. Most Linux distros have at least 2 of them installed by default.


Endwall 08/09/2017 (Wed) 05:03:01 [Preview] No. 10637 del
REOP
encrypt / decrypt
$ reop -E -i endwall -p endwall_reop.asc -m message.txt
passphrase:
$ ls
endwall_reop.asc endwall_reop.key message.txt message.txt.enc

$ reop -D -i endwall -p endwall_reop.asc -s endwall_reop.key -m message.dec -x message.txt.enc
passphrase:
reop: no seckey

Well this is so simple that I can't figure it out yet...

Usage:
reop -G [-n] [-i identity] [-p public-key-file -s secret-key-file]
reop -D [-i identity] [-p public-key-file -s secret-key-file]
-m message-file [-x ciphertext-file]
reop -E [-1b] [-i identity] [-p public-key-file -s secret-key-file]
-m message-file [-x ciphertext-file]
reop -S [-e] [-x signature-file] -s secret-key-file -m message-file
reop -V [-eq] [-x signature-file] -p public-key-file -m message-file

$ reop -D -p endwall_reop.asc -s endwall_reop.key -m message.dec -x message.txt.enc
passphrase:
reop: no seckey

What am I missing here?

STATUS: ENCRYPTS DOESN'T DECRYPT

I'll try this again from scratch.


Endwall 08/09/2017 (Wed) 05:21:08 [Preview] No. 10639 del
>>10637

This works:

$ reop -E -i endwall -p ~/.reop/pubkey -m message
passphrase:
$ ls
message message.enc
$ reop -D -p ~/.reop/pubkey -m decrypt -x message.enc
passphrase:
$ ls
message message.enc decrypt

This doesn't work the way that it is suggested on the web page.

$ reop -D -m decrypt -x message.enc
reop: no pubkey

Probably some environment variable not being set properly.

Interesting, might be useful but doesn't replace gpg.
Thanks for the tip.


Anonymous 08/09/2017 (Wed) 07:07:57 [Preview] No. 10641 del
>>10636
>Most Linux distros have at least 2 of them installed by default.
Care to tell me what are these tools?
There's none, besides openssl shit. Veracrypt is not default.
reop is a very simple command line software and uses a very tested crypto library.

Why I'm still discussing with you, really? All your comments seems like a markov-chain bot. You spammed all this thread with unrelated content. You fail to read and interpret what I'm saying (ironically, logics is the basis of what we're talking here).
Stop, please. You're destroying this board without even realizing (assuming you're human and not software). Your spam makes me want to isolate myself, so I don't bother anymore talking here or in any other imageboard. You're distracting people from the main point and spreading misinformation. Actually, this is one well know technique from security agencies, a kind of "astroturfing" to deliberately destroy the main discussion.


Anonymous 08/09/2017 (Wed) 07:53:12 [Preview] No. 10642 del
(652.54 KB 500x265 1497138772683.gif)
>>10641

>Care to tell me what are these tools?
>There's none,
Wrong again. OpenSSL and gpg.

>besides openssl shit.
OpenSSL has certainly had problems over the years. However, we're not talking about OpenSSL as a whole, we're talking about it simply in terms of performing AES-256 encryption in the same manner that reop does.

So please provide a critique of this specific functionality of OpenSSL. Specific examples from the relevant source code will be necessary.

Re: the rest of your post: If you can't tell from this post and the one to which you replied that I'm a human being, you need to get evaluated for autism. I'm not saying that as an insult. I'm serious.


Anonymous 08/09/2017 (Wed) 21:29:59 [Preview] No. 10647 del
>>10642
>you need to get evaluated for autism.
You seem to be a human. This >>10590 don't.


Anonymous 08/09/2017 (Wed) 22:56:08 [Preview] No. 10653 del
(96.93 KB 498x750 1496984509055.jpg)
>>10647
I'm flattered that you recognize my humanity.

>>>10590 don't
But you accused my post >>10636 of having been written by a "markov-chain bot". I didn't write >>10590 and you can clearly see a name attached to that post.


Anonymous 08/13/2017 (Sun) 17:14:39 [Preview] No. 10710 del
So why is reop better again ? Because I did not understand anything from you guys shitposting.


Anonymous 08/13/2017 (Sun) 20:29:46 [Preview] No. 10711 del
>>10710
Advantages:
- Simple code. No bloat. Do one thing and do it right (unix philosophy)
- Good security practices (no unnecessary permissions)
- Uses libsodium, a modern and stable crypto lib with well revised code. Uses AES-256.
- Leaks less metadata on pubkey
- Smaller pubkey.

I think they also have added pledge(2) to the reop ports on openbsd.

Disadvantages:
- No support for GUI tools, like for Thunderbird
- No support anywhere, really
- It's not maintained anymore (not exactly a problem, because the code is considered "done" by the author. No bugs found)
- Not audited by third-party


I personally think it's a good alternative to GnuPG, because of all the advantages above. If anyone (my antagonist) wants to point other disadvantages, welcome.


Anonymous 08/13/2017 (Sun) 21:18:57 [Preview] No. 10712 del
>>10711
Ohh cool. Thanks for making a summary.


Anonymous 08/14/2017 (Mon) 15:19:03 [Preview] No. 10715 del
(595.36 KB 1306x1691 1491460607843.jpg)
>>10710

>So why is reop better again ?

It's not. It's abandonware that nobody gives a shit about. Nobody uses the public-key functionality of reop, and the AES-256 functionality is redundant. There are plenty of options for AES-256 encryption on common operating systems that are either already available, or can be readily installed without having to compile from scratch (unlike reop).

The one person on this board (and on the planet) shilling reop was challenged to demonstrate the superiority of reop's AES-256 functionality against other implementations by referencing the relevant source code, but he failed to do so.


Anonymous 08/15/2017 (Tue) 02:52:42 [Preview] No. 10723 del
(736.54 KB 1280x640 1471700571618.png)
>>10720

There's nothing in that list about the gnupg implementation of AES-256 file encryption or the reop implementation of AES-256 file encryption.

The one person on this board (and on the planet) shilling reop was challenged to demonstrate the superiority of reop's AES-256 functionality against other implementations by referencing the relevant source code, but he failed to do so. Again.

If you are having difficulty locating the source code in question, I would be happy to provide you with a link. Just say the word!

Also, although it doesn't matter, because that link demonstrates absolutely nothing that's relevant to this discussion, I would note that that list goes back 11 years and has only one critical (remote) bug.

I'd call that "Only one remote hole in the default install, in a heck of a long time!" Hmm, that sounds familiar.



Top | Return | Catalog | Post a reply