Psychic Signatures in Java

Post by lazide » Thu, Apr 21, 2022, 11:55 PM UTC

tptacek wrote: post #110

lazide wrote: post #109

Earlier quoted context omitted.

Ah, your second question is a good one, and probably gets to the root of the disagreements. I was specifically referring to the context of things like block devices. There is no single message (in a sane way, anyway) for the device. Each low level block is the message, in the sense you are referring to. That's when inputsize != outputsize is a problem, as that 'message' is also fixed size. When I am referring to auth…

People have been saying stuff like "even a CRC would make attacks impractical" for decades, and what all they've managed to accomplish is an obstacle course for early-career academic cryptographers. Which, by all means, carry on: it produces great papers, and it's a great way to get new people into the field. But if you care about security, your ciphertext needs to be authenticated. Which brings me back to: all secur…

Post by loup-vaillant » Fri, Apr 22, 2022, 12:38 AM UTC

lazide wrote: post #107

loup-vaillant wrote: post #105

Earlier quoted context omitted.

> How so? All symmetric crypto algorithms at their basic level that I am aware of do not change the message size at all. That's because you are not aware of the importance of authentication. Without authentication, your system is not secure: an attacker might intercept messages, and modify them undetected . The key word here is "ciphertext malleability". And once they can do that, they can cause the recipient to reac…

Oh I am quite aware. You do not seem to be aware of the practical constraints around an actual attack like ciphertext malleability in this context, or have thought through how you would implement direct disk encryption on a block device with AES-GCM without, you know, doing block based AES-GCM for individual blocks? Which is exactly what I was referring to? For block based, the best way is simple to use a validating…

Post by lazide » Fri, Apr 22, 2022, 2:36 AM UTC

loup-vaillant wrote: post #113

lazide wrote: post #107

Earlier quoted context omitted.

Oh I am quite aware. You do not seem to be aware of the practical constraints around an actual attack like ciphertext malleability in this context, or have thought through how you would implement direct disk encryption on a block device with AES-GCM without, you know, doing block based AES-GCM for individual blocks? Which is exactly what I was referring to? For block based, the best way is simple to use a validating…

> You do not seem to be aware of the practical constraints around an actual attack like ciphertext malleability in this context Show me a peer reviewed paper demonstrating, or at least convincingly arguing, of the soundness of a particular technique you are trying to advocate, and I’ll believe you. Otherwise it’s pretty simple: either your authentication method has been validated (as are HMAC and polynomial hashes),…

Post by needusername » Fri, Apr 22, 2022, 7:14 AM UTC

gunnarmorling wrote: post #102

vlowrian wrote: post #86

What puzzles me most is that two days after the announcement of the vulnerability and the release of the patched Oracle JDK, there is still no patched version of OpenJDK for most distributions. We're running some production services on OpenJDK and CentOS and until now there are only two options to be safe: shutdown the services or change the crypto provider to BouncyCastle or something else. The official OpenJDK proj…

For folks on RHEL, the java-17-openjdk package for RHEL 8 has been updated: https://access.redhat.com/errata/RHSA-2022:1445 . > The official OpenJDK project lists the planned release date of 17.0.3 as April 19th, still the latest available GA release is 17.0.2 > ( https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u ). I don't think there 17.0.3 ever will be available from openjdk.java.net; there's no LTS for ups…

Post by loup-vaillant » Fri, Apr 22, 2022, 7:36 AM UTC

lazide wrote: post #114

loup-vaillant wrote: post #112

Earlier quoted context omitted.

> Practically speaking, even a basic CRC of metadata and file contents would make most attacks impractical. If I recall correctly, CRC of plaintext-then-encrypt scheme have been defeated in the past. With practical attacks. --- > Which you could do with AES-GCM of course, by storing the tag separately. I currently know of no implementations that do so however, but I'm sure there are ones out there. It would require s…

If you store all your tags (which update every time a block updates) in one location, then you’ll burn it out on a SSD, or thrash your disk with seeks on spinning rust (you’ll multiply your writes 2x, minimum). And unless you are adding some kind of virtualizing layer, you don’t have .4% of blocks to play with. You have 0% of blocks. I tried to read your pointer, but the link goes no where explaining it. Mind giving…

  int crypto_aead_aes256gcm_encrypt_detached(
      unsigned char       *ciphertext,
      unsigned char       *mac,
      unsigned long long  *mac_size_p,
      const unsigned char *message,
      unsigned long long   message_size,
      const unsigned char *additional_data,
      unsigned long long   additional_data_size,
      const unsigned char *always_NULL,
      const unsigned char *nonce,
      const unsigned char *key);