I’m wondering how a client might try to hide their identity from a server without going full ‘burner-phone-internet-cafe.’ Disabling cookies and other identifying HTTP headers seems like a good start. A VPN helps at the IP layer. What about the TLS layer? Are session tickets used to identify clients beyond their use restoring key material? Is this exploited in the wild?

OpenSSL is (in)famous for its bulky code base and history of preventable security vulnerabilities (e.g. HeartBleed).

In response to issues with OpenSSL the Internet Security Research Group is working on an alternative:

Rustls (pronounced Rustles).

The ISRG is the same group behind Let's Encrypt--the organization that helped TLS become more widespread.

I am personally excited for the project's future. Are you? :)

I am writing a toy TLS 1.3 server implementation. I am trying to test the happy path of my hello retry request implementation.

I have only implemented x25519 key shares so far, and so I need to convince a client to send a non-x25519 key on its first client hello.

How do I do this? It looks like the openssl command line utility, you can specify the named groups for the key share extension but not for the supported groups extension?

In the context of approximate SVP, is it the case that gamma under sqrt(2) is considered resilient to lattice reduction attacks? My research so far says yes, but I thought I'd ask here too. Assume dimensionality of 128 or 256. Any ideas what attacks would be feasible?

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!

Bit of a meta question, but I'm wondering if there are other cryptography communities that are more technical and active. The pqc mailing list for example has some great technical discussions, but it's pqc only, and I was wondering if there are any similar communities out there for general cryptography discussions.

This community is great of course (thanks to the mods and the members here), but quite often I see posts like "check out my medium blogs", "I made a cipher that is better than AES", "I can compress anything into 42 bytes with an RNG", and I want to find more technical discussions than that.

I’ve developed a new encryption method called FlexCrypt and I would greatly appreciate your feedback and security assessment. FlexCrypt combines several techniques, including hex pair reversal, permutation-based encryption, and XOR encryption. Below are the details:

How Does FlexCrypt Work?

1. Hex Reversal: The plaintext is first converted into a hexadecimal format, and then the hex pairs are reversed.
2. Permutation of Hex Pairs: Using a permutation key (e.g., [3, 1, 4, 2]), the hex pairs are randomly rearranged.
3. XOR Encryption: Finally, the rearranged hex text is encrypted using a 128-bit XOR key. This key length can be increased to 192 or 256 bits for enhanced security.

Example:

• Plaintext: "Hello World!"
• Encrypted Text: "f7b72d60"
• Decrypted Text: "Hello World!"

Key Management

• XOR Key: A 128-bit key used for XOR encryption (with the option to increase to 192 or 256 bits).
• Permutation Key: A key that determines the order of the hex pairs (e.g., [3, 1, 4, 2]).

Questions for the Community:

1. How do you assess the security and efficiency of FlexCrypt compared to established methods like AES?
2. Are there any vulnerabilities or attack vectors that I might have overlooked?
3. Under what conditions could FlexCrypt be practically applied?

Challenge:

Here are some encrypted texts using FlexCrypt. I’d like to challenge the community to see if you can crack them:

• Challenge 1: 9bf4ac1a0917d41df90f (128 bit)
• Challenge 2: 0ed819acd9856bbf67b15b12 (192bit)
• Challenge 3: 9918da0ef57306502b5b (256bit)

Feel free to share your attempts and findings!

Here you can find the Source-Code for my actual version:
NoWitchCraft/FlexCrypt (github.com)

I’m looking forward to your feedback and am open to any questions or suggestions!

Thank you in advance, N0W1tchCr4ft

A while back I made a Medium Blog post where I tried to analyze why we are failing to protect human safety as we use technology. The majority of the article discusses the pitfalls in deploying cryptography so I decided to post a link to it here. I would love to hear your comments on the post!

Here is the post.

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 a joint math and cs major heavily considering a PhD in Computer Science following my graduation with a focus on cryptography. I've taken:

• mathematical cryptography
• complexity theory cryptography
• galois theory
• abstract algebra
• complex analysis
• representation theory
• statistics 1
• complexity theory
• algorithm analysis/design
• real analysis I/II
• topology
• a bunch of other low-level cs courses (os, networks, distributed systems, applied cryptography, security etc)

Here are my two options for the future:

• Take Category Theory, Homological Algebra, Automorphic Forms, Analytical Number Theory (mathy path) (can swap automorphic forms/analytical number theory for two seminars in algebraic geometry)
• Take High-Performance Computation, Multiprocessor Synchronization, Distributed Systems, and Machine Learning (cs path)

