1. 2

    Now you can automatically derive Chosen Ciphertext Attacks (such as padding oracles) from arbitrary functions https://eprint.iacr.org/2019/958

    1. 2

      decently fast non-cryptographic hash function

      Please stop posting these in crypto (not just you @zimpenfish)

      1. 2

        Argh, sorry. Noted for next time.

        1. 2

          No worries, thank you!

      1. 0

        I think Lea said it very well. Not really interested in hearing you whining about being mistreated after the credible accusations of sexual assault and harassment. Flag as off-topic because this isn’t technical, and it’s not “culture” either, it’s just you @nadim

        1. 0

          Hi Max,

          I received an email a few minutes ago notifying me that you had tagged me in this comment.

          I don’t think we’ve ever met, but I see that you’re one of Matt Green’s PhD students and are thus active in the field, and I wanted to respond to your comment which appears to imply that I deserve the treatment described in my post because I have, according to you, likely committed serious crimes which people have accused me of on Twitter.

          I have two things to say:

          1. I understand that you think that my blog post is “whining”. I would disagree. I think that, as an aspiring academic, you should recognize that using someone’s work and soliciting for their feedback over a period of an entire week, in over a hundred messages and in two conference calls, while promising them citations that fail to materialize, isn’t exactly something I would describe as whining; it’s actually calling out plagiarism. And pointing out plagiarists does seem to be in the community interest, especially when they (or their students) resort to ad-hominem attacks in response to the calls for proper citation. Your own thesis advisor, Matt Green, is a co-author with Lea Kissner on the Zoom paper, and so I would also wonder whether there is a conflict of interest materializing when one of his students appears to further insinuate that I have committed crimes when I point out the act of plagiarism and supplement it with evidence. If what you’re saying here is that some people deserve to be plagiarized because of Twitter rumors about them, well, that’s not something I can really come to grips with.

          2. If you are interested in what I have to say regarding the tweets that you’re referring to, I wrote a detailed response here that you can read if you wish. In that response, I address the tweets in detail.

          I don’t mind you flagging the post or not wanting to read it, but I would appreciate it if you could please consider the points I make above and try to understand why they could make your comment appear unkind at best. Thank you for reading, and all the best to you.

        1. 0

          The DevOps tag is to computer systems as the Culture tag is to lobste.rs

          1. 1

            This isn’t crypto, this is a fun toy Bruce Schneier decided to work on.

            1. 1

              You’re correct in that it doesn’t do encryption and decryption. It’s a random number generator for cryptographic tools, such as the master password encrypting your password manager, or for seeding a SoloKey.

              Also, Bruce was only an advisor on the project.

            1. 8

              UPDATE: paper is possibly being withdrawn due to an error, sounds like in Theorem 1 on page 7.

              1. 4

                Withdrawl is now on arXiv: “Paper is withdrawn because a counterexample was found to Theorem 1”.

                1. 1

                  PDF is not on arXiv since it’s been withdrawn. Anyone still have it? Or (inclusive or) details on the counterexample?

                  1. 4

                    You can access previous versions on arXiv. Try https://arxiv.org/abs/2008.00601v1.

              1. 1

                Probably mostly useful for CTFs. Fun tool, thanks!

                1. 1

                  This breaks the security of common blind signature schemes, which is surprising and impactful. The security assumption involved (ROS) seems to have been cooked up for the scheme in question, which isn’t totally invalid but (clearly) has risks.

                  1. 12

                    Post quantum cryptography I know even less than Jon Snow. Can’t help you, sorry.

                    PQC is also not magic. We achieve this by making algorithms which rely on primitives that aren’t broken by known quantum algorithms. For example, Pete Shor’s algorithm factors numbers and can be applied to elliptic curve point multiplications as well, so RSA and ECC are out.

                    However, the best we have for e.g. hashes would be Grover’s algorithm, which (very roughly) makes search problems more efficient, and so might reduce work from exponential to the square root of that exponential. So as long as we have large hashes (256 bits -> 2^256 -> sqrt = 128 bits of security) our constructions can be secure. Lamport signatures, for example, are based on hash functions.

                    1. 6

                      PQC is also not magic.

                      I trust it’s not. It’s just that I only know “Lattices have promises, but the literature doesn’t look stable”, and “Hash based algorithms work well, but they’re slow, and key/signatures are big”. And even then I’m not sure. I figured a humorous quip would be better than ignoring the subject altogether (which at worst could be misleading).

                    1. 5

                      Great pragmatic blog post overall. A few comments:

                      Kyber decryptions have a failure probability of about 1 in 2^160.

                      An algorithm that straight up outputs its own private keys to the adversary with probability 2^-160 could still be proven secure in the computational model. I disagree with this as a criticism, efficient crypto is largely built around these sort of things.

                      but I contend that a nonzero risk means they cannot be used in sealing APIs for general purpose cryptography libraries, since the developers of that library cannot be responsible for the decryption failure risk calculus for all of its users.

                      With XChaCha, Daniel Bernstein decided for all of us that 2^-192 is large enough never to have to practically worry about IV collisions (birthday bound gives 96 bits of security there). Sometimes cryptography has to make these decisions because the tradeoffs are e.g. those large public keys you mentioned in Classic McEliece. Once we can do better, we will! Promise!

                      1. 1

                        Exciting opportunity! It’ll be interesting to see how limited it is though. I could absolutely use one of these for my research to verify things that I currently just have to tease out of Apple’s vague documentation, but it’s not like I’d be dropping jailbreaks left and right if I had one.

                        1. 1

                          I might be a bit jaded in this answer, but the terms and conditions make me think that Apple is getting increasingly concerned with how prevalent attacks on their OS (https://www.wired.com/story/android-zero-day-more-than-ios-zerodium/) have become and are trying to get some of the benefits of Open Source (lots of eyes on the problem) while also using their traditional tactics (legal implications for not coming forward with all those jailbreaks you’re dropping).

                          Opening up the platform a bit, within the constraints of the legal paperwork you’ll be signing, seems to be a decent compromise from their view. It will be interesting to see if many of the people responsible for Apple taking this step bother to sign up and bind themselves to it.

                          1. 1

                            The whole “must remain on the premises of program participants at all times” is interesting. “Is you security research device secured” :)

                          1. 1

                            You can either choose to set a high-entropy passcode such as a BIP39 phrase, and then forget it. This will not screw up your account unless you turn on the “registration lock” feature. Or you can use the new “Disable PIN” advanced feature in Signal’s latest beta, which does essentially the same thing in an automated way

                            Do I understand this correctly, that even if I choose “Disable PIN”, my contacts are still uploaded to Signal’s servers?

                            I understand the SGX part of SVR helps to derive a good key from a PIN in order to reasonably encrypt my contact list, but I don’t understand how to the rest works. Does the app contact a remote server, derive the key, and then encrypt the contact list locally, uploading it later? Or does it upload the contact list first, then encrypt it at the server?

                            1. 1

                              I’m pretty sure disabling the PIN/password disables contact backups. I’m not sure about the encryption though, it’s possible that the contacts are only transport-encrypted up to the SGX instance before being encrypted with the PIN+random key.

                              Disabling registration lock on the other hand means that losing your PIN doesn’t prevent you from recovering your account if you lose your PIN, it just means you need a week of inactivity to recover.

                              1. 2

                                Thanks, I have to admit I find the relationship between the PIN and the passcode lock pretty confusing.

                            1. 3

                              Signal’s original post about SVR here

                              Moxie’s early response to criticisms

                              More discussion from Matt Green’s twitter

                              See also good analysis from Twitter @LeaKissner and @VTeagueAus

                              1. 1

                                A thread, because it doesn’t merit a full post.

                                The linked in-depth related blog post is a bit meatier and less ranty.

                                1. 1

                                  Dropping a dissertation on us with no tl;dr comment? Lol at least it’s a short one at 96 pages.

                                  Here’s my shot at a tl;dr:

                                  Data oriented attacks can corrupt program execution, without triggering protection mechanisms such as DEP, ASLR, and CFI. This research systematizes the topic area (see also their 2019 Oakland SoK), then discusses advancements to an existing approach (data space randomization, to prevent targeted corruptions, Asia CCS ‘20) and a new approach (type-checking variadic function arguments, Usenix Security ‘17).

                                  1. 1

                                    The abstract of the paper is the TL;DR.

                                  1. 1

                                    This has zero cryptographic security, of course.

                                    Not sure why these non-cryptographic mixing functions get posted in crypto. Suggesting “performance” instead.

                                    1. 9

                                      When I think of Infosec people, I think of unconstructive mocking rants with terrible puns (this one coins Dunning-GNUger, but other ones like ‘Imagetragick’ come to mind) that frequently seem to misunderstand the time in which these systems were developed. It wasn’t so long ago that OpenSSL and GnuPG were seen as the bleeding edge of open source security software, and that C was the only sensible language around if you wanted either performance or interop with different language runtimes.

                                      Is there anything about this rant that shouldn’t have been a polite email to the GNU Name system people?

                                      1. 6

                                        I won’t condemn cryptographers ranting about the poor design of other crypto libraries on their own personal websites. But certainty I would like to see this cryptographer go to the GNU Name people with his concerns, in the interest of having more software in the ecosystem have better cryptography.

                                        1. 10

                                          The terrible puns are a coping mechanism for how often those polite emails get ignored 😅

                                          Suggest un-tagging as rant because although it has some generalizations it’s based on a specific action which it provides resources to understand, and has technical background and such. Borderline rant IMO.

                                          “Security used to be hard” isn’t really an excuse for doing new crypto wrong. Ultimately an accusatory blog post doesn’t meaningfully harm the project, its maintainers, nor its contributors. However, it might encourage its readers to use alternatives, or at least ask the right questions when developing or choosing solutions.

                                          Overall I’m disappointed by the comments on this post. Lots of “won’t anyone think of the developers privileged enough to have free time to donate to developing software” and not a lot of compelling cryptography discussion.

                                          1. 0

                                            Ultimately an accusatory blog post doesn’t meaningfully harm the project, its maintainers, nor its contributors

                                            That’s an interesting assumption. Blog posts and open source work are widely seen as being good for someone’s career. If a blog loudly calls non-anonymous people out as being incompetent in their chosen field, why couldn’t that have the opposite effect?

                                            Some of the GnuPG people rely on donations to work on it full-time. I would say that bad publicity for GnuPG affects them rather directly. Maybe this is warranted, but I would call it meaningful harm.

                                            But the author has updated his original post; his criticism of GNU Name seems to have been based on a misunderstanding.

                                            1. 4

                                              I appreciate the edit the author made, and it’s a good catch by the commenter, but the overall opinion of the article didn’t shift as a result.

                                              A blog post like this is can provide those contributors with essentially free security review/cryptanalysis, even if of limited scope or detail. The same technical content that gives it weight gives it value. Maybe it discourages someone from donating in the short term, but if it leads to a long-term better product, that’s good, and the short term effects can likely be countered by a reasoned response (especially if you respond to a rant in good faith, it’s a good look to be humble).

                                        1. 2

                                          Textbook example of blog spam here. Rather than providing an honest comparison of approaches, it simply says “if you do scaling, it’ll be bad, let our product do scaling for you, it’ll be good.”

                                          1. 2

                                            Really appreciate the honest feedback.

                                            1. 2

                                              Thank you for taking it so graciously! Gave me more credit than I probably deserved for that snark.

                                              1. 2

                                                Lobste.rs is a great community and part of being in a community is listening. Thanks again for helping me.

                                          1. 2

                                            https://www.theguardian.com/world/2020/jul/07/dutch-police-arrest-six-men-after-discovery-of-torture-chamber

                                            Dutch authorities prevented organized crime from torturing people because they could decrypt/intercept EncroChat messages and calls.