Cryptography

So I was reading about this paper. The underlying idea is to lift the discrete logarithm problem to prime−1 for prime curves or order−1 for binary curves since most elliptic curves only have small factors in that case. But their baby‑step giant‑step variant seems to only work when the private key already lie in a specific subgroup. That is : no indication is made on how to move the key to each underlying order subgroup.
And of course, using exponentiations to solve the problem isn’t a reason that allow building an index calculus algorithm…

If I understand correctly (or maybe I’m wrong), being able to use Pohlig Hellman would require using auxiliary inputs as proposed by Cheon : but in my case, I only have 48 of them over the extension of a pairing friendly curve of large characteristic.

I am not a cryptographer, but I am trying to use cryptographic libraries and would like to do it safely. Unfortunately, for my use case it seems to require using them in a non-standard way. The APIs don't seem to fit my use case straight-forward.

I was curious if it was theoretically possible and safe to use the ML-Kem encapsulation key to encapsulate a non-random value as the shared secret. 

What I actually am wanting to do is use the encapsulation key to encapsulate an x25519 public key into the cipher text for a mutual authenticated hybrid setup. The decrypted public key would be used to derive a shared secret using the x25519 process. 

If this is possible, the reason I think this is safe logically, not cryptographically, is this. Suppose ML-Kem is found to be broken, this is no weaker than directly sharing the EC public key which is far safer than directly sharing the raw symmetric key. If however, it is not and EC is defeated by quantum, the 'public' key is never shared publicly, so it should still be 'safe' as neither the public nor private keys are exposed. The only scenario I see that opens exposure is if both algorithms are broken in which case it's no worse than anything else that only uses both. The advantage is that it doesn't share the EC key publicly and you save 32 bytes. If however you include a 32byte hash of the EC public key in the shared message, the recipient could verify that the decryption was successful without an additional round trip and still using the same message size of a random value encapsulated and an additional x25519 key appended. Of course to be mutual, keys/ciphers need to be exchanged in the opposite direction as well.

I am likely missing something very important, so if this is a bad idea, please explain why. If it is not possible, I would also like to know why. Please don't just tell me to use standard APIs (even if that's what I should do and will if necessary) because I don't learn anything that way.

Thanks!

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

Wouldn't that mean the Department of Commerce has keys to the entire world's communications?

How would the Clipper Chip apply to foreign nations?

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

G is the Generator of a Discrete Log Hard Elliptic Curve Group.

2 Private keys x1 & x2, corresponding Public Keys P1 = x1G & P2 = x2G.

Now P = P1 + P2 is also a public key with corresponding private key x = x1 + x2.

If I sign (Schnorr Signature) with x, does it only prove possession of the private key corresponding to P or does it also prove possession of the 2 individual public keys x1 & x2? Or if not proof of possession of both x1 & x2, does it atleast prove something more than just x?

I am looking up Monero Documents & they seem to do this (MLSAG) & it's kind of confusing me.

Hello, I have a final project for my bachelor’s degree at university on the topic of private bidding using MPC protocols. However, my coordonative teacher didn’t really provide me with a lot of material or resources in that area and I need a starting point. Could someone give me some refferences on how to start, What to study? (I am familiar with pretty much any programming language, I know Docker and Linux so a simulation of the bidding process would be quite nice using containers)

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!

Hello, Im currently making a encryption algorithm and I am trying to add a key exchange in my algorithm. I found a method using Diffie Hellman to produce integers however I need a key (datatype) that is bigger than 64!. Because Im shuffling an array of size 64. Im gonna use Fisher-Yates shuffle. Can I achieve this using Diffie-Hellman or is any key I produce with Diffie-Hellman is smaller than 64! ? Thanks in advance. If theres anything I couldnt explain, please ask!

This is another installment in a series of monthly recurring cryptography wishlist threads.

The purpose is to let people freely discuss what future developments they like to see in fields related to cryptography, including things like algorithms, cryptanalysis, software and hardware implementations, usable UX, protocols and more.

So start posting what you'd like to see below!

