5 ms·

I can tell you that as long as the crypto in WireGuard is DJB stuff that can't be FIPS certified, Cisco and Juniper and such will still do a strong VPN business

by api 7y ago

I can tell you that as long as the crypto in WireGuard is DJB stuff that can't be FIPS certified, Cisco and Juniper and such will still do a strong VPN business and you will rarely see it in BigCo, at least in the US. Security is largely about checking boxes to reduce liability, and FIPS is a checkbox. Corporate IT is unbelievably conservative. It's all still about Active Directory, Windows domains, and SSL VPNs with FIPS certification and AD support.

samgranieri 7y ago
Humor me: What would prevent DJB's crypto from being certified by FIPS?
- api 7y ago
  Bureaucratic inertia. I've been hoping for years that it'll be certified. They've talked about Curve25519 and Curve448 for a while but no movement so far. My insider sources tell me there's opposition, but I have no clue why... either the NSA prefers weaker crypto or (more likely) industry wants the status quo because they fear competition from open source superior products like WireGuard among many others.
  - tptacek 7y ago
    I feel like having a restricted set of algorithms in FIPS 140-2 is kind of the whole point of having things like AES in the first place. First you get everyone to agree on an algorithm, then you mandate that algorithm for your own applications. I don't expect them to budge from that, and I don't think it has anything to do with quality. At the point NIST certifies XSalsa20 as FIPS-compliant, they might as well rename it AESbis. Industry prefers FIPS 140-2 because cryptographic expertise is extremely scarce and, prior to AES, commercial products were choc-a-bloc with broken hand-rolled cryptography. It's a rational decision to delegate selection of primitives to NIST. I think FIPS 140-2 is aging poorly, but I think that's in part because all cryptographic standards are aging poorly; like, the whole concept: top-down standardization efforts with whole cryptosystems designed by committee have a very poor track record, and probably aren't the right vehicle to improve cryptographic soundness in the industry.
  - wolf550e 7y ago
    NIST FIPS 186-5 (Draft) has Ed25519. https://csrc.nist.gov/publications/detail/fips/186/5/draft https://csrc.nist.gov/publications/detail/fips/186/5/draft NIST SP 800-186 (Draft) has the curve definitions. But says only for Ed25519, not for X25519. They have a Weierstrass curve W-25519 that is isomorphic to Curve25519 that might allow using X25519 code, but that's way above my ability to judge. 'tptacek or 'jedisct1 or others will know. https://csrc.nist.gov/publications/detail/sp/800-186/draft https://csrc.nist.gov/publications/detail/sp/800-186/draft
    - tptacek 7y ago
      I will definitely not know! :)
- tptacek 7y ago
  Convincing the USG to raise Chapoly to the level of AES, thus essentially defeating the purpose of standardizing AES in the first place. The more productive approach is to work on convincing stodgy enterprises that FIPS is a bad thing (which it is).
- loeg 7y ago
  NIST doesn't like non-NIST ciphers.
mschuster91 7y ago
Corp IT is still on AD as AD is literally the foundation of everything MS based. No matter if Exchange, workstations, file servers, even Office 365 - all is stored in Active Directory. Even their cloud services, even Microsoft Partner Program, it's all AD under the hood. Sure you can use Samba / OpenLDAP / half a dozen of IMAP/SMTP servers for groupware but holy hell administering it is an utter hellhole of a mess compared to the MS offerings. Corp IT cares about two things: retraining costs for employees and admins, and efficiency. And Apache Directory Studio just doesn't cut it compared with AD Editor.
- kazen44 7y ago
  Also, AD is probably one of microsoft's best products. It's actually rather stable, and can integrate with nearly everything.
  - duelingjello 7y ago
    Fun ancient fact from AD administration c. Win2k3: AD can optionally replicate by sending email (SMTP) between sites.
    - kazen44 7y ago
      as far as i know this is still supported. i know this option has existed till atleast 2008.
BrandoElFollito 7y ago
One of the reasons it is still AD is that the management of users and computers is simplified. You have several layers of admin access etc. I use Linux since 1993 and love it. All my servers are on Linux. Managing them as a group is a nightmare. I would love to have an umbrella à la AD to have all servers and users unified inside.
- xorcist 7y ago
  People regularly manage thousands of servers using Puppet or Ansible and version control. The structured text configuration files all UNIX-like software utilize makes this trivial. The strengths of AD are more related to client software, where many of them uses the policy mechanisms therein for management. Maintaining servers isn't what it does best. This is a large part of the reason why "the cloud" is pretty much Linux native.
  - BrandoElFollito 7y ago
    I use ansible and salt to provision servers. It works great. It has limited to no use to manage users and their passwords or authorizations, their control over machines, remote access to a share and zillons other usages you need specialized software for. AD has it all natively.
    - xorcist 7y ago
      People with large environments that needs to be managed homogenously would beg to differ. How else would people manage these things large scale? It's exactly the kind of functionality that this software provides. Expressing rules in code might be radically different to someone used to a product like AD, but the learning curve is pretty quick and it is inherently more powerful.
      - BrandoElFollito 7y ago
        I do not know about products for large environments. Our is arguably medium (around 10,000 servers) and we use solutions where each does its thing, without any reasonable cooperation between the solutions: - users management? NIS - configuration management? ansible / salt - machines management? none (we use a homebrew system based off salt) - shared storage? NFS - policies? salt or ansible if they are common to groups of machines, or NIS if for people etc. I would love to have a unified tool (similar to what Zen was trying to do 20 years ago) but I do not know any. What AD does for Windows is nice (though I do not use Windows servers but I see their management from the side), Linux was intended to be standalone and this is what there are so many specialized, but disconnected management systems.

