7 ms·

DoD Encryption Wizard

35 points by bsilvereagle 10y ago

hrolf 10y ago
>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.
- oneplane 10y ago
  Same here in Chromium. Typical... The actual problem seems to be with the cert chain. The whole site is a joke, but then again, so are most US govt sites. I don't understand why they have to keep using ugly, outdated and badly operating websites over there.
  - kevinoconnor7 10y ago
    I believe only Apple includes the DoD root ca by default.
    - ch_123 10y ago
      Ah, so that's why it loaded on my iPhone without any warning! (Firefox/Chrome caught the incorrect configuration)
  - pc86 10y ago
    Because they work? Especially if you are Joe Public who has been trained for years to just click past any warnings on any website. Because most people feel their tax dollars are better spent on things other than redesigning government websites because they "look old?"
    - smileysteve 10y ago
      > Because most people feel their tax dollars are better spent on things other than redesigning government websites because they "look old?" The beauty of Twitter Bootstrap is that good get a modern responsive website with less work than rolling your own design, or even having to think about it.
- deleted 10y ago
  [deleted]
- blcknight 10y ago
  It's signed by the DoD CA.
  - perlgeek 10y ago
    Maybe they should get their CA cross-signed by one that's in all major browsers.
    - dogma1138 10y ago
      Arguably there would be quite a few people who object to the DoD getting their CA's into browsers this isn't a good precedent. DoD today, UK MOD tomorrow, Russia and China when?
      - MichaelGG 10y ago
        What's the problem? Sounds like a good idea. If they ever abuse their status they get revoked, causing them a lot of pain. More pain than if they hadn't been depending on being trusted in the first place.
        dogma1138 10y ago
        Revoking CA's is considerably harder than you think it might work for you but it might not work for the tons of people that do not update their browsers or operating systems. Private/Internal/Enterprise CA's are intentionally out of the ring of trust for SSL certificates, there is no need to give the DoD any preferential treatment. This would literally benefit no one as anyone with any interest in accessing those websites would install the certificate. US .gov sites are "secured" with commercial CA certificates so they aren't even part of the argument. When you count the benefit / usefulness of this change which is very little to null and compare it to the possibility of it being abused as well as the precedent of adding "internal" certificate authorities to the global trust list I see a pretty solid argument against this. Overall with things like LetsEncrypt I hope that the CA/SSL Cert industry would get disrupted enough for most if not all commercial CA's to simply become irrelevant. It's not a question of insurance rather than a technical issue since you still get an 'n' figures "fraud" insurance when you purchase validated SSL certificates from commercial CA's and some standards require you to use them rather than LE and the likes. To my knowledge I do not know of any case on which that insurance has ever been successfully claimed so this entire premise should be just killed off completely. 'LE' and similar services should then be managed by a non-profit or a handful of those maybe for each region and just be done with it, the CA list is already too big and it's already near impossible to figure out who owns what besides the <10 big players. I honestly see no reason for SSL to work a browser have to have a list of 130-150 CA's on file (default Root+Intermediate CA listing on Windows).
deleted 10y ago
[deleted]
gcb0 10y ago
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 10y ago
  > 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 10y ago
    if you are dowloading those binaries than you are worse than the admins of that site.
- tomschlick 10y ago
  Nope. The more traffic that is encrypted the better. Protects privacy, ensures you're connecting to the right source, and helps prevent ISPs from throttling/caching based on the content.
- unethical_ban 10y ago
  Because the public doesn't know to make that distinction. I'd rather a site be served plain than retired HTTPS.
CiPHPerCoder 10y ago
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.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- fifteen_letters 10y ago
  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!
hiram112 10y ago
> 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 10y ago
  That's because it uses AES, and AES is accredited for Secret (but nothing more).
daveloyall 10y ago
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?
- deleted 10y ago
  [deleted]
- lallysingh 10y ago
  Something else with the same name, in case you came here by mistake, and wanted that instead.
  - daveloyall 10y ago
    Oh, I see!
dotBen 10y ago
I'm wondering if EW-Public has a backdoor/weak encryption that EW-Govt doesn't.
- fifteen_letters 10y ago
  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.
