2018.08.26 12:06:27 (1033656913874112512) from Daniel J. Bernstein, replying to "mjos\dwez (@mjos_crypto)" (1033138682063216642):
This is called "implicit rejection". It does _not_ magically turn decryption failures into decryption successes. It does _not_ stop the attacker from seeing the pattern of decryption failures, which is exactly the information exploited in (e.g.) the 2003 break of NTRU IND-CCA2.
2018.08.24 21:07:41 (1033068345116028928) from Daniel J. Bernstein:
PKE/KEM decryption failures strike again: https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/YsGkKEJTt5c/V0eivEroAAAJ Looks like Hamburg has broken the new (patented?) Round5 proposal to #NISTPQC. Round5 is a semi-merge of HILA5 with the (patented) Round2 proposal; by "semi-merge" I mean that it has some new design elements in it.
2018.08.25 01:00:53 (1033127033231081478) from "mjos\dwez (@mjos_crypto)":
Usually a "break" means that there is something wrong in the cryptographic strength of the algorithm. This is just a decryption failure.
2018.08.25 01:41:46 (1033137317991600128) from "Matthew Green (@matthew_d_green)", replying to "mjos\dwez (@mjos_crypto)" (1033127033231081478):
Oh kill me for asking this, but don’t decryption errors imply potential problems for CCA in F-O, or does the use of a transform like the one in the Hofheinz/Kiltz paper squish this?
2018.08.25 01:47:11 (1033138682063216642) from "mjos\dwez (@mjos_crypto)", replying to "Matthew Green (@matthew_d_green)" (1033137317991600128):
Well, if there is a decryption error, then the re-encryption step in Fujisaki-Okamoto variant will create a completely ciphertext (since plaintext is different). So it will catch it internally, and output a synthetic hash result instead in our F-O variant.