• Breaking News

    Tuesday, April 30, 2019

    Home Unlabelled Cryptography Programmers solve MIT’s 20-year-old cryptographic puzzle

    Cryptography Programmers solve MIT’s 20-year-old cryptographic puzzle

    April 30, 2019

    Cryptography Programmers solve MIT’s 20-year-old cryptographic puzzle

    Programmers solve MIT’s 20-year-old cryptographic puzzle

    Posted: 29 Apr 2019 02:21 PM PDT

    Extract PGP secret keys from Gnuk / Nitrokey Start firmwares

    Posted: 29 Apr 2019 10:20 AM PDT

    If some of you are using a Nitrokey Start or any other Gnuk token, I've just release a tool to extract the PGP secret keys from a dumped firmware.

    https://github.com/rot42/gnuk-extractor

    The README explains how to check if your token is correctly locked, and how to dump the firmware if it's not.

    submitted by /u/r0t42
    [link] [comments]

    Factoring Tools for your tool belt - (Python 3 + Binaries)

    Posted: 30 Apr 2019 01:45 AM PDT

    I've been going down the rabbit hole of trying to find advanced factoring algorithms that run on Python 3. TL/DR; there's NONE!

    Many of the posts are from 2012-2015 and don't work. However, I finally tracked down the working code (thanks to the link below).

    Want to start factoring right now? Try these options:

    ​

    If you want to have fun learning math and python III, then here's some "working" examples:

    ​

    Hope this saves you hours of Google-foo in your late night factoring quests!

    ​

    --Alien

    submitted by /u/AlienDjinn
    [link] [comments]

    X25519 output: What to hash?

    Posted: 29 Apr 2019 09:41 PM PDT

    X25519 is an ECDH key exchange over Curve25519. It suggests that the output of the X25519 key exchange needs to be hashed:

    Both of you can then hash this shared secret and use the result as a key for, e.g., Poly1305-AES.

    The documentation of the NaCl library by the same author states:

    NaCl does not make any promises regarding the "decisional Diffie–Hellman" problem (DDH), the "static Diffie–Hellman" problem (SDH), etc. Users are responsible for hashing group elements.

    Which still leaves unanswered what to put into the hash. So I checked some other implementations.

    The documentation for curve25519-donna says to hash the output only with a cryptographic hash function.

    libsodium's key exchange is rx || tx = BLAKE2B-512(p.n || client_pk || server_pk), which seems to hash the output, the client public key and the server public key. This matches their documentation for their scalarmult functions. (I'm a bit surprised the key exchange protocol involves no long-term keys to identify the other party; I suppose that is pushed to the application layer instead.)

    The documentation of Monocypher's crypto_key_exchange() is intransparent, but the code suggests that it hashes the X25519 output zeroes using HChaCha20 with a zero key.

    So now that djb doesn't answer the question and all major implementations disagree on what to do: What is to be hashed at a minimum and for what purpose?

    submitted by /u/beefhash
    [link] [comments]

    LCS35 solved - proof of existence

    Posted: 29 Apr 2019 01:24 PM PDT

    How good or bad is this three-pass protocol implementation?

    Posted: 29 Apr 2019 02:59 AM PDT

    Hi everyone!

    We have been assigned a university project concerning Massey Omura (three-pass protocol) and implementation of various functions through our own personal research (our professor only suggested the usual XOR example). I've found this paper which seemed interesting, so I implemented it in python using numpy. How good or bad is this implementation, from a security and practicity standpoint? I just wanted to know your professional opinions. Thanks.

    https://www.researchgate.net/publication/242074782_A_Three-Pass_Protocol_for_Cryptography_Based_on_Padding_for_Wireless_Networks

    submitted by /u/MrK_HS
    [link] [comments]
    Read more
    at

    No comments:

    Post a Comment