I'm doing Set 1 Challenge 6 from Cryptopals.

This is my code so far:

# https://cryptopals.com/sets/1/challenges/6
import base64
with open('repeating-keyXOR.txt', 'r') as file:
    text = file.read()
decoded_bytes = base64.b64decode(text)
bits = ''.join(f'{byte:08b}' for byte in decoded_bytes)

# let's try keysize from 2 to 40
keysize_list = range(2, 41)

def hamming_distance(bytes1, bytes2):
    bits1 = ''.join(format(byte, '08b') for byte in bytes1)
    bits2 = ''.join(format(byte, '08b') for byte in bytes2)
    counter = 0
    for i in range(len(bits1)):
        if bits1[i] != bits2[i]:
            counter += 1
    return counter


def find_keysize(text, keysize_list):
    encoded_bytes = text.encode('utf-8')
    keysize_dict = {}
    for keysize in keysize_list:
        first_four_chunks = [encoded_bytes[i:i+keysize] for i in range(0, len(encoded_bytes), keysize)][:4]
        edit_distance = (hamming_distance(first_four_chunks[0], first_four_chunks[1]) / keysize + 
                         hamming_distance(first_four_chunks[0], first_four_chunks[2]) / keysize +
                         hamming_distance(first_four_chunks[0], first_four_chunks[3]) / keysize +
                         hamming_distance(first_four_chunks[1], first_four_chunks[2]) / keysize +
                         hamming_distance(first_four_chunks[1], first_four_chunks[3]) / keysize +
                         hamming_distance(first_four_chunks[2], first_four_chunks[3]) / keysize
                         )
        # divide by 6 to find the average
        keysize_dict[keysize] = edit_distance / 6
    min_keysize, min_value = min(keysize_dict.items(), key=lambda x: x[1])
    return min_keysize
guessed_keysize = find_keysize(text, keysize_list)
blocks = [decoded_bytes[i:i + guessed_keysize] for i in range(0, len(decoded_bytes), guessed_keysize)]

def transposed_blocks(blocks, keysize):
    list_of_blocks = []
    for i in range(keysize):
        new_block = b''
        for block in blocks:
            try:
                new_block += bytes([block[i]])   
            except:
                continue
        list_of_blocks.append(new_block)
    return list_of_blocks
block_of_blocks = transposed_blocks(blocks, guessed_keysize)
block_dict = {}

for block in block_of_blocks:
    block_dict[block] = find_char(block)[0]

byte_sequence = list(block_dict.values())
# Combine all bytes into one bytes object
combined_bytes = b''.join(byte_sequence)decoded_string = combined_bytes.decode('utf-8', errors='replace')

print(decoded_string)

I got the key length of 3 and used it to decrypt the text. Since it was not a meaningful text, I understand that I the correct key length if different.

Could you please advise what I did wrong? I think something is not correct with the function find_keysize(text, keysize_list) but don't what. I take 4 chunks and go through all 6 pairs. Then I normalize all hamming distances by the keysize, and finally I divide total distance by 6 to find the average.

I am implementing an anonymous credential system following Lysyanskaya, 2002, specifically much of chapter 3. We assume that the user (not anonymous) U has a user public key PK^(U) (I will try to do my best without LaTeX support here re: notation) and user private key, SK^(U.) When creating the pseudonym N, this user creates a key pair (PK^(N,) SK^(N),) but will not store these credentials. Upon pseudonym creation only, U will provide the pseudonym public key PK^N and the pseudonym private key SK^(N), but encrypted with their own public key PK^(U). That is, Encrypt(message: SK^(N), withKey: PK^(U)). Let's call this value EK^(N) for encrypted key since the notation will become quite unwieldy otherwise.

If I want to allow this user to authenticate as N, my thinking is the server (organization O in Lysyanskaya) stores the pseudonym N, the pseudonym public key PK^(N) and the encrypted pseudonym private key, EK^(N). This way if the user really is who they claim to be, then O can encrypt some random message m with the pseudonym public key, provide the user only with the encrypted message Encrypt(message: m, withKey: PK^(N)) and the encrypted private key EK^(N).

