Re: Crypto software that *is* exportable from the USA
Paul Sheer wrote: I remember someone was maintaining the debian release of this software (although then, it did not support encryption). Please get the latest version from: ftp://lava.obsidian.co.za/pub/mirrordir/US/ I maintain the Debian package of mirrordir. The last version I packaged was 0.9.29. I have not packaged any of the (many) more recent versions because: - I would not be able to include the new crypto features in the package anyway due to US export laws. (Debian packages are binary only, and FTP connectivity is not assured, so the download sources from South Africa model does not work.) The non-us archive could host an up-to-date version, but someone else would have to maintain it. - Most of the recent releases have been bug fixes of crypto features. Besides the above problem with crypto, it does not appear stable. - The last time I checked, mirrordir fails its own self check routine due to a security check. However, the situation it complains about looks okay to me. - Jim Van Zandt
Re: Crypto software that *is* exportable from the USA
- I would not be able to include the new crypto features in the package anyway due to US export laws. no, the US version contains no crypto code. (Debian packages are binary only, and Both the source and binary US versions of mirrordir contain no crypto code. FTP connectivity is not assured, so the download sources from South Africa model does not work.) I will set it to only download when the crypto stuff is used, so that ordinary usage does not cause an automatic ftp transfer of the scripts. When users discover the security features, they can then bother with not having ftp connectivity. Is this OK? - Most of the recent releases have been bug fixes of crypto features. Besides the above problem with crypto, it does not appear stable. There have been some very important bug fixes in the ftp code. Also, the crypto stuff is now quite stable. -paul
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: But you're biting your own tail here. Where do you get that good checksum? Any place which is acceptable to the package maintainer -- perhaps out of a pgp signed archive. Remember, the start of this discussion was an (FTP) mirroring program that got around encryption export laws by importing software from a site in South Africa. The problem isn't in *producing* a package, it's in *acquiring* that package later. What happens if someone successfully attacks a site immediately before you mirror it? MD5 checksums aren't adequate, since the attacker can forge new ones. Cryptographically signed checksums don't help, since the software (at time of export) can't include the software to verify them. Downloading PGP from the ZA site won't help because you can't verify *its* checksum. Even if you hardcode in the signature for a known good copy of PGP, download and verify it, then use it to download and verify the latest version, *how do you know your original package was valid*?! Maybe the copy you downloaded actually downloads from blackhat.com.za. Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. And that, it seems, is exactly the problem that this program seeks to fix. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The problem isn't in *producing* a package, it's in *acquiring* that package later. What happens if someone successfully attacks a site immediately before you mirror it? What happens if someone replaces a PGP signature? Answer: people notice. [Consider an advanced attack, launched from a router which changes certain packets in-flight so that some files, when downloaded, are different from what's on the server, for some range of client ip addresses. I don't know if script kiddies have a toy that does this yet, but it'll happen eventually.] MD5 checksums aren't adequate, since the attacker can forge new ones. Cryptographically signed checksums don't help, since the software (at time of export) can't include the software to verify them. Downloading PGP from the ZA site won't help because you can't verify *its* checksum. If you can trust the debian packages, you can trust an md5sum contained in one of those packages. Perhaps a distributed auditing system (like what was used for the RSA challenge, but instead periodically downloading files and verifying md5sums) would be a good thing -- to set off alarms after a site has been cracked. [If no alarms go off for some period of time after you've downloaded a fresh copy of the system, you can be reasonably confident that you got a good copy and that the signatures you have are probably the correct ones.] Perhaps useful would be independent signature clearinghouses which let you check md5sums without talking to the site you got your packages from. [The more paranoid might want to check against a large number of sites, and might want an auditing system to be in place as well.] Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. And that, it seems, is exactly the problem that this program seeks to fix. Obviously it can't fix the problem for the past. However, it might help in the future... [Perhaps more important: security oriented technology can only be a part of a secure system.] -- Raul
Re: Crypto software that *is* exportable from the USA
On Sat, 23 Jan 1999, Bear Giles wrote: It supports strong encryption but is exportable from the US because it does not have encryption compiled in by default. Instead it downloads the scripts it needs from South Africa when it runs for the first time. This is *extremely* risky behavior. [...] South Africa has no export restrictions on cryptography. It supports file transfer and secure logins shells. I meant that mirrordir supported file transfer and secure logins shells. The scripts are downloaded via ordinary ftp. As an aside, why would a mirror program even want strong encryption? Encryption != authentication, although the implementatons have significant overlap. It started as a mirror program. Now its a suite of utilities including a secure shell. I don't think the problem is as big as you say. To illustrate, the connect script follows. We are talking about less than 200 lines of script - an extremely small amount. It could easily become widely publicisely what these scripts are. A script to do checksums on the package itself would only take a few lines. I admit that its not foolproof, but it can easily reach a point where its highly improbably that a user could have a compromised script. On the other hand, users would have the ability to do secure logins on a stock standard system, without having to install a single thing. Also: there is no GPL secure shell (as far as I know). So even the International version of mirrordir with compiled in encryption (i.e. not in scripts) is a worthwhile package which can be downloaded from outside the US just like ssh. It seems to have recieved very little attention considering the need for a GPL secure shell. Is there something that I am missing here? -paul /* client connection script, exporting this script from the US may be in violation of the US munitions export regulations */ Huge *r; Huge *s; Huge *p; Huge *q; Huge *g; Huge *m; Huge *x; Huge *y; Huge *X; Huge *Y; long l; long type; char *c; char *prot; l = strlen (dIffIe--HelLmaN\n); if (l != send (dIffIe--HelLmaN\n, l, 0)) return 0; prot = 1234; prot[0] = 0; prot[1] = 1; type = typeoption (); prot[2] = type; prot[3] = 0; if (send (prot, 4, 0) != 4) return 0; p = prime (type); g = 2; y = random (typesize (type)); Y = pow (g, y, p); if (writehuge (Y, 0)) return 0; l = strlen (DIfFiE--hEllMan\n); if (recv (c, l, 0) != l) return 1; if (strncmp (DIfFiE--hEllMan\n, c, l)) return 1; if (!(X = readhuge (0))) return 0; m = pow (X, y, p); huge2bin (m, c, l); initarcrd (c, l / 2); /* stream cypher initialisation */ initarcwr (c + l / 2, l / 2); x = 0; y = 0; if (!(y = readhuge (1))) return 0; if (checksavedkey (y, type)) return 0; if (!(r = readhuge (1))) return 0; if (!(s = readhuge (1))) return 0; q = p 1; /* signature equation */ if (m != (((pow (g, s, p) * pow (y, r % q, p)) % p * r) % p)) return 0; return 1;
Re: Crypto software that *is* exportable from the USA
Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgp4w5Qla0dtf.pgp Description: PGP signature
Re: Crypto software that *is* exportable from the USA
On Sun, 24 Jan 1999, Wichert Akkerman wrote: Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. It's called psst. (Or at least, the project is called psst). If you want a URL, go to freshmeat, find the GNU privacy guard home page, and follow the link :-) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Crypto software that *is* exportable from the USA
Wichert wrote: Previously Paul Sheer wrote: Also: there is no GPL secure shell (as far as I know). But people are working on that. From what I hear it's on the verge of becoming useable. Don't ask me about the name, I always forget it. MIT Kerberos (4 and 5) is open source and provides strong authentication (and optional encryption) of telnet, ftp, rsh, rcp, and more. Kerberos 5 is currently US-only, but Kerberos4kth is a foreign implementation that is available at nonus.debian.org. I believe this site also has an SSLtelnet program, built using SSLeay. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
It supports strong encryption but is exportable from the US because it does not have encryption compiled in by default. Instead it downloads the scripts it needs from South Africa when it runs for the first time. This is *extremely* risky behavior. FTP and HTTP sites *are* compromised. Software packages *are* compromised. Look no further than TCP Wrappers... A major part of the security process is having a human involved who knows what software was downloaded. A human may later see a pertinent news report and act on it; scripts will not. A *mandatory* part of a site's security process is having a human who has the final authority to approve the use of a package. A human who can be held accountable, and thus is motivated to pay attention to what's going on. A script blows off this part of the process. South Africa has no export restrictions on cryptography. It supports file transfer and secure logins shells. It can offer secure file transfers and multiple cryptographic checksums, and the end result is just as unacceptable. *We must start with the assumption that the server might be compromised.* If the server is compromised, secure login shells and FTP won't help. If the server is compromised, checksums (even MD5 checksums) won't help. The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. What's the answer? Download *PGP* to verify the checksums on that PGP file,... ? As an aside, why would a mirror program even want strong encryption? Encryption != authentication, although the implementatons have significant overlap. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. Actually... for the case of a pre-planned upgrade, a simple md5sum check -- that the downloaded file has a md5sum which matches an archive which has already been examined and seems clean -- would be sufficient (at least in terms of mechanical integrity). -- Raul
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: The only thing resilient to compromised servers are cryptographically signed cryptographic checksums. Which requires PGP. Which is not exportable. And which requires a chain of trust to evaluate whether to trust the key used to sign the checksum. Actually... for the case of a pre-planned upgrade, a simple md5sum check -- that the downloaded file has a md5sum which matches an archive which has already been examined and seems clean -- would be sufficient (at least in terms of mechanical integrity). But you're biting your own tail here. Where do you get that good checksum? You can't get it from the archive site, since a compromised archive implies that the local MD5 checksum may also be compromised. If the attacker doesn't replace the checksums, great. If he does If you distribute it as part of your package, you can't load newer packages... which makes the entire exercise academic. If you distribute it from a trusted site, then compromising *that* site results in the same problem. Even if you try to bootstrap the system, how do I know that the package I get was the one you wrote? How do I know that the TLD tables haven't been corrupted, or a DNS entry hijacked, or And again, what is the problem you're trying to solve that requires strong encryption in the mirroring software? AFAIK, MD5 checksums are *not* export restricted. Bear Giles [EMAIL PROTECTED]
Re: Crypto software that *is* exportable from the USA
Bear Giles [EMAIL PROTECTED] wrote: But you're biting your own tail here. Where do you get that good checksum? Any place which is acceptable to the package maintainer -- perhaps out of a pgp signed archive. If the package maintainer can't produce a trustable package, it doesn't matter how fancy you get. Bootstrapping is hard -- best you can do for the general case is compare notes after you've gotten a secure system up. The one thing you have going for you is that corrupted packages have to be visible, to someone, or they're no danger. -- Raul
