Cryptography

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?