If the user is not U, all this info will be useless to them. If the user is U and thus has SK^(U), they can then return to O the original message m, and I will know that they have the private key SK^(U) and thus are authenticated as pseudonym N.

I would be storing the following tuples in the database (in two separate tables).

Users table: (U, PK^(U))

Pseudonyms table: (N, PK^(N,) EK^(N))

Is this safe to store in the database?

I don't plan on exactly broadcasting this value, but say if there was a data breach, would it still be safe and not risk de-anonymizing the user?

It’s worth adding that I have since asked this question to ChatGPT and it said that we must always assume that PK^(U) is public and even if someone could not decrypt EK^(N), that they could tell that PK^(U) was used to encrypt it if provided with PK^(U), thus de-anonymizing the user U. It suggested using a key derivation function instead to derive SK^(N). That is, the server would not even send EK^(N) and would only send the encrypted message E(message: m, withKey: PK^(N)).

This is probably more significant than any of these papers coming out of China claiming to break RSA or Gift 64 using a western quantum computer. Scott Aaronson, the consummate quantum pessimist has rather abruptly changed his mind. The man who is famous for debunking claims related to quantum capabilities says:

To any of you who are worried about post-quantum cryptography—by now I’m so used to delivering a message of, maybe, eventually, someone will need to start thinking about migrating from RSA and Diffie-Hellman and elliptic curve crypto to lattice-based crypto, or other systems that could plausibly withstand quantum attack. I think today that message needs to change. I think today the message needs to be: yes, unequivocally, worry about this now. Have a plan.

https://scottaaronson.blog/?p=8329

Maybe he's been bought off by Big NIST or Quantinuum, but I kind of doubt it.

Hey everyone, I am an engineering student working on a research paper on Zk proofs , I need a detailed contrast between zk snark and zk stark and all the future and current projects going on this topic. Where can I find some good resources to understand more about them. Also if there is a good resource to understand Binius.

Does ChatGPT help in understanding cryptography papers? What should I do when I encounter concepts I'm not familiar with when reading papers? What are the most efficient ways to approach research?

A lot of topics sound like gibberish, I am also struggling to understand certain mathematical concepts. Any advice?

Hi,

Given SHA256 is supposed to be random and well distributed, is it true to say that essentially each output can have an infinite and relatively equal number of collisions generated by infinite inputs.

i.e. given in reality we have infinite inputs to feed the function (think arbitrary long binary numbers), can we assume that a properly functioning hash function has "even and reachable" collisions across it's output space?

Also, how can we gain confidence that a specific hash function is random and evenly distributed?

So I made this signature scheme, it's the most bare bones version available. Anyone see any obvious holes in the core algorithm?

It's python, so don't try are actually use it for anything.

I do imagine it's quantum resilient, but I'm curious if it's classically resilient. Here's the repository.

git@github.com:tart-grapes/dntl.git

Have fun.

What happens when an X25519 DH process is performed using a private key and the public key derived from it? I've tried to find any work on this question, and my Google-fu is coming up short. Is the resulting shared key particularly weak? Does it reveal anything about the private key? Is there any place I can look for work done on this particular question? Thanks!

Hello! I was wondering if anyone has utilized the relativity new/old rubber ducky tool by Hak5 on your airgapped machine and if it’s subtle or clonky. I was unimpressed by the video demonstrations…the reason I’m asking is I was curious as to the utility of putting an airgapped machine in a room covered in faraday fabric as a cheap alternative to well, a concrete bunker I guess. 😂😅

Welcome to /r/crypto's weekly community thread!

This thread is a place where people can freely discuss broader topics (but NO cryptocurrency spam, see the sidebar), perhaps even share some memes (but please keep the worst offenses contained to /r/shittycrypto), engage with the community, discuss meta topics regarding the subreddit itself (such as discussing the customs and subreddit rules, etc), etc.

Keep in mind that the standard reddiquette rules still apply, i.e. be friendly and constructive!

So, what's on your mind? Comment below!