Constantine A. Murenin
Bob Beck gives a 30-day status update on LibreSSL at BSDCan in Ottawa

Bob Beck — OpenBSD, OpenSSH and LibreSSL developer and the director of Alberta-based non-profit OpenBSD Foundation — gave a talk earlier today at BSDCan 2014 in Ottawa, discussing and illustrating the OpenSSL problems that have led to the creation of a big fork of OpenSSL that is still API-compatible with the original, providing for a drop-in replacement, without the #ifdef spaghetti and without its own “OpenSSL C” dialect.

It is suggested that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that noone at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL’s RT some 4 years prior).

Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL.

It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, EC FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley’s Chromium OpenSSL patchset.

To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment — Linux Foundation is turning a blind eye to LibreSSL, and instead ishas “not yet committed to support us”, and has so far only committed to funding OpenSSL directly, despite the apparent lack of security-oriented direction within the OpenSSL project upstream. Funding can be directed to the OpenBSD Foundation.

Slashdot | Lobsters | SoylentNews


OpenBSD 5.5 Released

As per the schedule, OpenBSD 5.5 was released today, May 1, 2014.

The theme of the 5.5 release is Wrap in Time, which represents a significant achievement of changing time_t to int64_t on all platforms, as well as ensuring that all of the 8k+ OpenBSD ports still continue to build and work properly, thus doing all the heavy lifting and paving the way for all other operating systems to make the transition to 64-bit time an easier task down the line.

Signed releases and packages and the new signify utility are another big selling point of 5.5, as well as OpenSSH 6.6, which includes lots of DJB crypto like chacha20-poly1305, plus lots of other goodies.


OpenSSH теперь можно собрать без OpenSSL

Разработчики OpenSSH уже давно планировали отказаться от libssl зависимости в ssh, ещё до недавнего обвала OpenSSL.

Благодаря алгоритмам тов. D.J. Bernstein, которые теперь являются частью OpenSSH 6.5 и 6.6, теперь это будет более возможно в предстоящем OpenSSH 6.7.

На днях, в Makefile.inc проекта OpenSSH была добавлена опция OPENSSL (для `make OPENSSL=no`), которая теперь позволит собирать OpenSSH исключительно с поддержкой SSH-2 и минимальным набором из встроенных шифров — AES-CTR и chacha20+poly1305 для шифрования данных, ECDH/curve25519 для обмена ключами и Ed25519 для самих ключей. Изменения скорее всего будут доступны в следующем релизе (т.е. в OpenSSH 6.7).

https://www.linux.org.ru/news/security/10440902

OpenSSH no longer has to depend on OpenSSL

What has been planned for a long time now, prior to the infamous heartbleed fiasco of OpenSSL (which does not affect SSH at all), is now officially a reality — with the help of some recently adopted crypto from DJ Bernstein, OpenSSH now finally has a compile-time option to no longer depend on OpenSSL — `make OPENSSL=no` has now been introduced for a reduced configuration OpenSSH to be built without OpenSSL, which would leave you with no legacy SSH-1 baggage at all, and on the SSH-2 front with only AES-CTR and chacha20+poly1305 ciphers, ECDH/curve25519 key exchange and Ed25519 public keys.

slashdot | lobsters


OpenBSD производит массовый аудит и переработку OpenSSL — libreSSL

В свете недавней очень серьёзной уязвимости Heartbleed протокола Heartbeat в сторонней библиотеке OpenSSL, разработчики OpenBSD решили окончательно и бесповоротно переписать всю библиотеку SSL, удалив груду разных кодов совместимости и поддержки несуществующий архитектур (например, big-endian i386/amd64), сохранив лишь API-совместимость с upstream OpenSSL.

Данное начинание некоторые временно называли OpenOpenSSL (т.к. оригинальный OpenSSL разрабатывается вне OpenBSD), но OpenBSD Foundation теперь объявило официальное название — «LibreSSL (the OpenBSD fork of OpenSSL)». Название также можно воспринимать как «lib-re-ssl» — переработка библиотеки ssl.

Что именно принудило проект OpenBSD отказаться от какого-либо сотрудничества с OpenSSL в будущем? Разработчик tedu@openbsd решил описать историю нового libressl на свежую память:

* Протокол Heartbeat никто до сих пор не использует, однако он был всегда включён с момента поддержки в OpenSSL пару лет назад, и его нельзя было выключить без перекомпиляции с OPENSSL_NO_HEARTBEATS. (Поддержка теперь была полностью удалена из OpenBSD libressl.)

