From owner-freebsd-ports Mon Nov 1 19:25:57 1999 Delivered-To: freebsd-ports@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 8A56314E0E; Mon, 1 Nov 1999 19:25:49 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id WAA22988; Mon, 1 Nov 1999 22:25:47 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 1 Nov 1999 22:25:47 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Kris Kennaway Cc: Issei Suzuki , security@freebsd.org, ports@freebsd.org Subject: Re: OpenSSH patches In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 1 Nov 1999, Kris Kennaway wrote: > There is some confusion (at least to me) about whether software which > provides a cryptographic function (like SSH) but which links to an > external library to provide the actual cryptographic code is liable under > the export restrictions. > > Otherwise, everyone in the US could just write their cryptographic code to > a certain API and have it fulfilled by an internationally-developed crypto > library, thereby defeating the intent of the restrictions. I'd very much > like this to be true, but I didn't want to risk it being false, seeing as > how I'm a guest in ths country and as such very much subject to the whims > of the INS :-) Yah, me too. My solution was to do the code as employed by some existing US citizens and let them deal with the legal consequences. :-) Of course, I'm due for US citizenship any day now.. Pity about all those "or we'll revoke it" clauses in the application and elsewhere. My recollection is that in general shipping things with APIs strictly used for encryption is still a no-no. The usual work-around is to define a general-purpose data transform API. In Coda, we discussed doing this and providing two modules -- an XOR crypto module, and a compression module, just to show the generalness of the whole thing. Both crypto and compression retain state over the course of the sessions, participate in a chat protocol to get going at the beginning, ... The other one that often works is that code for authentication is fine--i.e., MD5 hashes and MAC code. That also requires keying material, et al. What is the export deal on ebones/Kerberos? Ebones is exportable, but I don't remember a) whether it had to be reviewed/approved, and b) whether or not it actually had direct crypto hooks. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message