Cryptography @ Infosec.pub

515 readers
4 users here now

Questions, answers, discussions, and literature on the theory and practice of cryptography

Rules (longer version here)

##Related resources;

founded 2 years ago
MODERATORS
1
4
submitted 4 months ago* (last edited 4 months ago) by TrustedThirdParty to c/crypto
 
 

Hello all!

Since the forum hasn't had any listed rules until now, I'm going to import the rules which have worked over at the cryptography forum which I've been moderating in on reddit. I'll list the rules here with explanations.

Forum rules

1: Stick to the topic of cryptography

The focus is on modern cryptography (computer security algorithms and protocols and their implementations). We also allow related infosec topics (including phishing, security UX, etc) as well as discussion of notable historical ciphers, but keep in mind that just because cryptography is mentioned in an article it doesn't necessarily mean it's relevant. Analogy: a forum about motors wouldn't let you post about road trips. In this forum, a submitted article should have a substantial security aspect. If you're unsure, ask the mods or ask in a meta thread.

2: Engage in good faith, maintain high quality & accuracy, don't mislead

To keep quality high, first of all, be kind. Behavior which discourage other good faith participants from contributing is not allowed.
Second, modern cryptography implies threat models, public specifications, source code, security proofs, etc. Don't leave out important information. Please cite your sources. Remember that bad advice can be dangerous!

3: Crypto review requests must explain the algorithms

We follow Kerckhoffs' principle and Schneier's Law - posts that asks for security review of custom algorithms or implementations MUST also publish the full algorithm and a description of its use. Otherwise there can be no meaningful security analysis. Sharing just the output is like...

4: Challenges and puzzles must use modern crypto

Simple codes, ciphers, ARGs, and other such "weak crypto" don't belong here. Rule of thumb: If a desktop computer can break a code in less than an hour, or if it can be broken by hand, it's not strong crypto.

5: Don't cheat on challenges or tests!

Don't use this forum to cheat on competitions, challenges or tests! You may ask for help to understand a test question, but you are not allowed to ask others to solve it for you. You must also disclose the source of a problem you're asking for help with.

6: Link directly to original sources (with exceptions)

