• Breaking News

    Friday, November 2, 2018

    Home Unlabelled Cryptography Simple Handshake with Monocypher (review before release)

    Cryptography Simple Handshake with Monocypher (review before release)

    November 02, 2018

    Cryptography Simple Handshake with Monocypher (review before release)

    Simple Handshake with Monocypher (review before release)

    Posted: 01 Nov 2018 06:09 PM PDT

    Here's my new interactive Handshake, protocol, made for Monocypher. It aims to be simple, and to minimise dependencies (it uses only X25519, Chacha20, and Poly105, two of which are used in Monocypher's AEAD).

    I've attempted an informal security analysis, if anyone is interested in checking it out. In the mean time, here are the specifications below. I'll only have two questions:

    • Could someone actually implement this spec without looking at my code?
    • Does it look secure? What are the scary parts?

    Sender and recipient have the following X25519 key pairs:

    • Es: The sender's ephemeral key.
    • Ls: The sender's long term key.
    • Er: The recipient's ephemeral key.
    • Lr: The recipient's long term key.

    Those key pairs are used to derive the following symmetric keys:

    • K1: HChacha20(X25519(Es, Er), 0)
    • K2: HChacha20(X25519(Es, Lr), 1) XOR K1
    • K3: HChacha20(X25519(Ls, Er), 2) XOR K2
    • AK2, EK2: Chacha20_stream(K2)
    • AK3, EK3: Chacha20_stream(K3)

    (The authentication keys AK* use the first 32 bytes of the Chacha20 stream. The encryption keys EK* use the next 32 bytes. The streams' nonce and counter are both zero.)

    The messages contain the following (Es, Er, and Ls denote the public half of the key pairs, and || denotes concatenation):

    XLs = Ls XOR EK2 request = Es response = Er || Poly1305(AK2, Es || Er) confirmation = XLs || Poly1305(AK3, Es || Er || XLs)

    The handshake proceeds as follows:

    1. The sender sends the request to the recipient.
    2. The recipient receives the request, then sends its response.
    3. The sender authenticates the response, and aborts if it fails.
    4. The sender sends its confirmation to the recipient.
    5. The recipient decrypts & records the sender's transmitted public key.
    6. The recipient authenticates the confirmation, and aborts if it fails.
    7. The protocol is complete. The session key is EK3.
    submitted by /u/loup-vaillant
    [link] [comments]

    Ancient RSA

    Posted: 01 Nov 2018 09:53 AM PDT

    Most cryptography today involves operations in finite fields. A few ancient cryptosystems (like the Caesar cipher) basically just used operations on cyclic groups, a related idea. Operations on finite fields aren't too complicated to perform by hand.

    Suppose someone 2000 years ago had come across the idea of finite fields (maybe while studying the Euclidean algorithm). Would they have been able to make effective use of any modern cryptographic methods? Or would being restricted to relatively small numbers have also made these systems weak enough to quickly break by hand?

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

    Transposition Cipher

    Posted: 01 Nov 2018 12:48 PM PDT

    If you are interested in programming a transposition cipher then watch the below tutorial:

    https://www.youtube.com/watch?v=BzaaUgcqrL4

    ​

    This technique was used centuries ago.

    I created a Python script to do this as a programming challenge.

    If you are not interested in programming with Python then skip it because this is almost useless nowadays.

    ​

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

    How can a I crack an AES-CBC key knowing the IV and being able to produce the decrypted version of an encrypted message?

    Posted: 01 Nov 2018 09:13 AM PDT

    Hello,

    I have a situation where I am pretty sure I have the IV and can decrypt any encrypted message (of 32 bytes). I think the block size is 16 bytes.

    I am really struggling to find how I would go about cracking the key. I am aware that I probably need to use a CCA attack of some sort but can;t find any resources or tools that I am capable of understanding.

    Thank you for any help.

    Edit: In the end I learned that this is not possible and thus explored other routes to solve the problem in question.

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

    The database encryption and compression problem. Any ideas?

    Posted: 01 Nov 2018 08:44 AM PDT

    One of the great problems in operating large databases is the encryption & compression problem. When something is compressed & encrypted it's impossible to use the data base. So what do you do? You uncompress & decrypt data so you can use it thus exposing it to hack. I call this the TARGET problem. Target got hacked because it left it's data unencrypted and made it open to hack. Other than Larry Ellisons 'Star Wars' defense system he just announced at Oracle Open World (what does that mean), I wonder what ideas you all have to solve this huge problem.

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

    No comments:

    Post a Comment