* Предполагалось, что для избежания Heartbleed на OpenBSD достаточно будет установить опцию J в malloc.conf. Однако разработчики OpenSSL специально позаботились и сделали это невозможным, и поэтому даже на OpenBSD необходимо пересобирать всю библиотеку для устранения серьёзной уязвимости Heartbleed (в 5.3, 5.4 и 5.5, OpenSSL 1.0.0f в 5.2 и ранее не уязвим).

* В процессе тестирования опции J с OpenSSL была обнаружена старинная ошибка в OpenSSL, о которой уже несколько лет было известно разработчикам OpenSSL, и даже имелось очень простое исправление. Однако разработчики OpenSSL до сих пор не приняли это к сведению. Командам OpenBSD, FreeBSD и Debian пришлось исправлять ошибку без какой-либо помощи от OpenSSL. Пару недель спустя, в upstream CVE-2010-5298 до сих пор исправить не удосужились.

Так как сотрудничество с таким upstream нереально и в дальнейшем не предполагается, было принято решение улучшить читаемость всего кода в соответствии с style(9) — KNF, а также удалить весь неиспользуемый код для упрощения аудита. В будущем планируется выпуск портативной версии, после периода стабилизации.

»> http://BXR.SU/OpenBSD/lib/libssl/src/ssl/

http://www.linux.org.ru/news/bsd/10412863


My experience trying to become an AIO Wireless customer

AIO Wireless (AT&T wholly-owned subsidiary) doesn’t ship SIM Kits to PO Boxes, and doesn’t let you have a separate shipping and billing address (unlike StraightTalk and T-Mobile US).

I’ve tried making an order with just my shipping address in the billing/shipping field, and it didn’t succeed. I then changed my address with my bank to what I need my shipping address to be, tried making the order again, but it still didn’t succeed.

I called Capital One, the bank for my World MasterCard, was connected to Craig in Richmond, VA, who’s been with Capital One for 4 years, and he has ensured my address is all changed up and correct, yet the order would still not go through on aiowireless.com, persistently giving out the "Credit Card address Is Invalid" error.

Craig of CapitalOne was kind enough to quickly suggest that he’d be very happy to call AIO to try to troubleshoot the ordering or complete the order on the phone. He found AIO’s 855 number on their web-site quickly, and proceeded with the call.

After some delay of Craig setting it up, the AIO representative with a strong developing-world accent joined us both on the line. He proceeded with asking me for my phone number. It made no sense, but since AIO asks for a first/last/email/phone upfront in the ordering process, I thought maybe that’s how they locate their records, so, I gave him my number. He said he cannot find it. Starts asking for my name.

It becomes obvious the AIO guy is somehow thinking I’m already a customer, even though it was clearly explained that I’m not. Craig apologises to me, assuring me that he did inform the AIO representative of what was going on.

Long story short, both me and Craig talked to the AIO guy in circles, trying to get to his supervisor (to which he repeatedly claimed that none is available), trying to see if there’s any way to complete the order and purchase the service. Apparently, the only thing AIO customer support can help you with is navigating their web-site, but how is that of any help when the said web-site doesn’t actually work?

I asked Craig if he could possibly believe that this company with a single powerless representative and no supervisors is actually a wholly-owned AT&T subsidiary! To which the AIO guy has immediately interrupted us, insisting that it’s not a subsidiary, but an independent company instead. “But who owns it?”, Craig volunteers to prove my point, to which the representative still insists its independent (not owned by anyone?).

I proceeded to ask where the AIO call centre we’re talking to is located. The AIO guy claimed he’s in Florida (generally, people have no problem admitting Philippines, Mexico or India, but not here). Craig asked where in Florida, to which we got no answer. To break the silence, Craig volunteers that he’s in Richmond, Virginia, which I have absolutely no trouble believing, but the AIO guy still persists he’s just in “Florida”.

At one point, Craig started being more proactive, and started asking who is responsible for troubleshooting web-site errors at AIO, and how can we get connected to such person; the “Florida” man started claiming that apart from him being the troubleshooter, it’s the store representatives that could also help. He suggested I give him my ZIP code, and he can locate me some AIO stores. I obviously knew there were no local stores, but gave him my ZIP anyways; he said there were no stores, and I should give him another ZIP. Craig, being almost like my buddy now, joked that I must have a whole bag of ZIP codes to just give away!

