Чот проигрываю с чуханов, обсирающих телеграм, но не использующих свой собственный жабер сервер.

Бля, заебало в каждой вкладке терминала набирать свой 15-символьный пароль.
Нет ли никакого system-wide говна, которое бы просило меня это делать только раз в N минут?

крч, короткий мануал по pgp в картинках для самых молодых пользователей.
http://cdn.syn-ch.com/src/144/31/26/1443126467-89e89.pdf

YAY, чо обещают на black hat в августе:

In x86, beyond ring 0 lie the more privileged realms of execution, where our code is invisible to AV, we have unfettered access to hardware, and can trivially preempt and modify the OS. The architecture has heaped layers upon layers of protections on these negative rings, but 40 years of x86 evolution have left a labyrinth of forgotten backdoors into the ultra-privileged modes. Lost in this byzantine maze of decades-old architecture improvements and patches, there lies a design flaw that's gone unnoticed for 20 years. In one of the most bizarre and complex vulnerabilities we've ever seen, we'll release proof-of-concept code exploiting the vast, unexplored wasteland of forgotten x86 features, to demonstrate how to jump malicious code from the paltry ring 0 into the deepest, darkest realms of the processor. Best of all, we'll do it with an architectural 0-day built into the silicon itself, directed against a uniquely vulnerable string of code running on every single system.

https://www.blackhat.com/us-15/briefings.html#the-memory-sinkhole-unleashing-an-x86-design-flaw-allowing-universal-privilege-escalation

По слухам, в whatsapp впилят секретные чаты.
Скажите мне, что это даст кроме ублажения хомячков?
Ведь, если сорцы закрыты, то доказать что whatsapp не содержит закладок, которые будут открывать side channels и сливать переписку куда надо, будет крайне сложно.

На что они расчитывают, собственно?

Короче зашел от негего делать сюда http://youbroketheinternet.org/secure-email
и почитал там про Pond.

С виду заебись: юзается Axolotl, (значит там PFS). Работает строго через tor.
Есть рабочий клиент на Go.
Скомпилилось/запустилось все быстро и без особых проблем.

Спама там быть не может в принципе, так обмен сообщениями осуществляется только после обмена ключами (рекомендуется shared secret)
Из спорных моментов видится, разве что, клиент-серверная модель.

Затестить хочет кто-нибудь?

Practical Attacks Against The I2P Network
http://wwwcip.informatik.uni-erlangen.de/~spjsschl/i2p.pdf

Насколько это статья актуальна сейчас?
Все ли уязвимости пофикшены?

Предлагаю в этом треде обсудить textsecure.
Требования - бесплатный, опенсорсный мобильный месенджер с пушами, офлайновой доставкой, групчатами, который разрабатывают специалисты в области ИБ (а не всякие олимпиадники с NIH головного мозга).

Собственно, больше мобильных месенджеров, подпадающих под эти требования я не нашел (поясните за chatsecure, кстати).

Протокол, похож на OTR, но есть отличия:
* Не используется отдельный шаг для advertising-а ключей.
* Предусматривает потерю и доставку out-of-order сообщений. Для этого используется специальный ratcheting, позволяющий расшифровать любое сообщение при обрыве message chaining, но с сохранением PFS
* Есть нормальные (не mpOTR) групчаты, где сообщение шлется каждому из N собеседников. Есть некоторые оптимизации, чтобы сократить на больших сообщениях, содержащие картинки/аудио etc. В этом случае сообщение шифруется симметричным эфемерных ключом, этот ключ шифруется публичным ключом собеседника и на сервер шлется один шифротекст сообщения и N шифрованых симметриынй ключей на каждого адресата.

Для пушей используются гугловые и эпловские пушсервисы. Сообщения там не передаются, они юзаются строго для вейкапа трубки, которая полезет на сервер за сообщениями.

Недостатки:
* (пока) нет децентрализованности серверов (хотя сорцы сервера открыты);
* малофичатстый клиент по iOS;
* нет клиента под PC (хотя что-то для браузеров);
* используются номера телефонов для авторизации (обещают туда прикрутить имейлы). Параноики могут создать номер через google voice и авторизоваться голосом;
* невозможно объединить несколько девайсов в один identity;
* нельзя выбрать фоновую картинку для чата.

