1. 2

    Great paper. Builds off the GPU side channel that many people shrugged off as lacking impact. That said the mitigations section (or lack thereof) is a bit disappointing: “GPUs should clear local memory, but they won’t because it’s too slow” is likely accurate, but the authors don’t go on to discuss any even possibly feasible mitigations. I’m not saying it’s a simple problem, but these authors are certainly best suited to trying to tackle it, or at least hypothesize about it.

    1. 2

      but these authors are certainly best suited to trying to tackle it, or at least hypothesize about it.

      I don’t know. GPU’s are complicated, performance-focused, parallel hardware probably done with full-custom ASIC’s (just guessing there). I’d like to have seen them hypothesize about it. Yet, it will probably take people with experience in high-performance hardware and graphics cards to evaluate how feasible the solution would be. An example might be area of silicon vs speed tradeoffs.

      1. 2

        Fair point. I really like seeing well-rounded systems security papers - perhaps bringing in additional voices could’ve aided the mitigation section, but of course that would take time, and publication pressure is real.

        1. 1

          That’s a good summary of the tradeoff they probably made.

    1. 1

      The problem is that the database has no way to perform interesting operations on the data

      Granted it’s not particularly efficient -yet- Fully Homomorphic Encryption begs to differ on that point

      1. 1

        This is indeed a very promising research area. But it’s not ready for practical use yet, as far as I know.

      1. 1

        After a bit of digging, here’s the paper cited on the IronCore Labs website when they mention group transform encryption https://dl.acm.org/citation.cfm?id=3201602 However, the paper lacks a formal proof of security (?!) (although they do prove correctness, implying that their scheme is a non-trivial extension of previous work and therefore security cannot be immediately obvious)

        1. 3

          The article contains a lucid description of how hybrid encryption works. Props for clarity!

          Then, the article drops the reader off a cliff. What is this ‘transform’ step? Everything up to and after that part is crystal clear. Care to elaborate?

          1. 1

            @cipher_sift could you update this article to include a description of, or citations to descriptions of, the mentioned transformations?

          1. 1

            It’s great that this has successfully found info leaks. That said, it feels like a somewhat simplistic solution. Set taint bytes, see if those bytes show up anywhere. Maybe the code complexity of the kernel prevents things like symbolic execution from being feasible.

            This strategy works at runtime, and doesn’t require source. But, we have source.. could shadow memory based strategies be used? What about compile-time data dependency analysis - with marked variables, and a known list of functions which return data to userland, a walk of the control flow graph might be able to uncover issues (maybe that ‘known list’ assumption is too strong?).

            It’s possible that these other strategies are infeasible for reasons I’m unaware of - thoughts?

            1. 3

              It’s not that hard to start at copyout and scan backwards. Anything not provably zeroed is probably a leak. (I assert without evidence.)

              1. 1

                Take this with a huge pinch of salt (I didn’t work on it and I don’t know about the intent and decisions made) but I’m guessing it’s about making it easier for finding issues at runtime to fit in as part of a bigger picture of functionality. Extending your toolchain is not an easy task and that work mounts up as you look at multi platform support. You are likely to get an answer from people who worked on the project if you asked on the relevant list :)

              1. 1

                This is a 2001 paper, suggest historical and [2001] ?

                1. 2

                  I’ve been using oathtool for a while. This tools are fun, and especially useful under an architecture like QubesOS where your TOTP VM can be separated by the hypervisor from the network and from the VM in which the login is occurring. Then you can have same-physical-device reasonably secure 2FA, and you only need a fuzzy clock sync between your totp vm and the world.

                    1. 4

                      What’s wrong with desktop apps? Like real desktop apps, not this Electron, everything has an 80MB download + a 512MB memory footprint bullshit.

                      Not everything need to run from the browser. Browsers can already sync with your local filesystem using Dropbox/Mega/OneDrive API. This just seems … silly.

                      1. 3

                        They cost more to build and generally aren’t portable. Most users don’t care or notice the memory footprint. Just buy a ton of ram and roll with it.

                        1. 3

                          Good GUIs (generally ones using native UI APIs) are hard to write and not as easily portable, especially when you already have a website you can cram into an electron app.

                          1. 1

                            In a nutshell: worse is better ;)

                            1. 1

                              Also, to your point about DropBox - have you seen the extents to which they go to maintain persistence and access in their macOS desktop app? Benefit-of-the-doubt assuming they need the access their app tries to get, this is still a high-value target in terms of exploiting a personal computer https://techcrunch.com/2016/09/09/dropbox-responds-to-accusations-its-mac-desktop-client-hacks-os-x-security/

                        1. 8

                          Very interesting! But also, just note that it’s from 2013, so who knows maybe they have Tactical Slack by now.

                          1. 2

                            Tactical Slack

                            Excellent XD

                            Also, not only is it a 2013 post, it primarily cites a 2006 and a 2009 resource.

                          1. 1

                            Great! And even better, an extremely quick skim through here https://gitlab.com/search?utf8=%E2%9C%93&search=unsafe&group_id=&project_id=4469613&search_code=true&repository_ref=master shows they’re not shipping massive unsafe blocks everywhere!

                            1. 1

                              Great vulnerability, and a solid write-up. Thanks!

                              Classic double-fetch type vuln (meme related). Also, XML parse before verify feel vaguely “cryptographic doom principle”-y

                              This may have been a reasonable place to use IBE which is instantiated and reasonably efficient, at least one of which is proven in the standard model.

                              1. 3

                                It get’s worse the more important it is to us

                                This is so contrary to my experience it isn’t funny. Whenever I start a side project that isn’t actually important to me (just toying around), I find it hard to stay motivated. When it’s really important for some reason or other, that’s the motivation I need to keep going when I’m starting to get bored or it gets really tough.

                                1. 1

                                  In my limited experience with side-projects, I also felt entirely that this wasn’t my experience. It’s possible that this is because the side projects I’ve delved into have all been very small, and especially for the ones important to me, scope was very clear - feature creep/scope my be the differentiator between my experience and the authors. Is it possibly the same for you, or something else?

                                  1. 2

                                    I suppose that’s one aspect of it - with clear scope you know where you want to get to and if you’re as lazy as I am you want to get from A to B in the quickest way possible. If I am toying around for “fun” I tend to do things the extra-fancy way and progress is not as measurable. In other words, I spend so much time spinning my wheels and then eventually get frustrated about the lack of progress. Because it’s not really “important” I then find it easier to just abort the project rather than finish it up (because everything’s so fancy I feel a kind of pressure to finish everything else in a similarly fancy way).

                                1. 2

                                  Great survey of the current practical work towards the goal of ridding the world of passwords. ImperialViolet is great- always a careful balance of standards discussion, implementation examples, challenges, implications in related areas (e.g. DRM).

                                  There are definitely also more cryptographically involved systems which address the same problem, but they aren’t yet widely deployed like e.g. hardware security tokens are.

                                  1. 3

                                    The author also has an impressive hackerone history: https://hackerone.com/max and list of exploits on that blog. Doing great work :+1:

                                    1. 2

                                      The only reason this is called DAWG is for the comparison against Intel Cache Allocation Technology to be titled “CAT vs DAWG” in the paper -_-

                                      1. 1

                                        While you’re re-architecting your authentication system, maybe consider PAKE :) https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/

                                        Also, this blog post doesn’t really convince that JWT in beneficial on top of the usual signed oauth cookies?

                                        1. 4

                                          I wish something (potentially legislative? like the ADA) would require websites to have some amount of accessibility requirements, including basic functionality even with JS turned off. If I could surf with JS off and opt-in without losing 99% of functionality, I would.

                                          1. 1

                                            The main takeaway here is that even Rogaway messes up hybrid proof every once in a while

                                            1. 11

                                              Kyle and iFixit are fantastic, and this is a great breakdown of a subtle hardware issue.

                                              I wonder if there’s a reasonable adversarial model for MEMS gyros in helium-rich environments? Drones which use MEMS gyros can be knocked out of the air with sound waves at the gyro’s resonant frequency (cite: https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-son-updated.pdf), so a hose of liquid helium which rapidly expands to gas should also be able to take those drones down if it can get them to fly through a cloud of it for long enough.