Date: Wed, 12 Aug 2015 23:42:24 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Formats using non-SIMD SHA2 implementations On 2015-08-12 15:26, Lei Zhang wrote: > Now I just finished episerver. I took a close look at the rest of the formats in that list, and found a few 'technical' issues. > > - For 7z, keepass and pdf, there's AES encryption involved at some step of hashing (and also RC4 in pdf). But so far we don't have a SIMD implementation of AES (or RC4). I'm not sure how to handle this. Just do in in scalar code (a loop) after running SIMD for producing the keys! For example, the sevenzip_decrypt() function probably needs no change (but if you change it, be sure not to break non-SIMD builds). > - In clipperz, the salt has a maximum length of 128 byte, which is beyond the size of a single input block for SHA256. I've seen flags like SSEi_2BUF_INPUT and SSEi_4BUF_INPUT. I guess I'll have to quadruple the size the vector buffer to accommodate the salt ? Either that, or do it like in SAP G format (but that code is unreadable). I never used SSEi_2/4BUF_INPUT but I'm sure Jim can provide help if you get stuck. > - The dragonflys seem quite straightforward to me. But they are not interesting ? There's no harm in doing them, for practice if nothing else. So go ahead if you like, but I doubt anyone will have use for them. We made them to convince the DragonBSD guys their hashing was too weak, and they did get convinced and changed their code. I know 7z would be very appreciated by users, but it's not trivial. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.