• Breaking News

    Monday, May 13, 2019

    Home Unlabelled Cryptography In Pursuit of Clarity In Obfuscation

    Cryptography In Pursuit of Clarity In Obfuscation

    May 13, 2019

    Cryptography In Pursuit of Clarity In Obfuscation

    In Pursuit of Clarity In Obfuscation

    Posted: 12 May 2019 03:44 PM PDT

    Which algorithm is safest if we exclude AES, Twofish, Serpent and Whirpool?

    Posted: 12 May 2019 05:38 PM PDT

    TLDR: Which algorithm is safest if we exclude AES, Twofish, Serpent and Whirpool?

    Full version:

    Hello,

    my threat model is archiving and backing up important and private files.

    Files will be stored in many places including clouds, so count them as publicly accessible.

    I plan to store them for the next upcoming 100+ years in the future. Of course, nobody can imagine what computers will look and work in 2100 - BUT at least I can try to mitigate security risks.

    Super strong and random password is a sure thing.

    So I encrypt those files with VeraCrypt using AES-Twofish-Serpent cascade, Whirpool as the hash.

    But in case that some day a flaw will be found in any given algorithm or in it's implementation (in VeraCrypt itself), I want to add an aditional layer of protection - another software and another algorithm.

    BCArchive seems like a great opinion. (Do you agree?)

    They state:

    "Compressed archive with strong encryption

    BCArchive utilizes the following encryption algorithms, standards and specifications:

    Symmetric algorithms: Rijndael (AES), Blowfish-256, Blowfish-448, IDEA, CAST5, GOST 28147-89, Triple DES Secure Hash Algorithms: SHA-256, SHA-1, MD5 and RIPEMD-160 Asymmetric (public/secret key pair) algorithms: RSA, ElGamal / Diffie-Hellman Specifications for public/secret key pair format: PKCS #12, X.509 PKCS #5 recommendations for the implementation of password-based cryptography RFC 2440 specifications for session keys encrypted by symmetric or public key encryption algorithms"

    When I open advanced settings to modify it, I am given these options:

    https://i.imgur.com/32ymEvr.png

    My questions are:

    1. Which algorithm/hash method mentioned above is best if we exclude AES, Twofish, Serpent and Whirpool?
    2. I think that in case of VeraCrypt AES-Twofish-Serpent is better than Serpent-Twofish-AES because the outermost encryption is strongest (AES will be the first layer needed to break - do I understand that correctly?). Do you agree? Please give me your opinions and do not say that it doesn't matter. It does for me :D!
    submitted by /u/henriu5
    [link] [comments]

    Simplifying Noise protocol framework

    Posted: 12 May 2019 02:54 PM PDT

    I started working on Monokex because I felt Noise was too complex. I've had many iterations, some of which even tried to do away with a general purpose hash. I'm fairly proud on my penultimate iteration, based on XCKDF, but I since realised that it makes payloads very difficult to work with. The API I was using was a nightmare, and unencrypted payloads were not authenticated at all.

    I needed that general purpose hash after all, so I redesigned the whole thing. Trevor Perrin had the right idea about using a state machine for Noise, but he failed to make it as simple as it could be. So I came up with my own. I think it is secure, but I may have missed a crucial detail or three. (Spoiler: I violate the cryptographic doom principle.)

    Monokex state machine

    The state machine holds the following state:

    hash // 32 byte chaining_key + 32 bytes extra_key has_key // tell whether we can use extra_key local_sk // local static key (secret half) local_pk // local static key (public half) local_ske // local ephemeral key (secret half) local_pke // local ephemeral key (public half) remote_pk // remote static key remote_pke // remote ephemeral key

    The hash is the main state of the state machine. Its first half is used as a chaining key, and its second half is used as an extra key (which is only used when the has_key flag is set to "true"). The keys are filled as they are received (either during initialisation, or during the handshake itself).

    Initial state

    • chaining_key = "protocol name" (32 bytes, padded with zeroes)
    • has_key = false
    • local_ske = secret random string
    • local_pke = X25519_public_key(local_ske)

    State transitions

    State transitions with the mix_hash() procedure:

    mix_hash(input): self.hash = Blake2b(self.chaining_key || input)

    (I chose Blake2b, but we could use SHA3, HMAC, or HKDF instead. I believe it makes no difference, please tell me if you think it does.)

    Process messages

    Processing a message means processing all its tokens one by one, in order, then finalising the message thus:

    • If has_key is false, do nothing.
    • If has_key is true, use the first 16 bytes of extra_key as authentication tag. Then call mix_hash() with no input.

    Process message tokens

    First the keys (assuming has_key is false):

    • e (in a message we send): Call mix_hash(local_pke)
    • e (in a message we receive): Call mix_hash(remote_pke)
    • s (in a message we send): Call mix_hash(local_pk)
    • s (in a message we receive): Call mix_hash(remote_pk)

    Then the keys (assuming has_key is true):

    • e (in a message we send): Call mix_hash(local_pke xor extra_key)
    • e (in a message we receive): Call mix_hash(remote_pke xor extra_key)
    • s (in a message we send): Call mix_hash(local_pk xor extra_key)
    • s (in a message we receive): Call mix_hash(remote_pk xor extra_key)

    Then the exchanges:

    • ee: Call mix_hash(X25519(local_ske, remote_pke))
    • ss: Call mix_hash(X25519(local_sk, remote_pk))
    • es (as the client): Call mix_hash(X25519(local_ske, remote_pk))
    • se (as the server): Call mix_hash(X25519(local_ske, remote_pk))
    • es (as the client): Call mix_hash(X25519(local_sk, remote_pke))
    • se (as the server): Call mix_hash(X25519(local_sk, remote_pke))

    When processing an exchange, we additionally set the "has_key" flag to "true".

    Possible security implications

    The biggest differences, compared to Noise are the following:

    • There is no mix_key() function. Keys and transcript are both mixed with the same mix_hash() method. The idea is that as soon as we mix a DH secret that is unknown to the attacker, all following hashes are as good as uniformly random, and can be used as one time pads, encryption keys, or authentication tags.

      Noise took a more conservative approach there: the transcript is hashed, and the keys are derived, separately. When a key is available, it is used to do AEAD directly.

      I believe my approach is just as secure, but just in case I missed something…

    • Messages have only one authentication tag, that authenticate the transcript hash. When a message contains an encrypted DH public key, that key is first decrypted, then used in some exchange, then the message as a whole is authenticated.

      This is the part where I violate the cryptographic doom principle, and Trevor Perrin himself told me he doesn't like it. That's probably why Noise authenticates each encrypted key separately, and keys are authenticated before they are decrypted and used.

      I believe Noise's approach is overly conservative, and doesn't bring any additional security. I believe I can violate the cryptographic doom principle with impunity. I believe nothing bad will happen with my design.

      And I believe belief is not enough. Perhaps I missed something?

    Example protocol (XK1 pattern)

    Here's a complete example with the XK1 pattern (the server key is known in advance, the client key is transmitted over the network). The security goals are the same as Noise's XK1.

    Sender and recipient have the following X25519 key pairs (private half in lower case, public half in upper case):

    • (is, IS) The initiator's static key.
    • (ie, IE) The initiator's ephemeral key.
    • (rs, RS) The respondent's static key.
    • (re, RE) The respondent's ephemeral key.

    Those key pairs are used to derive the following shared secrets:

    • ee = X25519(ie, RE) = X25519(re, IE)
    • es = X25519(ie, RS) = X25519(rs, IE)
    • se = X25519(is, RE) = X25519(re, IS)

    Those shared secrets are hashed to derive the following:

    • C0 = "Monokex XK1"
    • H1 = Blake2b(C0 || RS)
    • H2 = Blake2b(C1 || IE)
    • H3 = Blake2b(C2 || RE)
    • H4 = Blake2b(C3 || ee)
    • H5 = Blake2b(C4 || es)
    • H6 = Blake2b(C5)
    • H7 = Blake2b(C6 || IS XOR K6)
    • H8 = Blake2b(C7 || ss)
    • H9 = Blake2b(C8)

    • T5 = H5[31:47]
    • T8 = H5[31:47]
    • C9 = H9[ 0:31]
    • K9 = H9[32:63]

    Here's in graphic form:

     RS IE RE ee es IS ss │ │ │ │ │ │ │ C0 │ │ │ │ │ ┌─╴+ │ │┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌───┐│┌─┴─┐ ┌─┴─┐ ┌───┐ └┤ H ├─┤ H ├─┤ H ├─┤ H ├─┤ H ├─┤ H ├─┤ H ├─┤ H ├─┤ H ├┐ └───┘ └───┘ └───┘ └───┘ └─┬─┘ └─┬─┘│└───┘ └─┬─┘ └─┬─┘│ T5 └──┘ T8 K9 C9

    The messages contain the following:

    • msg1 = IE
    • msg2 = RE || T5
    • msg3 = IS XOR K6 || T8

    The handshake proceeds as follows:

    • The initiator sends msg1 to the responder.
    • The responder sends msg2 to the initiator.
    • The initiator verifies msg2 (with T5), and aborts if it fails.
    • The initiator sends msg3 to the responder.
    • The responder verifies msg3 (with T8), and aborts if it fails.
    • The responder checks the initiator's static key, and aborts if it fails.
    • The protocol is complete. The session keys are C9 and K9.

    Conclusion

    Can anyone find any flaw?

    submitted by /u/loup-vaillant
    [link] [comments]

    Is there a security problem in this system

    Posted: 12 May 2019 02:18 PM PDT

    Hello, I'm sorry if this is not the right place to post this i didn't know were else to post it.

    Imagine if there is stream where every one posts a message using their public address. Once the message is posted every one can read it. Every user have a pair of public and privet keys, one of the public key is linked to the user and the other is used only for secret messages. Before posting on the stream the user encrypts the message which will contain his secret key, then encrypts it with N public keys and put it on the stream. Every user connected is constantly trying to decrypt messages using their privet key, If they succeed decrypting but the message is still crypted (because there is a multi layered encryption) they post the decrypted version on the stream. This way nor the sender or the receiver know where the message is coming from or where it is going.

    I was thinking of this being on top of a tchat, this can also be used on top of twitter or any public social media.

    Here is an example of the algorithm working with 3 steps:

    m1 = E(k1,m) k1 is the receiver public key

    m2 = E(k2, E(k1,m))

    m3 = E(k3, E(k2, E(k1,m)))

    Than I write m3 on the stream

    k3 holder reads the message and knows that he can decrypt it so he posts this

    E(k2, E(k1, m))

    then k2 holder reads the message and knows the result so he decrypts it and posts it to the stream at the end k1 wont know who is the original sender. in the message he will get the secret public key of the sender so he will encrypt his response using that key than with a random number of public keys.

    The only person who can decrypt the message is k1, if he is missing the message will keep encrypted.

    P.S: I know this look a lot like tor, but this system is still centralised and all of it is still on the visible web

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

    No comments:

    Post a Comment