mykhal

oh, https://news.ycombinator.com/item?id=14207815

This doesn't work yet. But when it does, you'll need recent firmware from the Raspberry Pi Foundation git repository

/me done. finally.

fixing this one https://news.ycombinator.com/item?id=10232282

regarding to excessive amount of required permissions, and the fact that contact == phone number, for now i am preferring ChatSecure.

o@puffy$ mg<Ret>M-x theo<Ret><Ret><Ret>...

an attacker might already have stolen his keys (why only one?), because the script checksums do not match :)

The title had to be shortened, was:

  Romantic Cryptography, i.e. how to say "I love you" but only if the other person is going to say "me too"

now i found out that the article was published in the Journal of Craptology:

  http://www.anagram.com/jcrap/Volume_7/

XOF, nice.. but what is the point of expanding SHAKE256 to e.g. 4096 bits, if its security remains 256 bits ?

recap: http://keccak.noekeon.org/fips202final.html

Nice, but I bet nobody is currently able to write there a proof for

  $\Re(s) = \frac{1}{2}$ for all s where $\zeta(s) = 0$ and $0 < \Re(s) < 1$

s/old/recent/

from test/verify_extra_test.c:

    Test for CVE-2015-1793 (Alternate Chains Certificate Forgery)
   
    Chain is as follows:
   
    rootCA (self-signed)
      |
    interCA
      |
    subinterCA       subinterCA (self-signed)
      |                   |
    leaf ------------------
      |
    bad
   
    rootCA, interCA, subinterCA, subinterCA (ss) all have CA=TRUE
    leaf and bad have CA=FALSE
   
    subinterCA and subinterCA (ss) have the same subject name and keys
   
    interCA (but not rootCA) and subinterCA (ss) are in the trusted store
    (roots.pem)
    leaf and subinterCA are in the untrusted list (untrusted.pem)
    bad is the certificate being verified (bad.pem)
   
    Versions vulnerable to CVE-2015-1793 will fail to detect that leaf has
    CA=FALSE, and will therefore incorrectly verify bad

Changes between 1.0.2c and 1.0.2d [9 Jul 2015]

  *) Alternate chains certificate forgery

     During certificate verfification, OpenSSL will attempt to find an
     alternative certificate chain if the first attempt to build such a chain
     fails. An error in the implementation of this logic can mean that an
     attacker could cause certain checks on untrusted certificates to be
     bypassed, such as the CA flag, enabling them to use a valid leaf
     certificate to act as a CA and "issue" an invalid certificate.

     This issue was reported to OpenSSL by Adam Langley/David Benjamin
     (Google/BoringSSL).
     [Matt Caswell]

WTF? am I still at HN?

unfortunately, it is annoyingly orthographic, no perspective.. :)

slightly off topic:

  $a = "DjBlYVWap4fQC8b3C73+NATPA2We"."c"."E+FNMAP+2WcTIdAzJQv6y2hFaP0F"."V"."y7hgdJc4ZlbX0fNKQgWdePWo3R7w";
  $b = "DjBlYVWap4fQC8b3C73+NATPA2We"."d"."E+FNMAP+2WcTIdAzJQv6y2hFaP0F"."d"."y7hgdJc4ZlbX0fNKQgWdePWo3R7w";
  var_dump($a === $b); // false
  var_dump(md5(base64_decode($a)) === md5(base64_decode($b))); // true

it's not _that_ broken

i you're lonely, just M-x theo ^M ^M ^M ...

ADF (acronym design failure)

more relevant link: https://archive.today/odPyB

bullshit

i think that Terminus is yet bester

s/Search/Eval/

g search is occasionally failing with HTTP 500, in CZ

yet another interesting project from libya..

https://news.ycombinator.com/item?id=7902924

why would anyone in the unicode age have to shorten the urls? (:

duplicity (https://news.ycombinator.com/item?id=7736739)

numerology is not my cup of tea.