Source: https://bsky.app/profile/filippo.abyssdomain.expert/post/3litoupmytkos

UK wanted global access to decrypt any and all Apple users' iCloud data on request. Apple pulled iCloud encryption from the ADP program instead within UK.

Seems like their idea is to ensure encrypted data outside of UK stays out of UK jurisdiction because the affected feature isn't available there anymore. But this will prevent UK residents from using iCloud end to end encryption in ADP and keeping for example backups of photos and iMessage logs protected, so for example journalists are a lot more exposed to secret warrants and potential insider threats.

Part 1 is in the post link.

Part 2: https://blog.cryptographyengineering.com/2025/02/06/how-to-prove-false-statements-part-2/

Part 3: https://blog.cryptographyengineering.com/2025/02/19/how-to-prove-false-statements-part-3/

Here's a copy of my own comment from the reddit thread;

Randomness is a property of a source, not of a number. Numbers are not random. Randomness is a distribution of possibilities and a chance based selection of an option from the possibilities.

What we use in cryptography to describe numbers coming from an RNG is entropy expressed in bits - roughly the (base 2 log of) number of equivalent unique possible values, a measure of how difficult it is to predict.

It's also extremely important to keep in mind that RNG algorithms are deterministic. Their behavior will repeat exactly given the same seed value. Given this you can not increase entropy with any kind of RNG algorithm. The entropy is defined exactly by the inputs to the algorithm.

Given this, the entropy of random numbers generated using a password as a seed value is equivalent to the entropy of the password itself, and the entropy of an encrypted message is the entropy of the key + entropy of the message. Encrypting a gigabyte of zeroes with a key has the total entropy of the key + "0" + length in bits, which is far less than the gigabytes worth of bits it produced, so instead of 8 billion bits of entropy, it's 128 + ~1 + 33 bits of entropy.

Then we get to kolgomorov complexity and computational complexity, in other words the shortest way to describe a number. This is also related to compression. The vast majority of numbers have high complexity which can not be described in full with a shorter number, they can not be compressed, and because of this a typical statistical test for randomness would say it passes with a certain probability (given the tests themselves can be encoded as shorter numbers), because the highest complexity test has too low complexity to have a high chance of describing the tested number.

(sidenote 1: The security of encryption depends on mixing in the key with the message sufficiently well that you can't derive the message without knowing the key - the complexity is high - and that the key is too big to bruteforce)
(sidenote 2: the kolgomorov complexity of a securely encrypted message is roughly the entropy + algorithm complexity, but for a weak algorithm it's less because leaking patterns lets you circumvent bruteforcing the key entropy - also we generally discount the algorithm itself as it's expected to be known. Computational complexity is essentially defined by expected runtime of attacks.)

And test suites are bounded. They all have an expected running time, and may be able to fit maybe 20-30 bits of complexity in there, because that's how much much compute resources you can put into a standardized test suite. This means all numbers with a pattern which requires more bits to describe will pass with a high probability.

... And this is why standard tests are easy to fool!

All you have to do is to create an algorithm with 1 more bit of complexity than the limit of the test and now your statistical tests will pass, because while algorithms with 15 bits of complexity will generally fail another bad algorithm with ~35 bits of complexity (above a hypothetical test threshold of 30) will frequently pass despite being insecure.

So if your encryption algorithm doesn't reach beyond the minimum cryptographic thresholds (roughly 100 bits of computational complexity, roughly equivalent to same bits of kolgomorov complexity*), and maybe just hit 35 bits, then your encrypted messages aren't complex enough to resist dedicated cryptoanalysis, and especially not if the adversary knows the algorithm already, even though they pass all standards tests.

What's worse is the attack might even be incredibly efficient once known (nothing says the 35 bit complexity attack has to be slow, it might simply be a 35 bit derived constant folding the rest of the algorithm down to nothing)!

* kolgomorov complexity doesn't account for different costs for memory usage versus processing power, nor for memory latency, so memory is often more expensive

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!

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!

Noch zu checken, ob die erwähnten Profile tatsächlich das zum Themenschwerpunkt haben, was der Name suggeriert …

@dutypo Ich wollte mal Typograph werden, in einem früheren Leben, als es das noch als Ausbildung und Studienschwerpunkt gab – als Übergang für ein paar Jahre, zwischen Offsetdruck und @hedgedoc und @cryptpad@fosstodon.org @cryptpad@peertube.xwiki.com @cryptpad_design . Dass es nichts wurde, hat meiner Liebe zu @Gedrucktem, #Hörbüchern, #Literaturverfilmungen, #Sprache, typographisch guten elektronischen Veröffentlichungen, #DTP, @PDF, @openscience , @opendatabund , #Aufklärung , @crypto usw. übrigens keinen Abbruch getan. Unter Anderem freie #HedgeDoc- und #Cryptpad-Instanzen gibts hier: https://timo-osterkamp.eu/random-redirect.html

I need to

• encrypt JSON payload (not just sign)
• not share private key
• verify the payload is generated with the shared public key and RSA fitting all of these.

As I've only made auth with JWT so far, I'm not sure. If I use RSA, I guess I have to put the encrypted text in the body.

Do you think it can be used? Any other suggestions?

i remember pond used to have them. but pond is niche and dead. where else are bilinear parings used? i don't care about crapto deployments though...

TIL the French government may have broken encryption on a LUKS-encrypted laptop with a "greater than 20 character" password in April 2023.

• https://nantes.indymedia.org/posts/87395/une-lettre-divan-enferme-a-la-prison-de-villepinte-perquisitions-et-disques-durs-dechiffres/

When upgrading TAILS today, I saw their announcement changing LUKS from PBKDF2 to Argon2id.

• https://tails.boum.org/security/argon2id/index.en.html

The release announcement above has some interesting back-of-the-envelope calculations for the wall-time required to crack a master key from a LUKS keyslot with PBKDF2 vs Argon2id.

And they also link to Matthew Garrett's article, which describes how to manually upgrade your (non-TAILS) LUKS header to Argon2id.

• https://mjg59.dreamwidth.org/66429.html

Abstract

In this paper, we present video-based cryptanalysis, a new method used to recover secret keys from a device by analyzing video footage of a device’s power LED. We show that cryptographic computations performed by the CPU change the power consumption of the device which affects the brightness of the device’s power LED. Based on this observation, we show how attackers can exploit commercial video cameras (e.g., an iPhone 13’s camera or Internet-connected security camera) to recover secret keys from devices. This is done by obtaining video footage of a device’s power LED (in which the frame is filled with the power LED) and exploiting the video camera’s rolling shutter to increase the sampling rate by three orders of magnitude from the FPS rate (60 measurements per second) to the rolling shutter speed (60K measurements per second in the iPhone 13 Pro Max). The frames of the video footage of the device’s power LED are analyzed in the RGB space, and the associated RGB values are used to recover the secret key by inducing the power consumption of the device from the RGB values. We demonstrate the application of video-based cryptanalysis by performing two side-channel cryptanalytic timing attacks and recover: (1) a 256- bit ECDSA key from a smart card by analyzing video footage of the power LED of a smart card reader via a hijacked Internet-connected security camera located 16 meters away from the smart card reader, and (2) a 378-bit SIKE key from a Samsung Galaxy S8 by analyzing video footage of the power LED of Logitech Z120 USB speakers that were connected to the same USB hub (that was used to charge the Galaxy S8) via an iPhone 13 Pro Max. Finally, we discuss countermeasures, limitations, and the future of video-based cryptanalysis in light of the expected improvements in video cameras’ specifications.

Who wants to invite refugees from r/crypto and r/cryptography on Reddit, and from crypto.stackexchange.com?