Нужно заметить, что недостатки не вызваны какими-то недостатками в протоколе (здесь уместно вспомнить tox), а скорее ограниченностью в ресурсах.

Repost, share, renbnweet.

Кто-нить ricochet тыкал?
Как оно?

Поставил GNU freenet.
Чувствую себя как в конце нулевых когда search engines еще не захватили мир.

В вашем текстовом недоредакторе можно сохранить файлик с расширением gpg, который
автоматически будет зашифрован симметричным ключом и дешифрован при последующем
отркытии?

Reconstruction of FrameBuffers from VRAM

This document describes a method of reading and displaying previously used framebuffers from a variety of popular graphics cards. In all 4 tested laptops the content of the VRAM was not erased upon reboot. It is also possible to show that the content of the host VRAM can be accessed from a VirtualBox guest, thereby leaking possibly confidential information from a trusted host into an untrusted guest machine.

https://ssl.opennet.ru/opennews/art.shtml?num=41902

Exploiting the DRAM rowhammer bug to gain kernel privileges
http://googleprojectzero.blogspot.ru/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.

https://www.pgpru.com/novosti/2015/prodemonstrirovanoispoljzovanieujazvimostivdrampamjatidljapovyshenijaprivilegijjvsisteme

нихуясебе

Как вы живете с тем, что любой юзерспейсный кусок говна, запущеный от имени юзера может сдампить весь экран целиком?

Почему никто еще не придумал аналог btsync, который бы умел нативно синкать/мержить между собой криптоконтейнеры?
Все-таки всякие ecrpytfs слегка посасывают при синке через btsync.

YAY, распределенные файловая система будущего.
https://www.tahoe-lafs.org/trac/tahoe-lafs
https://www.tahoe-lafs.org/~trac/LAFS.svg

Естессно, все шифруется на стороне клиента, чтобы service provider не смог ничего прочитать.
Даже есть веб-ебло на питушоне

1. Договариваешься с N друзьями.
2. Поднимаете это говно
3. ...
4. Спокойное аутирование

Шекурный (по заверениям) жабер сервер с зеркалом в tor.
https://securejabber.me/

Из битемаджего [chan] privacy:
Truecrypt certainly is better than notusing encryption at all. If you want whole disk encryption look into dm-crypt, else veracrypt/gostcrypt or GPG will do fine.

If you really are concerned about backdoors that much I like to show you the following:

Ever heard of intrinsics? It's about using hardware-implemented functions. To see what intrinsics your processor supports run "cat /proc/cpuinfo" (on unix-systems).

Intel processer povide intrinsics for AES and if you have a modern computer with an intel cpu, you are sure to have those intrinsics. And openssl happily uses these intrinsics per default. Here is a minor problem:

If you know how AES works, you know that encryption and decryption take the same amount of work. When using the openssl functions for AES encryption (not the ones which use intrinsics!!!) however, encryption can take roughly twice as long as decryption. now let's look at the intrinsic: If you benchmark those functions you'll notice that encryption takes waaayyy too long compared to decryption.

Of course that doesn't proove that there's a backdoor, but if you have sensitive information whiches security is in your hands, you should keep the above information in mind.

If you use veracrypt, you will have options available to disable intrinsics. To my knowledge, dm-crypt uses intrinsics per defualt. Feel free to run cryptsetup benchmark.

If you want to be sure that there is no hardware backdoor, I suggest you use an uncommon cipher such as serpent that have no intrinsics available. Keep in mind that doesn't make https and gpg magically stop using AES. I will yet have to find out myself how to disable intrinsics in dmcrypt and openssl and would be most grateful if someone on BM could post the answer.

KISS:
If you handle very sensitive stuff, make sure you do not use intrinsics. And don't forget to airgap your machine.
For personal use, veracrypt (and in my point of view truecrypt too, correct me if I'm wrong) are most suitable and I enjoy the acceleration provided by intrinsics.
Though to make it harder for NSA to spy on you and learn something new, feel free to do some custom stuff such as a hardware number generator or a seperately encrypted container for your personal keys.

Here are my sources:
http://www.ct.de/cs1403154
https://en.wikipedia.org/wiki/AES_instruction_set
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
[feel free to add more, such as sources direct from openssl]
[maybe someone could provide more details about backdoors in instruction sets]