BTW, during the whole ordering process on the website (I’ve even tried it from two separate computers, and throughout my phone call; Capital One shows 8 pending transactions of 50,69 from AIO WIRELESS), not only was the order not accepted, but I’ve also noticed that if you try changing the Billing/Shipping address on the final page where you provide the credit card info, then the Total amount counts the sales tax twice. E.g. on the payment information page, with a 7% rate, the total is first reported as 50,69 after tax; however, editing the address results in a hike from 50,69 to 51,39 total (from 40 + 9,99 + 0,70 + 0,70).

And you thought StraightTalk customer service was bad…


HTTP/1.1 999 INKApi Error @ LinkedIn

A little while ago, I’ve noticed that all profiles, even those declared as being the public ones, have been blocked by LinkedIn, and instead the Join LinkedIn sign-up page shows up. I’ve finally got my way to troubleshoot this, after noticing that it appears to affect every single profile.

This is what I got:
~# curl -v www.linkedin.com/in/mureninc
* About to connect() to www.linkedin.com port 80 (#0)
*   Trying 216.52.242.80... connected
* Connected to www.linkedin.com (216.52.242.80) port 80 (#0)
> GET /in/mureninc HTTP/1.1
> User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6
> Host: www.linkedin.com
> Accept: */*
>
< HTTP/1.1 999 INKApi Error
< Date: Sun, 02 Mar 2014 22:13:56 GMT
< nnCoection: close
< Server: ATS
< X-Li-Pop: PROD-ELA4
< X-LI-UUID: mJPSLEvEVxMwm+37ACsAAA==
< Content-Length: 511
< Content-Type: text/html
< Set-Cookie: X-LI-IDC=C1
<
<html><head>
<script type="text/javascript">
window.onload = function() {
  var domain = document.domain;
  var newDomainIndex = 0;
  if (domain.substr(0, 6) == "touch.") {
    newDomainIndex = 6;
  }
  else if (domain.substr(0, 7) == "tablet.") {
    newDomainIndex = 7;
  }
  if (newDomainIndex) {
    domain = domain.substr(newDomainIndex);
  }
  window.location = "https://" + domain +  "/uas/login?trk=sentinel_org_block&session_redirect=" + encodeURIComponent(window.location);
}
</script>
</head></html>
* Connection #0 to host www.linkedin.com left intact
* Closing connection #0

(Notice that they cannot even spell their headers.)

There’s a thread over at developer.linkedin.com from Sept 2013, which probably sounds like about the same time I’ve started to notice the unavailability of the LinkedIn profiles; however, the linkedin engineers show a complete failure to grasp the issue people are having, let alone provide a reasonable solution. Keyword: LinkedIn sucks.

Apparently, this only happens from one of my IP-addresses at one provider (the IPv4 I’ve been using for years, and which surely doesn’t have any bots on it scraping LinkedIn), but not on others. The trk=sentinel_org_block part would seem to suggest that they simply block the whole net; so, if you want to scrap their whole web-site from your residential connection — feel free; but if you want to view a couple of pages a month from your dedicated static IPv4 at a data centre — too bad, you’re a scraping bot.


Straight Talk AT&T LTE, 2.11GB/13 days out of 2.5GB/30 days used


% time curl -A”Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36” -v www.google.com ; date
* About to connect() to www.google.com port 80 (#0)
* Trying 74.125.228.84… connected
* Connected to www.google.com (74.125.228.84) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36
> Host: www.google.com
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Server: WebProxy/6.0
< Date: Thu, 27 Feb 2014 02:28:27 GMT
< Content-Length: 0
< Location: http://1.2.3.50/throttle/setcookie.php?u=http%3a%2f%2fwww.google.com%2f
< Connection: keep-alive
<
* Connection #0 to host www.google.com left intact
* Closing connection #0
0.030u 0.010s 0:10.95 0.3% 0+0k 0+3io 0pf+0w
Wed Feb 26 21:28:36 EST 2014


% time curl -A”Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36” -v "http://1.2.3.50/throttle/setcookie.php?u=http%3a%2f%2fwww.google.com%2f" ; date
* About to connect() to 1.2.3.50 port 80 (#0)
* Trying 1.2.3.50… connected
* Connected to 1.2.3.50 (1.2.3.50) port 80 (#0)
> GET /throttle/setcookie.php?u=http%3a%2f%2fwww.google.com%2f HTTP/1.1
> User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36
> Host: 1.2.3.50
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Date: Thu, 27 Feb 2014 02:28:51 GMT
< Server: Apache/2.0.59 (Unix) PHP/5.2.1
< X-Powered-By: PHP/5.2.1
< Location: http://tft.tracfone.com/2p5
< Content-Length: 0
< Content-Type: text/html
< Connection: keep-alive
<
* Connection #0 to host 1.2.3.50 left intact
* Closing connection #0
0.010u 0.010s 0:00.52 3.8% 0+0k 0+2io 1pf+0w
Wed Feb 26 21:29:00 EST 2014


% time curl -A”Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36” -v "http://tft.tracfone.com/2p5" ; date
* About to connect() to tft.tracfone.com port 80 (#0)
* Trying 64.94.225.110… connected
* Connected to tft.tracfone.com (64.94.225.110) port 80 (#0)
> GET /2p5 HTTP/1.1
> User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36
> Host: tft.tracfone.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< Content-Type: application/xhtml+xml;charset=UTF-8
< Date: Thu, 27 Feb 2014 02:29:13 GMT
< Content-Length: 1169
< Connection: Keep-Alive
< Expires: Thu, 27 Feb 2014 02:34:14 GMT
<
* Connection #0 to host tft.tracfone.com left intact
* Closing connection #0
<?xml version=”1.0” encoding=”UTF-8”?><!DOCTYPE html PUBLIC “-//WAPFORUM//DTD XHTML Mobile 1.0//EN” “http://www.wapforum.org/DTD/xhtml-mobile10.dtd”><html xmlns=”http://www.w3.org/1999/xhtml”><head><title>TracFone Wireless, Inc.</title> <meta http-equiv=”Cache-Control” content=”no-cache”/><style type=”text/css”>img{vertical-align:middle;border-style:none;}.body{text-align:center;font:small Arial,Helvetica,sans-serif;background-color:rgb(255,255,255);margin:0;padding:0;}</style> </head><body class=”body”><img src=”http://1.1.1.1/bmi/cdn.3cinteractive.com/img/tracfoneO.jpg” height=”40”/><br /><br />You have been automatically redirected to this page because you have reached or exceeded 2.5 GB of high speed data usage during your current 30 day plan cycle. Your data will continue at a reduced speed for the remainder of your current 30 day plan. High speed data will be restored at the beginning of your next 30 day plan cycle.<br />Please see your Terms and Conditions of Service for further information.<br /><br /><a href=”javascript:history.go(-1)”>Click OK to continue,</a><br />you will be redirected back to the last page you were viewing. </body></html>
0.020u 0.000s 0:00.90 2.2% 0+0k 0+3io 0pf+0w
Wed Feb 26 21:29:23 EST 2014


% time curl -A”Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36” -v www.google.com ; date
* About to connect() to www.google.com port 80 (#0)
* Trying 74.125.228.81… connected
* Connected to www.google.com (74.125.228.81) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.105 Mobile Safari/537.36
> Host: www.google.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Vary: User-Agent
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: PREF=ID=f133229b1a5070a6:FF=0:TM=1393468288:LM=1393468288:S=hlIk-eay4HuoTnaw; expires=Sat, 27-Feb-2016 02:31:28 GMT; path=/; domain=.google.com
< Set-Cookie: NID=67=WTfuFemDXH7VjJz_W76ORdzdNX-bKnf5681fTBmVfQxD_GvIdB7zvhqtciHq33nB8Ug7bd2r6u5i5-gfagWo6QxlSCvzffNGk9Q9zTutLtaw0ClIzqS5otkUPfiby6EM; expires=Fri, 29-Aug-2014 02:31:28 GMT; path=/; domain=.google.com; HttpOnly
< P3P: CP=”This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.”
< Date: Thu, 27 Feb 2014 02:31:28 GMT
< Server: gws
< Cache-Control: private
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Alternate-Protocol: 80:quic
< Transfer-Encoding: chunked
< Expires: Thu, 27 Feb 2014 02:36:28 GMT
<
<

It would seem like the bandwidth throttling is somewhat intermittent:


% wget -4 -O /dev/null —progress=dot http://cachefly.cachefly.net/1mb.test ; date
—2014-02-26 21:35:29— http://cachefly.cachefly.net/1mb.test
Resolving cachefly.cachefly.net… 205.234.175.175
Connecting to cachefly.cachefly.net|205.234.175.175|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 1048576 (1.0M) [application/octet-stream]
Saving to: `/dev/null’

0K ………. ………. ………. ………. ………. 4% 145K 7s
50K ………. ………. ………. ………. ………. 9% 173K 6s
100K ………. ………. ………. ………. ………. 14% 216K 5s
150K ………. ………. ………. ………. ………. 19% 556K 4s
200K ………. ………. ………. ………. ………. 24% 357K 3s
250K ………. ………. ………. ………. ………. 29% 629K 3s
300K ………. ………. ………. ………. ………. 34% 602K 2s
350K ………. ………. ………. ………. ………. 39% 645K 2s
400K ………. ………. ………. ………. ………. 43% 559K 2s
450K ………. ………. ………. ………. ………. 48% 585K 2s
500K ………. ………. ………. ………. ………. 53% 656K 1s
550K ………. ………. ………. ………. ………. 58% 610K 1s
600K ………. ………. ………. ………. ………. 63% 112K 1s
650K ………. ………. ………. ………. ………. 68% 4.86M 1s
700K ………. ………. ………. ………. ………. 73% 44.0M 1s
750K ………. ………. ………. ………. ………. 78% 41.2M 1s
800K ………. ………. ………. ………. ………. 83% 45.1M 0s
850K ………. ………. ………. ………. ………. 87% 250K 0s
900K ………. ………. ………. ………. ………. 92% 120K 0s
950K ………. ………. ………. ………. ………. 97% 45.8M 0s
1000K ………. ………. …. 100% 53.4M=2.7s

2014-02-26 21:35:37 (373 KB/s) - `/dev/null’ saved [1048576/1048576]

Wed Feb 26 21:35:37 EST 2014

However, it is definitely there — speeds are no longer ~400KB/s, but are often only about ~40KB/s now:


% time wget -4 -O /dev/null —progress=dot http://cachefly.cachefly.net/1mb.test ; date
—2014-02-26 21:41:45— http://cachefly.cachefly.net/1mb.test
Resolving cachefly.cachefly.net… 205.234.175.175
Connecting to cachefly.cachefly.net|205.234.175.175|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 1048576 (1.0M) [application/octet-stream]
Saving to: `/dev/null’

0K ………. ………. ………. ………. ………. 4% 93.2K 10s
50K ………. ………. ………. ………. ………. 9% 198K 7s
100K ………. ………. ………. ………. ………. 14% 55.2K 10s
150K ………. ………. ………. ………. ………. 19% 53.0K 11s
200K ………. ………. ………. ………. ………. 24% 79.2K 10s
250K ………. ………. ………. ………. ………. 29% 44.4K 11s
300K ………. ………. ………. ………. ………. 34% 33.4K 11s
350K ………. ………. ………. ………. ………. 39% 44.6K 11s
400K ………. ………. ………. ………. ………. 43% 19.5K 12s
450K ………. ………. ………. ………. ………. 48% 24.9K 12s
500K ………. ………. ………. ………. ………. 53% 45.9K 11s
550K ………. ………. ………. ………. ………. 58% 29.1K 10s
600K ………. ………. ………. ………. ………. 63% 26.9K 9s
650K ………. ………. ………. ………. ………. 68% 31.3K 8s
700K ………. ………. ………. ………. ………. 73% 30.8K 7s
750K ………. ………. ………. ………. ………. 78% 38.6K 6s
800K ………. ………. ………. ………. ………. 83% 25.6K 5s
850K ………. ………. ………. ………. ………. 87% 46.1K 3s
900K ………. ………. ………. ………. ………. 92% 39.7K 2s
950K ………. ………. ………. ………. ………. 97% 46.8K 1s
1000K ………. ………. …. 100% 58.4K=27s

2014-02-26 21:42:12 (38.6 KB/s) - `/dev/null’ saved [1048576/1048576]

0.000u 0.010s 0:27.04 0.0% 0+0k 0+4io 0pf+0w
Wed Feb 26 21:42:12 EST 2014

Reception is either 1/4 bar LTE or 3/4 bar HSPA+.


OpenSSH 6.5 released (with lotsa D. J. Bernstein crypto)
OpenSSH 6.5 has been released, which is dubbed a feature release. It’s the first release with lots of D. J. Bernstein crypto in public domain (6.4 did not contain any DJB code whatsoever), from ChaCha20-Poly1305 stream cipher and MAC, to key exchange with Curve25519 (and a new private key format). The new key exchange is now the default (when supported by both sides), but the new transport cipher is an option. Additionally, the portable version has some extra code-hardening, and a switch to a ChaCha20-based arc4random() PRNG for platforms that don’t provide their own.

How are you supposed to read Tumblr&#8217;s Terms of Service?

1200×1920

How are you supposed to read Tumblr’s Terms of Service?

1200×1920