
DoD Encryption Wizard - bsilvereagle
https://spi.dod.mil/ewizard.htm
======
CiPHPerCoder
I got curious and opened this project in JD-GUI. The namespace is afrlew,
which I presume is some sort of acronym.

EDIT: Of course it is! AFRLEW = Air Force Research Laboratory Encryption
Wizard

The lion's share of the crypto appears to be in called Hut8.class, which JD-
GUI didn't fully decode successfully.

This looks odd:

    
    
        private void incrementSaltIndex(byte[] paramArrayOfByte, int paramInt)
        {
          int tmp5_4 = (paramInt + 3);
          paramArrayOfByte;
          if (0 == (tmp5_1[tmp5_4] = (byte)(tmp5_1[tmp5_4] + 1)))
          {
            int tmp20_19 = (paramInt + 2);
            paramArrayOfByte;
            if (0 == (tmp20_16[tmp20_19] = (byte)(tmp20_16[tmp20_19] + 1)))
            {
              int tmp35_34 = (paramInt + 1);
              paramArrayOfByte;
              if (0 == (tmp35_31[tmp35_34] = (byte)(tmp35_31[tmp35_34] + 1)))
              {
                int tmp50_49 = (paramInt + 0);
                paramArrayOfByte;
                if (0 == (tmp50_46[tmp50_49] = (byte)(tmp50_46[tmp50_49] + 1))) {
                  throw new ArithmeticException("Value overflow");
                }
              }
            }
          }
        }
    

Their PasswordGenerator class is also interesting. Has a loop that runs for an
arbitrary 80000 iterations, etc.

Overall, no obvious vulnerabilities, but definitely in the "written by a bored
undergrad student in their spare time" realm from what I saw. Obviously, I
wouldn't recommend using it.

~~~
fifteen_letters
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
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
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.

------
hrolf
>The owner of spi.dod.mil has configured their website improperly. To protect
your information from being stolen, Firefox has not connected to this website.

oh, yeah, totally clicking on that.

~~~
blcknight
It's signed by the DoD CA.

~~~
Kadin
For those who are interested (probably not necessary on a Mac as they may be
preinstalled), the DOD CA certs can be freely downloaded from DISA:

[http://iase.disa.mil/pki-pke/Documents/unclass-
installroot_v...](http://iase.disa.mil/pki-pke/Documents/unclass-
installroot_v3-16-1a.zip)

There are (impressively thorough, including recommendations on out-of-band
fingerprint authentication) installation instructions included, and they
provide PEM, PKCS7, and some weirdo Windows format.

~~~
nneonneo
However, _that_ website is not served over HTTPS, which would seem to make it
a prime target of MITM. Do you happen to have an HTTPS link to obtain these
certs?

~~~
jcurbo
I haven't found one, but I suspect the IASE page is only over HTTP for legacy
reasons, as there are lots of things that download stuff automatically from
DISA. I could be wrong though, and I agree that it should be served over
HTTPS. The main DISA page is served over HTTPS:
[https://www.disa.mil](https://www.disa.mil)

~~~
fifteen_letters
> I haven't found one, but I suspect the IASE page is only over HTTP for
> legacy reasons

Well, also because an HTTPS page would create a chicken-and-egg situation. How
do you download the root certs if you can't see the page because you don't
have the root certs? etc

------
niels_olson
I wouldn't use this if you're not dealing with the DoD. However, if you're in
the DoD trying to work with an external collaborator, services like this
provide at least some way to show, for example, an IRB, that you're moving PHI
with due diligence.

The DoD maintains a PKI system that is essentially independent of the rest of
the world's crypto: [http://iase.disa.mil/pki-
pke/interoperability/Pages/index.as...](http://iase.disa.mil/pki-
pke/interoperability/Pages/index.aspx)

------
hiram112
> EW-Govt is accredited by the Army and Air Force for NIPRNet and SIPRNet. EW
> is free to users.

Not that it means anything, but NIPRNet is the unclassified network, SIPRNET
is secret level.

So this is not accredited to run on Top Secret and above.

~~~
fifteen_letters
That's because it uses AES, and AES is accredited for Secret (but nothing
more).

------
daveloyall
From the bottom of the page:

Unendorsed polyseme: Encryption Wizard for Oracle
[[http://www.relationalwizards.com/](http://www.relationalwizards.com/)]

uh... How can I say this... :)

wut?

~~~
lallysingh
Something else with the same name, in case you came here by mistake, and
wanted that instead.

~~~
daveloyall
Oh, I see!

------
dotBen
I'm wondering if EW-Public has a backdoor/weak encryption that EW-Govt
doesn't.

~~~
fifteen_letters
Well, you can look at the reversed bytecode and see that it's using AES-128 or
AES-256.

If you're willing to click past the website (DoD root certificates explained
elsewhere), you could read more on the FAQ:
[https://www.spi.dod.mil/ewizardFAQ.htm#FAQkp.3](https://www.spi.dod.mil/ewizardFAQ.htm#FAQkp.3)

The difference between the two is that one has FIPS 140-2 paperwork and the
other does not.

------
gcb0
can we stop being lame and complaining about https certs of something you're
not downloading binaries or submitting information? just consider it http and
move on. sigh.

~~~
smileysteve
> can we stop being lame and complaining about https certs of something you're
> not downloading binaries or submitting information

This is a post about encryption, a site and program for encryption.

It also has file hashes and downloads (zips) on it; so, that meets some of
your qualifications.

~~~
gcb0
if _you_ are dowloading those binaries than you are worse than the admins of
that site.

