Cryptography Cube/CubeCrypt v0.6 with OpenSSL SHA256 HMAC

---

• Cube/CubeCrypt v0.6 with OpenSSL SHA256 HMAC
• Privacy-preserving sentence semantic similarity using InferSent embeddings and secure two-party computation
• Can I use the rubik's cube as an encryption device or cipher?
• "Leak-attributable" secret sharing/MPC?

Cube/CubeCrypt v0.6 with OpenSSL SHA256 HMAC Posted: 26 Jan 2018 09:01 PM PST https://github.com/pvial00/Cube/blob/master/bin/Linux/cubecrypt https://github.com/pvial00/Cube CubeCrypt is a standalone binary (at the moment only tested and compiled in Linux) that allows for file encryption with the Cube256 cipher authenticated with HMAC EVP_SHA256 from OpenSSL. Usage: cubecrypt <encrypt/decrypt> <input file> <output file> <password> Inner workings: The password supplied by the user is input into CubeKDF and a 128 bit key is generated. CubeRandom is called to give 128 bits for the nonce. The data is encrypted and a 256 bit MAC is generated. Upon decryption the MAC is verified before decryption takes place. CubeCrypt will be the recommended tool for encrypting files with Cube. The next version will have memory usage optimizations. A formal paper is in the works, finally. submitted by /u/pvial00 [link] [comments]

Privacy-preserving sentence semantic similarity using InferSent embeddings and secure two-party computation Posted: 26 Jan 2018 10:25 AM PST submitted by /u/johnmountain [link] [comments]

Can I use the rubik's cube as an encryption device or cipher? Posted: 26 Jan 2018 11:10 AM PST Hi, I'm curious of I can use my rubik's cube as an encryption device of some sort, here's how I think it will function: Get a solved cube and get a predetermined scramble from a generator online. On the scrambled cube, write your message color by color(I think there are some better ways to do this). You can solve the cube back to it's solved state or you can scramble it even more (Your buddy needs to solve the cube nevertheless to scramble it from your scramble in step 1). Your buddy will then scramble it from the scramble that you have given him in step 1 and follow how you wrote the message in step 2. That's how I envisioned it to work, I have questions about it: Will my cipher text easy to break? Is there any way that I can code this for it to be viable at least? (I figured out that writing letters individually on each sticker is going to be tedious task) Does it satisfy Kerchoff's principle? That's all I would appreciate your answers guys (and/or girls)! I'm currently in high school and I'm reading about cryptography and I'm a rubik's cube addict! Thank you for reading my question and answering it! Any suggestions or improvements will be welcomed, I'll also accept suggestions for good books about cryptography hehe. Thanks again, all love from the Philippines! submitted by /u/Armakatsu [link] [comments]

"Leak-attributable" secret sharing/MPC? Posted: 26 Jan 2018 12:20 PM PST Are there known methods to share a secret (or, ideally, do multi-party computation) so that if any participant leaks intermediate values (that could be used to reconstruct the shared secret or the inputs/outputs of the MPC) the leak can be uniquely traced back to the guilty party in a non-repudiable way? I tried searching the IACR ePrint archive for this, but "canary trap" gave zero results; "traitor tracing" was only related to broadcast and DRM, not secret sharing; and "secret sharing" or "multi-party computation" only returned papers on ensuring correctness and identifying cheaters (those who would try to manipulate the result) not leakers. Specifically, I'm looking for systems with the following properties: (0) There exists a dealer, who shares a secret to participants: Alice, Bob, Carol, etc. A recipient can gain access to the secret by working together with the participants in a correct execution of the protocol (1) If any participant discloses their share, it is possible to determine which participant failed in keeping their share safe (2) There is no way to compress or transform a share so that it could be disclosed and used to reconstruct the secret but not traced back to the particular participant it originated from (3) The dealer does not know the shares of the participants either, and thus no party can produce evidence of a leak where no leak has occurred Of the above, (0) is relatively trivial. (1) and (3) together render most secret sharing/MPC techniques unsuitable; eg. regular Shamir's Secret Sharing has (1) but not (3), while oblivious polynomial evaluation-based schemes have (3) but not (1). Additionally, (2) prohibits some schemes such as simple additive secret sharing, regardless of other properties, as three colluding participants could just sum their shares and generate a secret that can be safely leaked, with no way to trace it back to the guilty parties. There seems to be a "brute-force" n-of-n solution which uses a construction similar to Lamport signatures with a large share table generated with a suitable all-or-nothing transform. Assuming 24 is computationally infeasible to brute-force, and there are three participants Alice, Bob and Carol: The dealer generates a share table [(x0, y0), (x1, y1), (x2, y2), (x3, y3)] for Alice and Bob. Alice and Bob both generate 4 public keys, and use eg. lexicographic ordering to create a table of 4 keypairs where each pair has one key from Alice and one from Bob, which is then sent to the dealer, who then encrypts each share to the corresponding public key. This way Alice and Bob don't know each other's shares while the dealer doesn't know exactly who has which shares. This is then repeated with the other two possible pairings (Alice and Carol, Bob and Carol), so that each participant has 8 shares out of 24 total, and nobody knows the entire set of shares someone else has, nor the contents of anyone else's shares. The recipient learns the entire share table by each pair of participants encrypting their respective shares with the recipient's public key, and ordering them in the same pattern as they were in the original share tables, then sending it to the recipient. The exact shares someone has (for example, assume Alice received [x0, y1, x2, x3] with Bob and [y4, y5, y6, x7] with Carol) are the "incriminating information" and if anyone else learns their contents they can publish proof of this. Additionally, if the dealer learns the positions of the shares someone has (in Alice's case, the secret 01001110), they can use that to pick the correct shares and generate a proof of leak, once again incriminating the participant. If every other participant colludes with the dealer or recipient, a participant can be framed; if any two participants stay honest, proof of leak cannot be created due to the missing information. If any k < n participants collude in an attempt to reconstruct secret data, they risk exposing information that can be used against them. (Some steps omitted for brevity; for example the participants also need to produce commitments that can be used to identify the incriminating information, and prove their correctness. The latter seems trivially doable by just repeating the protocol a sufficient number of times, and having all parties reveal enough information to prove correctness in all but one execution; everything else is performance optimization. There might also be a way to use oblivious polynomial evaluation to make a more efficient scheme, but I haven't found an immediately obvious way to do it yet.) What I'd like to know is: are these kinds of constructions genuinely novel; and if not, where/how can one find more information on them? submitted by /u/eth_r [link] [comments]

You are subscribed to email updates from Cryptography news and discussions. To stop receiving these emails, you may unsubscribe now.	Email delivery powered by Google
Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States