Cryptography-Digest Digest #977, Volume #9 Tue, 3 Aug 99 08:13:06 EDT
Contents:
Infallible authentication scheme (Michelle Davis)
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a Byte?)
("Magic")
Re: Americans abroad/Encryption rules? (W.G. Unruh)
Re: Americans abroad/Encryption rules? (W.G. Unruh)
Re: The security of TEA ([EMAIL PROTECTED])
Re: [Q] Why is pub key cert. secure & free from spoofing? (W.G. Unruh)
Re: Americans abroad/Encryption rules? (W.G. Unruh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michelle Davis)
Subject: Infallible authentication scheme
Date: Tue, 03 Aug 1999 08:29:52 GMT
A week ago I posted an idea of mine for using hash functions in
identification. I thought the system was quite solid, but it turns out
that it was vulnerable to a dictionary attack: only 320 bits of the
512-bit string to be hashed were the secret key (the shared secret),
and so someone might attempt a narrowed-down brute-force search. Also,
there was some question about the implications of the key's
randomness, the way in which it is generated, and how these factors
might be exploited. Basically, it all came down to the question, is
there sufficient entropy in the message digest, such that someone
working back from the message digest wouldn't be able to use a
dictionary attack to discover the string to be hashed?
I've come up with a solution that solves this problem, and it looks
too good to be true. I'd really appreciate it if someone could tell me
if I'm right or wrong, because I've gone over this a hundred times and
can't find a problem with it. The scheme is as follows:
Key generation: A central key-seed is split in half. Each half is
coupled to one half of a user ID, such that two 1024 strings are
obtained (The 36-bit ID comprises only 18 bits of each). Each of these
strings is run through 3DES, with the key being a derivative of the
central key seed. The two results are separately hashed. The two
message digests are joined to form a 320-bit secret key. This key can
be extrapolated by any entity knowing the central key seed, without
having to keep a database of secret keys.
Authentication: The user attaches a timestamp to his ID, joins this to
his secret key (320 bits), and pads it to 512 bits. This string is
then 3DES-encrypted, using a key which is a derivative of the secret
key. The result is hashed, yielding a 160-bit message digest. The left
80 bits are sent to the authenticating entity, together with the ID
and timestamp in unencrypted form. The authenticating computer
performs the exact same operation: obtains the user's secret key
through the procedure detailed in Key Generation; attaches the
timestamp and ID; pads; encrypts; and hashes. The left 80 bits of the
result are compared with what was sent by the user, and if equal, it
authenticates.
Attack: Now comes the good part. This thing is completely and utterly
resistant to attack. Let's say our attacker knows 192 bits of the
string to be hashed (timestamp, padding, etc.), and wants to use this
to do a dictionary attack. He finds that since the 512-bit string has
been passed through 3DES, what has been hashed is in fact a completely
pseudorandom string, which has zero known elements (we are working on
the still-valid assumption that a feistel cipher like 3DES produces
effectively pseudorandom ciphertext). So maybe he wants to attack
3DES. Well, let's assume this is 2010, and our attacker has a machine
which can break 3DES in one second flat. What does he use for his
analysis? All he has is a partial plaintext. He has no ciphertext, no
idea what the key is: In other words, absolutely nothing. _If_ he had
the 3DES ciphertext, supposedly he could do a correlated dictionary
search, using known elements of the plaintextext, and find the unknown
320-bit secret key. But to obtain the ciphertext, he must first get
back to 512 bits from a truncated message digest. This, even in the
year 2100, could take several thousands of years, unless serious
faults were found in SHA-1.
And that's that.
------------------------------
From: "Magic" <[EMAIL PROTECTED]>
Crossposted-To:
alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++,microsoft.public.vc.language
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big is a
Byte?)
Date: Tue, 3 Aug 1999 03:24:41 -0600
> > > Guenther Brunthaler wrote:
> > > > Well, "byte" is simply short for "binary term" ...
I might be able to be convinced the bit is short for BInary Term but I truly
think that byte was some early programmer's sick sense of humor, since half
a byte is a nibble. 'hey... if you take a big bit of that sandwich, it
would be a nibble, eh? And if you took a bigger bit it would be a bite
heheh. Oh, but bite looks too similar to bit.... soooo..... Lets change the
i to a y! YES Byte! Oh... and heres something that will confuse those
damned Brits. Lets make a kilobyte be 1024 bytes instead of 1000! HAHA!!'
Paul
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 3 Aug 99 10:39:18 GMT
[EMAIL PROTECTED] (JPeschel) writes:
>>[EMAIL PROTECTED] (W.G. Unruh) writes:
>>Sorry. I was wrong. There is a personal use examption also under the EAR.
>>And it is much less stringent than the EAR exemption. In fact it seems that
^^^ ITAR
>>you can permanantly export encryption under the personal use exemption.
>>The one under ITAR became moot when control of encryption passed to EAR.
>Good work, Bill, I knew someone would find it. (You did mean to write less
>stringent
>than the ITAR exemption, though, I think.)
Yes. The ITAR had a huge list of requirejments for record keeping and
reporting and keeping the crypto under your personal direct control at all
times.
This one even lets you send it before or after you leave the country.
>I seem to recall quite a bit of talk praising and condemning the ITAR exemption
>when Schneier first mentioned the rule's appearance in the Federal Register. My
>feeling is we'll take what we can get.
>Joe
>__________________________________________
>Joe Peschel
>D.O.E. SysWorks
>http://members.aol.com/jpeschel/index.htm
>__________________________________________
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 3 Aug 99 10:42:29 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>if your off us soil and you send encryption to any one you can"t be accussed
>of exporting from the us since your exporting from some where else.
that is true, unless you brought the crypto out with you, inwhich case you did
export it. However, if you as a US citizen supplied Ben lauden(?) with crypto,
even if you had gotten it off a Finnish server, I suspect you would find yourself
in trouble.
>
>David A. Scott
>--
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> http://members.xoom.com/ecil/index.htm
> NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The security of TEA
Date: Tue, 03 Aug 1999 11:12:59 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Here let my post some encrypted binary data to see if you can crack
it. =)
>
Heres a easy one for Little Tommy boy tocrack. do you know where
to begein.
begin 755 fortom.cpt
hA1ca75Ay70Bn70gbOGkY6KAj7m+b9qAV70ld7mgYQoNeTG3xRattTrEaJ03l
hMr2mOEMBOGkY6KAj7m+b9qAV70ld7mgYQmAYDbAY7XckA1ca75Ay73IqRbVi
h7a6YA4oxBkoB+YYA1UIAOKVq8bBkRnle7YdWTrpoNHsyPL-nNKIb947bQndz
hQqZcMKBlRaAiRKddQqJfP5BHPrFoTqpp74cf8WBnHLwb8ape12ZhMW-mT0NZ
h75Ua7qteA53xPWQYNrFoA5tXNm3bR5RnNKJyOKdhPGNw8G+bFXQVNqob7qZV
hQqRhPGRqPrVZN5xW717kM0AaRqtXF+NWQmNeOrYd+YYA1UIAOKVq8bBkRnle
h7YdWTrpoNHsyQL+qRmhZ65VnO1-e7qJzP0xoRqIzMWh9+GBVQ1-qTqdYSLJc
h8bAyI4gaRmQ8ErtlPmpaOKQbPaBbPK+g7rxg6KllSHgYPqskTrFZMLBdPLQv
h74cb9aJmN0ojRq3oT1FiRaVdN4BZDKFVPLBkPbwkQrJcQ1NkQ5-S1bliDKEY
hM4BdPalnOX2VRrkgN47WCa+YOXkYQb7pA4dbRm-dOr2r80ha7qUYQnNVOKZd
hO4BpP4ZdOKtnQqJhQXMYQb7WTqxVP3sIQqcbP0hn6KYYQW7WMW-rPX-mQqAv
hMmhb6KNZOXNr7bgkRbBeMLBdPLQv75xj90lrM0te7qBcMHRYObVdNbUY7qhV
hDXlqPrptTbhe8ZsII4gq74Fr95tZRGdUOG-VM12VMK6eRL7o7qdeSLBZO5sk
hR5xZRWdiQ4cxMmhiCWlkOGMjR43eObUVQ4Eg7qteA53xPWRhOLER4adoOn-v
hRr-nPLUb9rZeMXRaO4taMqwVR5saMrtbCapXDX7e7axySKhnMLBzOb+YMLYb
h94pbOKBvPapW6Is90EN+LaFlQq-ZQ5BVO5ZWOKdm716yMaczMGhZA0lZNGRa
hOKQbNXQVQ4BdQqBVQqxhPGQYN5JcA5Jc70RqMGAzMKpnF+NrO0Re7qxV9nRd
hMGkAOKVq8bBkRnle7YdWTrpoNHsyQqcxM4FkNmkYIH3eR5AbSmhY70s6MqwY
hAWBWRnxV81EyAXdYQGReOqpS1add9GlrN0xeN5EbSmhY74cUOqsY8allDWFZ
hO4skTqUaM03zMmAm74pi7KYYPX2jMKZfOX+VMbsaOWhZDKlkRXNq7aptTbtd
hQrBzOaRS1axp7bkYRGheOW-iMKBpP4ZdEaJb6LdoOXdfO1d+MbJVRX7n75Eu
hOaxcDW6Y6FdUQW-kNWxh75wgMWhkCqMYS1dcMndyQLRX90+r0EYmR5hW85sY
hO0ojQqVW9mxcRrVdNKFwTGAYJnIYTrJZA5tXNnduMGAeOrsb9KBe7XQjQ43d
hSqBpOmkgOKVq8bBkDX6YM5BwRHM91WdlQGAkNKIbCqZdPXJe7qZn9mJnOq3d
hQqBVQqxhPGQYN4AkMrxeMH-ePKoo747nOKpeNKBzRKJoT0djMmkxPqsYQIRV
hQXNkMlQOJbBeML2yNbMbQ4FdNk2C12Y4I4VWMKBsOrZiQKsY6rNkDX7cOXdY
hS5waMXdmML-nTKFmOLhZPnQjQqwbP0ljQaYvQmhhDGBkRXMYM5BwRHdePG-e
h8+tNQ57r90lxPXNx7r-aT1-qOrsh7q7e7qkYOXhV7adlMqZlOm3u746xM0hY
h7a7WO13WNbFiM0oVNaAlMbUeQmBRQGNq7adlMqZlOm3u0EYyQLVnOKtV6H-a
hTm-YNm7nNKwxMbZrQqdeDXxVO5pYS1ddRbBtRaMmQ4tpNGlZPmQjObJoSqBX
hMGkUMqte7qdbTnwYPrEkQbJmP3sINakfMLUdOGlHOGNV7rFjOX-Y74waOKxh
h7qdfQ0+YNqVpA5RXQ5wyNKor75xj95tV6G7xMW-VNWxYRmkUOGhkCqMYS1dc
hMndwSKZm83sIQ4gq70ZJD46a6G3uQrFcMKBqPK+Z7qZVA4ldSrBZQ5htT5hY
hO1Mk70A1RatoCWlhRKwjNatX9nRdMGkjPaRV60BhQ5BkPbwR4bNjRmQyQqcz
hO0hZ90lVPm-xTb-nOWQiM4YeRL7o7qNUDX7eMXdbSLNe71RrRq6XR4taCmlW
hQmlW7rFjOaBhPLwx8GgY4aIYOXhV0l-pTbZoTGBePKkx74pa64-r6GJURG-o
hM0tY75sgNbVfDGwYTrBdMqZXQLpX713lT0AbMKRf647X6HdUQW-nNmdm75gU
hOqQYAbBoSn7q0l-lTbsaQ1hv74omOKsbDaJcPKBxMapaNWoVOq7dQqBVQqxh
hPGQe0l+R4VB2TLBuMKImQKRnNGl-Pm-xTb-nNWlj73kvO4lqAasYTHhVNL3X
hA4td70-vMGAuMWhn6KYYNmdXMbAbRWlo74EcQKs7KKFhO1Ne7bBYA57bQXMy
hQ4gq74tzDKZeQWdUOG+ZP1Bp7W7d7o7WQrRgSmcYMbIwA4tiMLBkMLEzTGhY
h7a7mN13vMaEbOGdhME31Q47cDmBgTmJV7atsRHdpNHtv74omOKsbDaJkOKBv
hPqIb9G-lQ0tdRKtdD5JVSboY7ZBqA4tiMGcyM4kx6rwfOLVgN4AhN5-n9Is9
hMLExMaJrCaleDWFhObMkQbwaNHRuMKRx70hH6LZr9KBsPqJd9ndiQGkjPbZr
h7mBVQ1-qTqdYA5gaMXdmMGAuQ0hk64-c6G3e0UdXOX-cMq6cQqtUQq3xDWRg
hMncmQqdm7bBvT5QqObVi7a6c6G7VMm-kNmNj75IaQWhUBa-qNmBk7bgkAbZq
hQ52yMaczMGhn6KY70mlxPaRiMG7h74cUOqteAatVDWFhObMkQbwaRXNhQ4kV
hMKwdF+M70odCOrBc9m3s74UgMKdlDrQcDWRgMncmIKZh713vMakVMGhcDqZq
hRX3aQqZdO4BU74cUOqsaQq-gSn-j7bVzO1djRpsINqgqNq-W9G6Y6FFbMasb
hSmhY74YbN5Zx6rRhQHoYRaVzRqVbOLBgQKoU80hiDGlnO0xX7q3oN4BqP4Yx
hPqtqQrdfOrBnNrFYA4td0JZlQaMVQrZiDKYYM0pq7qNiMmNm75gVPaVgQrFh
hQXwYN5wkTqlXRWFgPLQbMKIb646YRGhe7r-pM0-YRrxb7mhBBGBxQGMYMbJy
hBqs91WFzObRnRrtY6GloQmlWRrFiMGEh75IaQWhbAaoYSXNrMrNpQqsaQ1hr
hRmAlQLxn7a6e6KB5O5RWSGNn80kkO5sYDbNrObBaMlQOQrhoMHJfO0AuMWhy
h7bYYNGko7rZcSX2VOq+h7qphDqNrDXtZTndmRHddQXNgQr2uQ5xW7mlnO1Rb
hO5Jn9ndiQLtdN4Fe64NeObo71-QO4IBdQLBxNKpnNqRi8aQYPWojQqVW9q32
hT4Ix7Gha7bRkQHoYQbIkMKxjQ5BeP4NnR5Zc9btZP4o01EoB+YYg8G3Y8WMd
hTWsdArsd8nQxDHQf8Lsn8Gty8GMeN02d94sW8Woe6asg8G3Y8WMdTWsdArsd
h8nQxDHQf8Lsn8Gty8GMeN02d94sW8Woe6Ys9FLYxPqFqR5+YQ1lkMm+R4VQA
h1FcyP4kXMGhy7bYYPGdYMW-nNmdm74+UQrxcBWBoP1lXR5hxDXcaHGQyQ4kw
hPmhe90lfPmxq7q2bMmdpQ4+g7rxhDaM730Rf7apWSKtX85BhOmAO75lc7mhk
h6G3UQqVWTKBsOrZdMKFqQqtfQ1Nx7bJWA5hcTGRqPKoo74Ri6aYYRGhiQmsb
h9kcVR4+cOGhkD+sCOm-V7bBYA5RzRnNmMWApOrYb9qJcN1+jMbVrM1-YM0kx
hO0hkCqMYJnpkMqVyRKsaNHpu74cxQ5Za7qZkQaB47qFcMKFp75gcOLw7KKlk
hRXNq7adpTqdeMLBeOmAVMKdXNmkYG1QcR0-VPX-p74obMmhrAaJVAbBZO5sk
hNbBoQ0NzO4we747eCLtVNWpiNKlW6Is90EN+HaoY8allDXhZQ5wkQLFz707f
hML+bPKFdCWlfQqBgO4peOWppRmkaRGhr7aFXSm-kPrJyMnMaR1xvNL+q74se
h74phPIs3OaIbPXQVNqwcRLZhDqx2S17r857lMalbRXQkMKQa8Wgb+0lUPWoc
hQm-UOXQVQ4BdN4BVA4UYQmcYOrhtT1dkMG3b74kpQ4tdNE2CMnNv7oYbTn3i
hOKIuMWhBR4xcDXFVQXdmQLZh70Rl75cwQGhaCWlrPWlV7q3o9kcVNK3dNaZc
hBWoYDVde7aVpQLNjQ0cyHGArOkMB9aZk6HRU7qJlOX3sOq6g8mhrD0BhS5Bx
hOKwkS5hkMLBzObcbP47d9WlkPaBwNbYbOGNYO0kjRKtVQrRfDW-VO5skTLwa
hNLBkOrQq8UMB+5UYNGleR4sUSqBpNKQg7qNlA4gYOXddMnMkMbxbO1xb8UtN
h0E2C0qYYNmlxMbRaTGpYM0-dQqBf7aFgA5AYHnpxA5FdQ5BgML+XOqJo64tc
hN4BaMG-yM1MVMK6eRL7o7ksCTHldOrhyR1FZOnsyNKor757cD5sYQXdwQqJe
h9mRiMLwb65wYAKlfObwYOKUkOLJn71NkNr2eR5wb846YO0tzO57nPWpp0EMh
hO4VlDaNeObBZO5skRbJoMnNe75QvMGhr85xrRWlxMmsb9kdb75UVPbUY6r3f
hSG3ZOndnQKxpMG+yNKoe74Fn6KZq12ZzRKxZMmNgRm-dNKsY7qhVNrBxOKxW
hA5lbQHxe74kV747nCWlfRWoX7oYUMaBmPK2UOqdqDrcYQ1lk7aVpMqddOW-r
hNawq8UMB24Bl6HNwMW-iSqBUQ0kkO5tqQqlnQ5BqPqZvDVQA0JYLGrQvMLYb
hDKFZPqBvPq3n9kcVP4ozMWheD5RgRnpX7bRZQr6aQ1kyRq6e8Wgb4apWN4Bi
hOKEbNm7lR5JdN4Fd6rNkRnpX0l-YTndzOmMk70AO74BcCKYYRGhaR0-rTGla
hRaoY7qVfDaNrDXde7b7lTbtz71dk75+wOKsbDapx9qAjHW-fNWVY75wUObhc
hBUsCPW3fMKVlTKYaTHlf74+mOWhU95UYNmlx7qNpOWMVNK6h7rtrBWBVTm-h
hOaAkN57bQ5BhOqwZMGhaOLxoN0-aMKZY9nBnOqsZMaMcLUZrTmJhO5okOLJn
h70RqMGAbPKNWOKBW6HFxPbFiMGEVRqAYMbxgCapXDWdfQqVXRLNU8bAyI4gm
hQ0loOLhgM1QjQqViT4BcRk31MqtrCaFeSnQYQbIkQbww716yO4cbQ4RWOLZk
hO0xaQrYbOGln75kgO5hcBWBnRXkYO5xpR1dUNG-e74MxNrZyCLVhPWoV0Ud+
hNXJYOW-dQqBV6KMYTm3V7bgkT5Jm71ls74MxNrZyCLVhPWojNalUM13cQ4EY
hR0hf7bQYOXhVR5wwA5hcM5BbOrNnNqFm7KU70m3uTW-aMHcVOqddNWhe7ata
hSm2YOLkkNKtjO1deTGAXNKVgCWlZPmQjM4Jn9m7j74ovRKdxQqlWDWRgMrQy
hA1d2QGQyQ4guRkMB65wYNn3eMWkbPWpZ74Ix65UYCqNqSroY7YxXRHdjQ5Br
hOWAoOqFXOKFVM0xvPms8-Is98IwVRK7r7qdZQ5B5NqVWSLNeOpsI74+kNLZp
h64-cEGJiR0tjPX3rNLsh8KtU7UsCArsd8nQxDHQf8Lsn8Gty8GMeN02d94sW
h8Woe6asg8G3Y8WMdTWsdArsd8nQxDHQf8Lsn8Gty8GMeN02d94sW8Woe6asg
88G3Y8WMdTWs73+
+
end
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: [Q] Why is pub key cert. secure & free from spoofing?
Date: 3 Aug 99 11:02:20 GMT
Jerome Mrozak <[EMAIL PROTECTED]> writes:
>I'm a rank newbie, passing thru security issues for the 1st time. I've
>been exposed to the public key method, and an explanation showing
>host-spoofing:
>A --> Spy --> B,
>where B believes the public key it received is from A when it is really
>from Spy.
>My text claims that use of a public key certificate authority (CA) will
>keep the spy at bay. My question is: if the Spy can insert itself
>between A & B, why not between A & CA, or B & CA?
He can. That is why the standards that the CA applies in verifying that the pulic
key KA is actually from A is important. For example, the Verisign standard
certification is almost useless, as they simply require a request for
certification to issue one. They have more stringent ones (eg requiring a
signed application from a JP,) up to submitting a whole a raft of documents
attesting to the valididty of the relationship between the key and the person.
(Those cost serious money).
PGP uses the "Web of Trust" model, where you trust B C D and will only accept keys
signed by them (or by people who are attested to by them,...)
Ie the value of a CA is just another bit of evidence, or greater or lesser
reliablity, that the key has not been spoofed.
------------------------------
From: [EMAIL PROTECTED] (W.G. Unruh)
Subject: Re: Americans abroad/Encryption rules?
Date: 3 Aug 99 10:44:50 GMT
[EMAIL PROTECTED] (wtshaw) writes:
>> if your off us soil and you send encryption to any one you can"t be accussed
>> of exporting from the us since your exporting from some where else.
>>
>It would seem that way since we allow foreigners access to crypto in the
>US now, but that is probably because we want to be nice to these foreign
?? Hmm, Ambiguous. See below. The general definition of EAR seems to say that
export means transfer to a foreign national, but for crypto a different definition
seems to apply, which does not include that. So if you believe that 734.2(b)9
superceeds 734.2(b)2 (which it seems to) then that is correct(transfer to a
foreign national in the USA is legal).
EAR 734.2
(b) Export and reexport
(1) Definition of export. "Export" means an actual shipment or
transmission of items subject to the EAR out of the United
States, or release of technology or software subject to the EAR
to a foreign national in the United States, as described in
paragraph (b)(2)(ii) of this section. See paragraph (b)(9) of
this section for the definition that applies to exports of
encryption source code and object code software subject to the
EAR.
...
(9) Export of encryption source code and
object code software.
(i) For purposes of the EAR, the export of encryption source
code and object code software means:
(A) An actual shipment, transfer, or transmission out of
the United States (see also paragraph (b)(9)(ii) of this
section); or
(B) A transfer of such software in the United States to an
embassy or affiliate of a foreign country.
(ii) The export of encryption source code and object code
software controlled for EI reasons under ECCN 5D002 on the
Commerce Control List (see Supplement No. 1 to part 774 of the
EAR) includes downloading, or causing the downloading of, such
software to locations (including electronic bulletin boards,
Internet file transfer protocol, and World Wide Web sites)
outside the U.S. (except Canada), or making such software
available for transfer outside the United States (except
Canada), over wire, cable, radio, electromagnetic, photo
optical, photoelectric or other comparable communications
facilities accessible to persons outside the United States
(except Canada), including transfers from electronic bulletin
boards, Internet file transfer protocol and World Wide Web
sites, unless the person making the software available takes
precautions adequate to prevent unauthorized transfer of such
code outside the United States or Canada. Such precautions
shall include ensuring that the facility from which the
software is available controls the access to and transfers of
such software through such measures as:
(A) The access control system, either through automated
means or human intervention, checks the address of every
system requesting or receiving a transfer and verifies that
such systems are located within the United States or
Canada;
(B) The access control system provides every requesting or
receiving party with notice that the transfer includes or
would include cryptographic software subject to export
controls under the Export Administration Regulations, and
that anyone receiving such a transfer cannot export the
software without a license; and
(C) Every party requesting or receiving a transfer of such
software must acknowledge affirmatively that he or she
understands that the cryptographic software is subject to
export controls under the Export Administration Regulations
and that anyone receiving the transfer cannot export the
software without a license. BXA will consider
acknowledgments in electronic form provided that they are
adequate to assure legal undertakings similar to written
acknowledgments.
>technicians. If you are overseas, don't think that all of your rights
>travel with you, as government all too often does things it can and
>shouldn't when it thinks it can get away with them.
>--
>MY lock, MY key.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
