Cryptography @ Infosec.pub

467 readers
1 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 3 months ago* (last edited 3 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
1
The cryptography behind passkeys (blog.trailofbits.com)
submitted 6 days ago by Natanael to c/crypto
4
5
6
 
 

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
7
1
submitted 1 month ago* (last edited 1 month 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

8
9
 
 

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

10
4
submitted 1 month ago* (last edited 1 month 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.

11
 
 

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

12
0
🕵️‍♂️ (infosec.pub)
submitted 1 month ago* (last edited 1 month ago) by Natanael to c/crypto
 
 
13
33
submitted 1 month ago* (last edited 1 month ago) by Natanael to c/crypto
14
15
 
 

Via; https://bsky.app/profile/nicksullivan.org/post/3ll7galasrc2z

CFRG process documentation has been updated.

16
17
10
submitted 2 months ago* (last edited 2 months ago) by Natanael to c/crypto
18
2
How to Hold KEMs (durumcrustulum.com)
submitted 2 months ago by Natanael to c/crypto
19
20
21
 
 

From: https://mastodon.social/@fj/114171907451597856

Interesting paper co-authored by Airbus cryptographer Erik-Oliver Blass on using zero-knowledge proofs in flight control systems.

Sensors would authenticate their measurements, the control unit provides in each iteration control outputs together with a proof of output correctness (reducing the need in some cases for redundant computations), and actuators verify that outputs have been correctly computed

22
4
submitted 2 months ago* (last edited 2 months ago) by Natanael to c/crypto
 
 

"The GSM Association announced that the latest RCS standard includes E2EE based on the Messaging Layer Security (MLS) protocol, enabling interoperable encryption between different platform providers for the first time"

23
 
 

HQC gets standardized, as an addition to ML-KEM (kyber). McEliece is out of the NIST process for two reasons, they consider it unlikely to be widely used, also ISO is considering standardizing it and they don't want to create an incompatible standard. If ISO does standardize it and it does see use, NIST is considering mirroring that standard (since lots of US agencies are bound to using NIST standards)

24
25
view more: next ›