lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <541962CC.9040302@ciphershed.org> Date: Wed, 17 Sep 2014 06:30:36 -0400 From: Bill Cox <waywardgeek@...hershed.org> To: discussions@...sword-hashing.net Subject: Re: [PHC] omegacrypt and timing -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/17/2014 05:53 AM, Krisztián Pintér wrote: > On Wed, Sep 17, 2014 at 11:30 AM, Bill Cox > <waywardgeek@...hershed.org> wrote: >> However, AntCrypt, OmegaCrypt, and Schvrch all tried to >> introduce data based branching > > i picked omegacrypt because i just spotted this. out of the 3, > antcrypt seems to be the worst, the other two can get away with > some blinding (dummy operations), but you can't compensate for > differences in floating point, as the timing is just unknown and > depends on zillions of factors, including the data itself. > I forgot to mention POMELO. It also does data-based branching to thwart SIMD. That's 4 entries with the same idea! Of the four, AntCrypt does the best job of making it's case for using data-based branching for SIMD defense. I think OmegaCrypt, POMELO, and Schvrch do too little data-based branching to badly hurt a GPU attack. The GPU can simply execute each case serially, and only write data for the selected case, so with N cases, a GPU will not slow down by more than a factor of N. I would love to explore more in this direction of data-based branching for GPU defense. None of these code bases seems like the right starting point, so... I think may have some fun hacking up a non-entry. Of all the authors, I think I win at using other people's good ideas :-) I bet I can make something cool with this one. Specifically what I'm thinking of is a simple m_cost loop like my original "keystretch" algorithm, but I'd replace hashing with with 3-cycle AND/OR/ADD/SUB-XOR-ROTATE combinations. Like Schvrch and POMELO, I'd drop an calls to existing cryptographic hashes, and depend on the unpredictable 3-instruction combinations to randomize a "state". I think I'll go code it and post back :-) Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUGWLIAAoJEAcQZQdOpZUZOgoQAKakzgffcA4UDQ0YVF8UdLZw OlkW+86jKQLgZw0ybM7zanx8WsNtGMlb+BAUWHk3vfvzsyaQnxXa/V5Jqy+sOxZA bDl++C8EwlZj+Zeaq+9QsQ/Q5LZ5b2KOvljwvOh+OVUOqS9XfzfKbUTvowmhvNxG hBdRz+gl5acvsuN7jWHL3iZonkj1UUFOxCuz/UtKzsiHzhCYx/kAThztRCbsDoAl wNVNNF8iEH2Ghu/wT3FurmXUIXYf3eEGJCgfEPDue57ZGv5k7QdkCRh6i+gs5MWt F+vy74/GrTGrWDrmMEHJUhDMq7fgHj/dbAGjY8ypUW65jKRg5RFA7s/5rmqPHnLf y7C+a8V5L6cezCoYEXASjl0OWqhTdKSv3tZWVX7C+rZPh4R4g9ceXbEE+1GS8Ntd gUROW5SMlYOW3erbuuSvloezqMIPV4N9sICH4YbsHu/ZnW1xYJ8Jx1j9zFMHfHwv 7+ZieMjmPTo7Cq966gWmTvWO15sTwNHAC8zo4uzVlnsKKXZUtWWbnNGwZbTSi1dG LmyRqc3CBzsE2iV+oVE3+wEshRERhbFOvYzkWrY8g2xEYGNzAsmSA3iz9nYbHJ5n si+sAgGxdnW/NvH7HD+maK6ZYV44gWFJCmowzcwa/cCJwL9Rt9e9zsqf0vZAu0Zq GVIaQQWYraJNJKACeQ8k =K0VJ -----END PGP SIGNATURE-----
Powered by blists - more mailing lists