by api 7y ago

samgranieri 7y ago

Humor me: What would prevent DJB's crypto from being certified by FIPS?

api 7y ago
Bureaucratic inertia. I've been hoping for years that it'll be certified. They've talked about Curve25519 and Curve448 for a while but no movement so far. My insider sources tell me there's opposition, but I have no clue why... either the NSA prefers weaker crypto or (more likely) industry wants the status quo because they fear competition from open source superior products like WireGuard among many others.
- tptacek 7y ago
  I feel like having a restricted set of algorithms in FIPS 140-2 is kind of the whole point of having things like AES in the first place. First you get everyone to agree on an algorithm, then you mandate that algorithm for your own applications. I don't expect them to budge from that, and I don't think it has anything to do with quality. At the point NIST certifies XSalsa20 as FIPS-compliant, they might as well rename it AESbis. Industry prefers FIPS 140-2 because cryptographic expertise is extremely scarce and, prior to AES, commercial products were choc-a-bloc with broken hand-rolled cryptography. It's a rational decision to delegate selection of primitives to NIST. I think FIPS 140-2 is aging poorly, but I think that's in part because all cryptographic standards are aging poorly; like, the whole concept: top-down standardization efforts with whole cryptosystems designed by committee have a very poor track record, and probably aren't the right vehicle to improve cryptographic soundness in the industry.
- wolf550e 7y ago
  NIST FIPS 186-5 (Draft) has Ed25519. https://csrc.nist.gov/publications/detail/fips/186/5/draft https://csrc.nist.gov/publications/detail/fips/186/5/draft NIST SP 800-186 (Draft) has the curve definitions. But says only for Ed25519, not for X25519. They have a Weierstrass curve W-25519 that is isomorphic to Curve25519 that might allow using X25519 code, but that's way above my ability to judge. 'tptacek or 'jedisct1 or others will know. https://csrc.nist.gov/publications/detail/sp/800-186/draft https://csrc.nist.gov/publications/detail/sp/800-186/draft
  - tptacek 7y ago
    I will definitely not know! :)
tptacek 7y ago
Convincing the USG to raise Chapoly to the level of AES, thus essentially defeating the purpose of standardizing AES in the first place. The more productive approach is to work on convincing stodgy enterprises that FIPS is a bad thing (which it is).
loeg 7y ago
NIST doesn't like non-NIST ciphers.

mschuster91 7y ago

Corp IT is still on AD as AD is literally the foundation of everything MS based. No matter if Exchange, workstations, file servers, even Office 365 - all is stored in Active Directory. Even their cloud services, even Microsoft Partner Program, it's all AD under the hood. Sure you can use Samba / OpenLDAP / half a dozen of IMAP/SMTP servers for groupware but holy hell administering it is an utter hellhole of a mess compared to the MS offerings. Corp IT cares about two things: retraining costs for employees and admins, and efficiency. And Apache Directory Studio just doesn't cut it compared with AD Editor.

kazen44 7y ago
Also, AD is probably one of microsoft's best products. It's actually rather stable, and can integrate with nearly everything.
- duelingjello 7y ago
  Fun ancient fact from AD administration c. Win2k3: AD can optionally replicate by sending email (SMTP) between sites.
  - kazen44 7y ago
    as far as i know this is still supported. i know this option has existed till atleast 2008.

BrandoElFollito 7y ago

One of the reasons it is still AD is that the management of users and computers is simplified. You have several layers of admin access etc. I use Linux since 1993 and love it. All my servers are on Linux. Managing them as a group is a nightmare. I would love to have an umbrella à la AD to have all servers and users unified inside.

xorcist 7y ago
People regularly manage thousands of servers using Puppet or Ansible and version control. The structured text configuration files all UNIX-like software utilize makes this trivial. The strengths of AD are more related to client software, where many of them uses the policy mechanisms therein for management. Maintaining servers isn't what it does best. This is a large part of the reason why "the cloud" is pretty much Linux native.
- BrandoElFollito 7y ago
  I use ansible and salt to provision servers. It works great. It has limited to no use to manage users and their passwords or authorizations, their control over machines, remote access to a share and zillons other usages you need specialized software for. AD has it all natively.
  - xorcist 7y ago
    People with large environments that needs to be managed homogenously would beg to differ. How else would people manage these things large scale? It's exactly the kind of functionality that this software provides. Expressing rules in code might be radically different to someone used to a product like AD, but the learning curve is pretty quick and it is inherently more powerful.
    - BrandoElFollito 7y ago
      I do not know about products for large environments. Our is arguably medium (around 10,000 servers) and we use solutions where each does its thing, without any reasonable cooperation between the solutions: - users management? NIS - configuration management? ansible / salt - machines management? none (we use a homebrew system based off salt) - shared storage? NFS - policies? salt or ansible if they are common to groups of machines, or NIS if for people etc. I would love to have a unified tool (similar to what Zen was trying to do 20 years ago) but I do not know any. What AD does for Windows is nice (though I do not use Windows servers but I see their management from the side), Linux was intended to be standalone and this is what there are so many specialized, but disconnected management systems.