home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / alt / security / pgp / 352 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.6 KB
  1. Xref: sparky alt.security.pgp:352 sci.crypt:6010
  2. Newsgroups: alt.security.pgp,sci.crypt
  3. Path: sparky!uunet!mcsun!Germany.EU.net!rzsun2.informatik.uni-hamburg.de!fbihh!bontchev
  4. From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
  5. Subject: Re: Legal Stuff!
  6. Message-ID: <bontchev.724976946@fbihh>
  7. Sender: news@informatik.uni-hamburg.de (Mr. News)
  8. Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
  9. Organization: Virus Test Center, University of Hamburg
  10. References: <bontchev.724943800@fbihh> <9212211051.AA59278@chaos.intercon.com>
  11. Date: 21 Dec 92 22:29:06 GMT
  12. Lines: 60
  13.  
  14. amanda@intercon.com (Amanda Walker) writes:
  15.  
  16. > > (I just wonder how all those crypt(3) functions in the Unixes around 
  17. > > were exported...)
  18.  
  19. > They weren't.  Export versions of UNIX have the crypt(3) functions removed
  20. > from the C libraries.  The login program (which uses crypt(3) internally to 
  21.  
  22. Very funny... Now, our system, which is a DEC Ultrix, running on a
  23. VAX, -does- have the crypt(3) function... The funnier thing is that it
  24. doesn't have the crypt(1) program, which is a much weaker encryptor...
  25. On the top of that, there is a des(1) program! (Well, I'll have to
  26. check, maybe des(1) is in /usr/local/bin and has been put there by the
  27. sysadmin, who has got one of the zillions free DES implementations,
  28. available on the net...)
  29.  
  30. > authenticate passwords) turns out to be OK, because it cannot be used to 
  31. > encrypt or decrypt information.  I have seen it reported in print that there 
  32.  
  33. Ah, but you should be able to recompile login(1) and how to do that if
  34. crypt(3) is not available?
  35.  
  36. > > Fortunately, the USA is not the only country that has programmers, so 
  37. > > there are plenty of free DES implementations around. I really cannot 
  38. > > understand why RIPEM is not available for anonymous ftp, without the DES 
  39. > > and the RSAREF stuff. Anybody should be able to plug in additional 
  40. > > DES- and RSAREF-compatible modules... 
  41.  
  42. > This possibility is being explored.  Making it available without DES included 
  43. > is not a problem.  Making it available without RSAREF, but still assuming the 
  44. > *use* of RSA in its operation, may not be enough to satisfy RSA's lawyers.  
  45. > However, we shall see how this develops.  I hope that something along these 
  46. > lines can be worked out.
  47.  
  48. Somebody else just explained me in private e-mail that this is even
  49. less likely... It seems that the NSA is -very- reluctant to allow
  50. export of programs that have "hooks" for user-supplied encryption
  51. software... For instance, there is usually no problem to export a
  52. program that provides DES encryption using an arbitrary key, but NOT
  53. ON ARBITRARY DATA! (By "no problem", I mean that you can get the
  54. permission without problems, not that you don't need a pemission...)
  55. In the same time, it is extremely unlikely that you'll be permitted to
  56. export a program that does not perform encryption at all, but has
  57. "hooks" for the user to plug in his/her own implementation of DES or
  58. whatever! On the top of that, there seem to be no written laws or
  59. regulations about this; my correspondents (there were two of them) had
  60. got this feeling by personal experience...
  61.  
  62. As an example, the Kerberos implementation that is allowed to be
  63. exported by DEC has not only the encryption routines removed - it has
  64. even the -calls- to those routines removed! So, you cannot just add
  65. encryption to it...
  66.  
  67. Regards,
  68. Vesselin
  69. -- 
  70. Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
  71. Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
  72. < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
  73. e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
  74.