I'm interested in fully homomorphic encryption and secure multiparty computation. Which path would serve me better?

I learned, by speaking to people on subreddits such as these, that no amount of software verification can guarantee to protect you against faulty hardware that is vulnerable to side-channels. Originally I was told to refer to the Intel Manuals to learn more about cryptographic hardware extensions.

However I admit I have no experience in hardware RTL designs nor assembly. Plus Intel CPUs are proprietary and I can't just make edits to them without risking lawsuits (or worse). So I decided to pay attention to the RISC-V Cryptographic Hardware Extensions--which are open source.

How mature are these extensions? It doesn't look like they are production ready are they? What faults do you see in them compared to industrial strength CPUs cryptographic hardware extensions?

Groth16 uses something very similar to KZG commitments (the Powers of Tau in a trusted setup & use of Elliptic Curve Pairings), though the paper doesn't mention KZG at all.

However, there is never an opening of the commitment in the proof - i.e. at no point is the commitment opened at a random point sent by the verifier like is done in KZG.

I understand how the proof is sound even without the opening. It's because part of the equation which is proved is computed from the trusted setup by the prover & the other parts computed by the verifier again using the trusted setup. And the trapdoors to ensure that the prover has used the Trusted setup - else the proof won't verify.

I am surprised however, how this point (no opening) is not mentioned in either the paper or any other description of Groth16 considering this seems to be a rather non-standard way of using KZG type of commitments. Or is this usage not considered at all to be "commitments" & hence this is not mentioned - i.e. I interpret them as commitments only because they look similar to KZG but Groth & others don't look at these as commitments.

Simple question where I’m talking about finite fields and not finite rings of Integers and where the factorized order is smooth.
Of course, in the later case, Pohlig Hellman is most of the time supported natively. But what’s the code for doing on finite field having a degree ≥3 ?

Factorizing and rising to a suborder is easy, but how to tell Magma/SageMath/Pari to apply Polhard rho in a specific order’s factorized subgroup ?
An alternative is to provide me the answer in the language or your choice using finite fields libaries of your own choice…

When renewing SSL certificates, CAs make plaintext HTTP requests which can be intercepted by your ISP.

My problem with this is that it is hard to distinguish between a compromised CA and a compromised ISP without cryptographic guarantees.

Other ACME request types exist. A CA could use the existing server certificate when performing an ACME check to update that certificate for example.

What should I read about here?

NIST just released the final version of the first PQ standards. There is no official announcement as of yet, but the documents are available for download:

FIPS203 ML-KEM (Kyber): https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf

FIPS204 ML-DSA (Dilithium): https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.204.pdf

FIPS205 SLH-DSA (SPHINCS+): https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf

With the impending NIST selection of stateless Post Quantum secure Cryptography standards later this week, what are some services that have already made the change to quantum safe cryptography?

I know of a few like Cloudflare and Signal that are leading the front on implementing PQ safe algo's, but I wonder who else is making waves in this direction?

Are there any comprehensive lists that have collected this kind of information you know of?

I want to support quantum safe, forward thinking projects, and having an informed list would be really cool! Like a "Quantum Safe" stamp that shows that a company or service that we "trust" is forward thinking and building future safe cryptography in their systems. Bonus for sauce on the implementations!

I'm referencing this standardization process I hear is almost complete NIST PQC Standardization was just announced

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!

I’m in the same boat as many others (possibly you too) that disdains research/papers claiming to present “new”/“novel” things in compsci, especially cryptography, because the overwhelming majority of these papers:

• Are written from an excessively myopic perspective mimicking a novice who lacks sufficient real-world experience to understand the proper way some things are done. It’s easy to come up with new ideas and new ways to do things but it’s much harder to write real-world software systems and have a true appreciation for the way some things must necessarily work.
• Extremely lacking in self-criticism, lacking in comparison to similar novel concepts that failed due to X Y Z, and lacking in how this novel concept is different from them
• Lacks source code for peer review/verification in the spirit of "hey guys, just trust me on this”

All of that being said, I myself am embarking on writing a novel cryptography paradigm that imagines a new way to conceptualize encryption and follows this to its logical conclusion of an entirely new type of cipher unlike ARX, SP-box, Feistel, pseudo-hamad, etc., that’s in a class all of it’s own.

I am looking for advice/discussion to help me avoid common pitfalls with new/novel work. Some of the things I’ve thought of so far:

• Foremost, obey Schneier's Law!: hold out a glimmer of hope this work might be of some use to someone but anticipate I could be wasting weeks of effort on a trivially-debunked paradigm and cipher someone else breaks in 5 minutes.
• Significant emphasis on self-criticism! Lead with a most-conservative specific set of cases, circumstances, and conditions this work applies to and investigated usage in, explain how this work would be innapropriate for general usage or as a replacement for other encryption algorithms, etc.
• The only thing claimed to be novel is the paradigm, not the cipher or any of the extensive followup work supporting the article.
• Extensive recognition of existing work/techniques/concepts in cryptography and how these synergize, never conflict, with my new cryptography paradigm.
• Source code! In many languages! And lots of documentation and usages for everything and all the proper software goodies
• Judiciously limiting any broad generalizations to the absolute minimum, instead leaving these as exercises for the reader if they happen to think the same thing I do. Everything will be structured as concrete, formulaic, and ungeneralized as possible (while still indirectly hinting at the larger picture; I should be able to reserve that right, shouldn’t I?)
• Rationale/reasoning behind everything!, and cut out every nonessential aspect/detail that isn’t backed by a logical explanation of its necessity in the design.
• Structuring for skimability!
• Real, concrete numbers and analyses on every angle/approach to cryptanalysis of my design that I can think of!

I’m eager for your suggestions and ideas to help me avoid common pitfalls writing a paper that presents new/novel work. My goal here in this forum is the same as my paper: to exchange knowledge and foster mutual learning.

I hope this question isn’t off-topic for this sub as I acknowledge Scheier’s Law, embrace being wrong, and seek only help on professional writing. No details about my specific topic or paper are mentioned here.

A lot of crypto developers here have recommended I study preexisting implementations to learn how to code it myself.

If you have coded XMSS in the past what reference programs did you study and learn from?

Ideally the reference code should come equipped with test vectors.

I thank anyone in advance for any responses!

Hey all, I find myself working on the cryptography of an Open Source project, Meshtastic. It currently uses AES256-CTR with pre-shared keys for communication. We’ve recently tightened the code-base up to work even harder to avoid IV re-use.

The project is squeezed by a few requirements, like the need for changes to be non-breaking if possible, the extremely slow data rates of LoRa, and the extremely limited ram and flash on many of the devices we support.

One of the known limitations with Meshtastic is that the keys are all PSK, and there’s no re-keying or forward secrecy for direct messages. Direct messages just re-use the shared channel key. I’ve jumped in to try to fix this.

I’m basing the effort on a drive-by pull request from a couple years back, that never went anywhere. The basic concept is to use a curve25519 diffie-hellman process. Part 1 of the DH calculation gives us a public/private keypair, and the node sends the public key with its node announce packets.

Then the remote node takes that incoming public key, and its own private key, and does part two of the DH exchange, giving it a shared secret. The current version of this code uses SHA-256 hashing step, as the raw DH result has “mathematical properties”. This hashed output will be used for AES-256-ctr encryption between the two nodes.

And here are the questions for the r/crypto brain trust:

Is a hashing step actually needed to evenly distribute the entropy of the curve25519 output, before using it as an AES key? I've not been able to find any work on how resistant AES is to that sort of problem. The original PR used a blake2b hashing step, but that overflowed the flash on some of our targets. I can just barely squeeze a SHA256 hash in, but if it's considered safe to skip, I’ll gladly do so, and have a bit more flash breathing room.

Are there any glaring flaws with this scheme? We’re not going to achieve secret-squirrel levels of encryption, but I’m trying to get this as right as possible given the constraints. You can find the in-development code at https://github.com/meshtastic/firmware/pull/4379/files

Thank you for your time, and happy Meshing!

Others here have mentioned it is important t write good documentation to serve others when developing crypto code.

What are the most effective technique to deliver clear documentation and clear code? Would you recommend any books on clear docs and writing clean code (I develop in C).

We are aware that crypto code is vulnerable to classic exploits such as buffer overflows, integer overflows, memory leaks, etc.

The older legacy crypto code is the more likely it will have such flaws. I know other developers believe it is best to sometimes rewrite crypto code--however this is not always an option when the legacy code is massive and battle-tested. No one wants to go through the effort of auditing that or rewriting that from scratch and sometimes the code itself is very esoteric (e.g. OpenSSL).

So as a cost-effective compromise I was thinking about developing a transpiler that converts code vulnerable to such exploits and replace it with cleaner code.

What flaws do you see in my thinking?

I learned about the signature forgery attack against RSA signatures and was wondering if you can "crack" signatures in the same way you can crack password hashes or if such computations are fruitless