We prefer original sources of news, source code, academic papers or similar, rather than clickbaity buzzword blogspam. Avoid snake oil and low quality sources.
Do not post link shortener or to link farms or similar low quality sites, avoid mirror sites (unless necessary due to eg. paywall, like archive.org), and link directly to the original (unless you're posting a more readable expert written summary).

7: Avoid making duplicate posts

In low volume forums like this, multiple posts on breaking news will easily flood the forum. Please check if news is already posted. Different sources on the same news should be posted as comments in the existing thread (exceptions may only be made for substantial new information or if the prior thread is old - ask the mods if you're unsure)

8: All use of AI / LLM and their prompts MUST be disclosed in your submissions and comments

Instead of entirely banning LLMs, we require transparency. Due to LLMs so often being confidently wrong, we PROHIBIT all undisclosed use of LLM when posting regardless of the nature of your post. If used, you MUST share the prompt!
No LLM / AI is exempt!
If you're here to ask a question, a major problem is that the LLM output will carry implied INCORRECT context which you will not recognize, but which we will see, increasing the risk of misunderstanding. We will not be able to give you correct advice if we don't know your thought process!

2
 
 

Hi!

I'm @Natanael@infosec.pub and this account that I'm making this post from is my moderation account, which is now part of the moderators of this cryptography forum. This is the account which I'll be handling removals/bans from, etc.

I've been added as a moderator by @jerry@infosec.pub (server admin)

I also moderate https://reddit.com/r/crypto, and I've been looking for options since the reddit admins decided to make a mess of things with the API and various policies, etc. The community will NOT be forced to migrate so these communities are separate for now, but everybody's encouraged to join here.

If you're a member in both places, feel free to tell us both your handles so we know who you are!

3
4
submitted 18 hours ago* (last edited 18 hours ago) by Natanael to c/crypto
 
 

Opossum is a cross-protocol application layer desynchronization attack that affects TLS-based application protocols that rely on both opportunistic and implicit TLS. Among the affected protocols are HTTP, FTP, POP3, SMTP, LMTP and NNTP.

Note: The vast majority of websites are not vulnerable as HTTP TLS upgrade (RFC 2817) was never widely adopted and no browsers support it.

4
5
2
submitted 1 week ago by Natanael to c/crypto
6
7
8
3
submitted 4 weeks ago by abacabadabacaba to c/crypto
9
10
 
 

Context: https://bsky.app/profile/martin.kleppmann.com/post/3lr6ex2glkc2h

This system is baked into the Guardian's news app that millions of people have installed. Every regular user of the app generates cover traffic, and an attacker monitoring the network cannot distinguish someone using the secure messaging feature from a regular user.

Open source;

https://github.com/guardian/coverdrop

11
12
13
14
1
The cryptography behind passkeys (blog.trailofbits.com)
submitted 1 month ago by Natanael to c/crypto
15
16
17
 
 

From here;

https://chaos.social/@dbrgn/114386333844571387

dbrgn@chaos.social - Here are a few interesting details about the maximally privacy-friendly protocol design:

  • Everything related to synchronization between devices is completely end-to-end encrypted
  • Message recipients do not know from which device a message was sent
  • The Mediator Server of a device group does not know the corresponding Threema ID
  • The Chat Server only sees the IP address of the Mediator Server, but not the IP address of the end devices
18
1
submitted 2 months ago* (last edited 2 months ago) by Natanael to c/crypto
 
 

Announcement from here;

https://mailarchive.ietf.org/arch/msg/cfrg/_HH9A70BwJ6vgEfT2iSTvCQFhZE/

Hi folks,

We recently published an initial specification for a hybrid, post-quantum, augmented PAKE protocol, called CPaceOQUAKE+, located here:

https://datatracker.ietf.org/doc/draft-vos-cfrg-pqpake/

The motivation for this protocol can be roughly summarized as follows:

  • Post-quantum: None of the existing PAKE specifications are post-quantum. Rather than incrementally improve on PAKEs that are secure against standard adversaries, we felt it important to shift focus to post-quantum adversaries.
  • Augmented: Many PAKE deployments use augmented PAKEs (SRP and SPAKE2+, for example). A drop-in replacement for these use cases was therefore important.
  • Hybrid: CPaceOQUAKE+ is built on CPace and OQUAKE (which is specified in the document and based on the NoIC protocol in [1], and then composed with CPace using a variant of the combiner analyzed in [3]) as well as other standard building blocks (like ML-KEM). While CPace is well-understood, OQUAKE and the combiner itself are more new and thus warrant additional caution (from an implementation and analysis perspective). By making the primary protocol CPaceOQUAKE+ hybrid, we hedge against issues in the component pieces used in its construction and the maturity of their implementation(s).

This specification emerged from a number of relevant papers on the topic, including [1,2,3,4,5]. We are finishing security analysis of this protocol (and the core constituent parts) and hope to publish that soon.

We expect the shape and contents of this draft to change over time, especially as this community commences work on PQ PAKEs. We hope that by releasing this initial version we can get the conversation started on this important topic. IETF 123 is a little far out, but if folks would find it interesting, perhaps we can have an interim meeting of sorts to discuss PQ PAKEs and these specifications in the interim.

Best, Chris, on behalf of the editors

[1] https://eprint.iacr.org/2025/231
[2] https://eprint.iacr.org/2024/1621
[3] https://eprint.iacr.org/2024/1630
[4] https://eprint.iacr.org/2024/1400
[5] https://www.escholarship.org/uc/item/7qm0220s

19
20
 
 

See also discussion here; https://reddit.com/comments/1jv572r

21
4
submitted 3 months ago* (last edited 3 months ago) by Natanael to c/crypto
 
 

Cryptology ePrint Archive
Paper 2025/585
Adaptively-Secure Big-Key Identity-Based Encryption
Jeffrey Champion, The University of Texas at Austin
Brent Waters, The University of Texas at Austin, NTT Research
David J. Wu, The University of Texas at Austin

Abstract
Key-exfiltration attacks on cryptographic keys are a significant threat to computer security. One proposed defense against such attacks is big-key cryptography which seeks to make cryptographic secrets so large that it is infeasible for an adversary to exfiltrate the key (without being detected). However, this also introduces an inconvenience to the user who must now store the large key on all of their different devices. The work of Döttling, Garg, Sekar and Wang (TCC 2022) introduces an elegant solution to this problem in the form of big-key identity-based encryption (IBE). Here, there is a large master secret key, but very short identity keys. The user can now store the large master secret key as her long-term key, and can provision each of her devices with short ephemeral identity keys (say, corresponding to the current date). In this way, the long-term secret key is protected by conventional big-key cryptography, while the user only needs to distribute short ephemeral keys to their different devices. Döttling et al. introduce and construct big-key IBE from standard pairing-based assumptions. However, their scheme only satisfies selective security where the adversary has to declare its challenge set of identities at the beginning of the security game. The more natural notion of security is adaptive security where the user can adaptively choose which identities it wants to challenge after seeing the public parameters (and part of the master secret key).

In this work, we give the first adaptively-secure construction of big-key IBE from standard cryptographic assumptions. Our first construction relies on indistinguishability obfuscation (and one-way functions), while our second construction relies on witness encryption for NP together with standard pairing-based assumptions (i.e., the SXDH assumption). To prove adaptive security, we show how to implement the classic dual-system methodology with indistinguishability obfuscation as well as witness encryption.

22
 
 

Abstract;

In this paper, we present the first practical algorithm to compute an effective group action of the class group of any imaginary quadratic order O on a set of supersingular elliptic curves primitively oriented by O. Effective means that we can act with any element of the class group directly, and are not restricted to acting by products of ideals of small norm, as for instance in CSIDH. Such restricted effective group actions often hamper cryptographic constructions, e.g. in signature or MPC protocols.

Our algorithm is a refinement of the Clapoti approach by Page and Robert, and uses 4-dimensional isogenies. As such, it runs in polynomial time, does not require the computation of the structure of the class group, nor expensive lattice reductions, and our refinements allows it to be instantiated with the orientation given by the Frobenius endomorphism. This makes the algorithm practical even at security levels as high as CSIDH-4096. Our implementation in SageMath takes 1.5s to compute a group action at the CSIDH-512 security level, 21s at CSIDH-2048 level and around 2 minutes at the CSIDH-4096 level. This marks the first instantiation of an effective cryptographic group action at such high security levels. For comparison, the recent KLaPoTi approach requires around 200s at the CSIDH-512 level in SageMath and 2.5s in Rust.

See also; https://bsky.app/profile/andreavbasso.bsky.social/post/3ljkh4wmnqk2c

23
0
🕵️‍♂️ (infosec.pub)
submitted 3 months ago* (last edited 3 months ago) by Natanael to c/crypto
 
 
24
33
submitted 3 months ago* (last edited 3 months ago) by Natanael to c/crypto
25
view more: next ›