5 ms·

Hi! Current software maintainer here. (I meant to reply earlier, and then a storm knocked out power to my house.) The weird routine you posted is for backwar

Hi! Current software maintainer here. (I meant to reply earlier, and then a storm knocked out power to my house.) The weird routine you posted is for backwards compat reasons only. It's used solely when decrypting our very first file format, which we care about only because some people never throw anything away. Obviously the password stretching has to match exactly, so the code that originally stretched it (PBKDF 1.5) is still there. It's not been used for new files in the last... five years? Since before my predecessor, anyway. Encrypting/decrypting with a password these days uses standard PBKDF 2.0, with a configurable-as-long-as-its-larger iteration count. Been poking at other stretching schemes too, but none of them are included in released versions yet. At some point we'll drop support for decrypting the early versions and get rid of all that cruft. Anybody still needing their ancient files can use an earlier release. > Their PasswordGenerator class is also interesting. Has > a loop that runs for an arbitrary 80000 iterations, etc. The generator doesn't need to loop at all. The first implementation did, because hysterical raisins. The current random generator just does its work in a single pass. Cleaning up the surrounding code (including that needless loop structure) is on the todo list, but not a priority for the end customer. Cheers!

CiPHPerCoder 10y ago
Interesting! I never imagined someone from DoD would respond to my quick analysis. In all fairness, JD-GUI wasn't exactly great at reversing the class file to Java code and missed quite a bit. I haven't had a chance to analyze it further. Is there any chance the DoD could open source this application (e.g. on Github, or some other site)?
- fifteen_letters 10y ago
  FWIW, a few bits of the Java source are generated from other languages. So if JD-GUI produces something that looks just freaky bizarre, the answer might well be that the actual Java source really does look like that, but that's not what "the original" file is written in, if that makes sense. Like 95% of the project is maintained in straight up Java, but things dealing with different crypto implementations, or features not available in the public release, are sometimes maintained "one level up". Full disclosure: I'm a contractor, not a DoD employee; as the maintainer I can safely speak for what the project was and is. But as to what the project will do in the future, all I can do is give you my best Magic Eight Ball guess. Namely: if it happens, it probably won't be soon. Most of us on the project are big believers in open source but convincing the higher-ups that it would be worth doing that for EW is a looooooooong undertaking. Going open source -- or making any other change to policy, or management, or whatever -- has to help the DoD solve the problems which this software was created to solve. It's not that the entire organization is against the idea of libre software -- AFRL is a research group, they get how good software development works -- it's just that their default position is "make no change" and any other approach has to show a demonstrable, concrete benefit over what they're already getting. In the meantime... well, the EW-Public license specifically allows decompiling, which everybody was going to do anyhow. :-) It's not the same, but it makes looking for vulnerabilities way easier.

CiPHPerCoder 10y ago

Interesting! I never imagined someone from DoD would respond to my quick analysis. In all fairness, JD-GUI wasn't exactly great at reversing the class file to Java code and missed quite a bit. I haven't had a chance to analyze it further. Is there any chance the DoD could open source this application (e.g. on Github, or some other site)?

fifteen_letters 10y ago
FWIW, a few bits of the Java source are generated from other languages. So if JD-GUI produces something that looks just freaky bizarre, the answer might well be that the actual Java source really does look like that, but that's not what "the original" file is written in, if that makes sense. Like 95% of the project is maintained in straight up Java, but things dealing with different crypto implementations, or features not available in the public release, are sometimes maintained "one level up". Full disclosure: I'm a contractor, not a DoD employee; as the maintainer I can safely speak for what the project was and is. But as to what the project will do in the future, all I can do is give you my best Magic Eight Ball guess. Namely: if it happens, it probably won't be soon. Most of us on the project are big believers in open source but convincing the higher-ups that it would be worth doing that for EW is a looooooooong undertaking. Going open source -- or making any other change to policy, or management, or whatever -- has to help the DoD solve the problems which this software was created to solve. It's not that the entire organization is against the idea of libre software -- AFRL is a research group, they get how good software development works -- it's just that their default position is "make no change" and any other approach has to show a demonstrable, concrete benefit over what they're already getting. In the meantime... well, the EW-Public license specifically allows decompiling, which everybody was going to do anyhow. :-) It's not the same, but it makes looking for vulnerabilities way easier.