niels_olson 10y ago
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.aspx http://iase.disa.mil/pki-pke/interoperability/Pages/index.as...

35 points by bsilvereagle 10y ago

hrolf 10y ago

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

oneplane 10y ago
Same here in Chromium. Typical... The actual problem seems to be with the cert chain. The whole site is a joke, but then again, so are most US govt sites. I don't understand why they have to keep using ugly, outdated and badly operating websites over there.
- kevinoconnor7 10y ago
  I believe only Apple includes the DoD root ca by default.
  - ch_123 10y ago
    Ah, so that's why it loaded on my iPhone without any warning! (Firefox/Chrome caught the incorrect configuration)
- pc86 10y ago
  Because they work? Especially if you are Joe Public who has been trained for years to just click past any warnings on any website. Because most people feel their tax dollars are better spent on things other than redesigning government websites because they "look old?"
  - smileysteve 10y ago
    > Because most people feel their tax dollars are better spent on things other than redesigning government websites because they "look old?" The beauty of Twitter Bootstrap is that good get a modern responsive website with less work than rolling your own design, or even having to think about it.
deleted 10y ago
[deleted]
blcknight 10y ago
It's signed by the DoD CA.
- perlgeek 10y ago
  Maybe they should get their CA cross-signed by one that's in all major browsers.
  - dogma1138 10y ago
    Arguably there would be quite a few people who object to the DoD getting their CA's into browsers this isn't a good precedent. DoD today, UK MOD tomorrow, Russia and China when?
    - MichaelGG 10y ago
      What's the problem? Sounds like a good idea. If they ever abuse their status they get revoked, causing them a lot of pain. More pain than if they hadn't been depending on being trusted in the first place.
      - dogma1138 10y ago
        Revoking CA's is considerably harder than you think it might work for you but it might not work for the tons of people that do not update their browsers or operating systems. Private/Internal/Enterprise CA's are intentionally out of the ring of trust for SSL certificates, there is no need to give the DoD any preferential treatment. This would literally benefit no one as anyone with any interest in accessing those websites would install the certificate. US .gov sites are "secured" with commercial CA certificates so they aren't even part of the argument. When you count the benefit / usefulness of this change which is very little to null and compare it to the possibility of it being abused as well as the precedent of adding "internal" certificate authorities to the global trust list I see a pretty solid argument against this. Overall with things like LetsEncrypt I hope that the CA/SSL Cert industry would get disrupted enough for most if not all commercial CA's to simply become irrelevant. It's not a question of insurance rather than a technical issue since you still get an 'n' figures "fraud" insurance when you purchase validated SSL certificates from commercial CA's and some standards require you to use them rather than LE and the likes. To my knowledge I do not know of any case on which that insurance has ever been successfully claimed so this entire premise should be just killed off completely. 'LE' and similar services should then be managed by a non-profit or a handful of those maybe for each region and just be done with it, the CA list is already too big and it's already near impossible to figure out who owns what besides the <10 big players. I honestly see no reason for SSL to work a browser have to have a list of 130-150 CA's on file (default Root+Intermediate CA listing on Windows).

deleted 10y ago

[deleted]

gcb0 10y ago

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 10y ago
> 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 10y ago
  if you are dowloading those binaries than you are worse than the admins of that site.
tomschlick 10y ago
Nope. The more traffic that is encrypted the better. Protects privacy, ensures you're connecting to the right source, and helps prevent ISPs from throttling/caching based on the content.
unethical_ban 10y ago
Because the public doesn't know to make that distinction. I'd rather a site be served plain than retired HTTPS.

CiPHPerCoder 10y ago

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.

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
fifteen_letters 10y ago
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!

hiram112 10y ago

> 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 10y ago
That's because it uses AES, and AES is accredited for Secret (but nothing more).

daveloyall 10y ago

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?

deleted 10y ago
[deleted]
lallysingh 10y ago
Something else with the same name, in case you came here by mistake, and wanted that instead.
- daveloyall 10y ago
  Oh, I see!

dotBen 10y ago

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

fifteen_letters 10y ago
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.

niels_olson 10y ago

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.aspx http://iase.disa.mil/pki-pke/interoperability/Pages/index.as...