Cryptography-Digest Digest #484, Volume #9 Fri, 30 Apr 99 10:13:03 EDT
Contents:
Re: Predicting calculator pseudo-random numbers (John H Meyers)
KeyNote v2 trust management toolkit now available for beta testing (Matt Blaze)
Re: Commercial PGP for Linux? (Matthew Skala)
Re: Commercial PGP for Linux? (Bernie Cosell)
Encryption specialist wanted ("Kevin Green")
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(wtshaw)
Re: Applied Cryptography || C++ Anotated Archives (Gurripato (x=nospam))
Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO (SCOTT19U.ZIP_GUY)
Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
Re: Prime Numbers Generator (Terje Mathisen)
Re: Applied Cryptography || C++ Anotated Archives ("Anonymous")
Re: Random Number Generator announced by Intel (Daniel James)
Re: Commercial PGP for Linux? (Steven Haslam)
----------------------------------------------------------------------------
From: John H Meyers <[EMAIL PROTECTED]>
Subject: Re: Predicting calculator pseudo-random numbers
Date: Thu, 29 Apr 1999 21:42:16 -0500
Hewlett-Packard, in particular, has always used a decimal LCRNG,
to which the user can supply an initial seed; the current
value/seed remains preserved in a reserved memory location,
even when the calculator is "off," so that the sequence
continues deterministically until re-seeded.
The HP48 uses a multiplicative generator
(15-digit multiplier and internal value/seed, only the
first 12 digits are returned in its floating-point result);
the initial seeding command guarantees a period of 5x10^13;
the "time-randomized" seeding command has a flaw, in that
there are only 2^20 possible starting points, with the
internal timer repeating its low-order 20 bits every few minutes;
this is correctible with a small user program.
Current TI models use a "Lecuyer" generator as described here:
<http://www.ti.com/calc/docs/faq/83faq070.htm>.
None of the above are suitable for "cryptographic" use,
except possibly for generating IVs; however, HP and TI
calculators are capable of being programmed with any
mathematical and cryptographic algorithms which exist,
since they can, with suitable internal programming,
do anything which "full-size" computers
(or less than "full size" smart cards, etc.) are capable of.
===========================================================
With best wishes from: John H Meyers <[EMAIL PROTECTED]>
------------------------------
From: Matt Blaze <[EMAIL PROTECTED]>
Subject: KeyNote v2 trust management toolkit now available for beta testing
Date: Fri, 30 Apr 1999 02:42:20 GMT
We are pleased to announce the beta release of the KeyNote v2 Trust
Management Toolkit and Reference Implementation for BSD Unix and
Linux. The toolkit was developed by Angelos Keromytis of the
University of Pennsylvania.
KeyNote is a small, flexible trust management system designed to be
especially suitable for Internet-style applications. KeyNote provides
a single, uniform language for specifying security policies and
credentials, and can be used as an application policy description
language as well as as a format for public-key credentials. KeyNote
is a joint project of M. Blaze, J. Feigenbaum, J. Ioannidis, and
A. Keromytis.
KeyNote provides a standard, common mechanism for managing security
policy, credentials, access control, and authorization. An
application built with KeyNote simply asks the "compliance checker"
whether potentially dangerous actions should be allowed according to
policy. Policies and credentials are written in a standard language
that is shared across applications; the security configuration
mechanism for one application carries exactly the same syntactic and
semantic structure as that of another, even when the semantics of the
applications themselves are quite different.
The KeyNote language and implementation are virtually without
intellectual property constraints (as far as we know). We have not
patented the KeyNote system or trust management generally (although of
course anyone, including us, could invent and patent some specific
novel application of trust management based on KeyNote). The KeyNote
toolkit is covered under a Berkeley-style open source license and can
be freely incorporated (with attribution) into commercial and
non-commercial software. The software is, of course, distributed
completely without warrantee. Use it, like everything obtained from
the net, completely at your own risk.
This is a Beta release, and we might change the interface, structure,
supported platforms, or other aspects of the system when the final
version is released. The beta release has been tested under BSD Unix
and Linux, but may (or may not) run on other platforms. To build
KeyNote with credential signature verification, you'll need a recent
release of the SSLeay library.
A full description of the KeyNote language can be found in our
Internet Informational RFC (we don't know the number yet), which can
be obtained by anonymous ftp from:
<ftp://ftp.research.att.com/dist/mab/knrfc.txt>
The beta release of the KeyNote toolkit can be downloaded from the
KeyNote web page at:
<http://www.cis.upenn.edu/~angelos/keynote.html>
or by anonymous ftp from:
<ftp://ftp.research.att.com/dist/mab/keynote-2-beta2.tar.gz>
There is a mailing list for KeyNote users and developers. To
subscribe, send an email message to <[EMAIL PROTECTED]>
containing the line:
subscribe keynote-users
-matt
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Crossposted-To: comp.security.unix
Subject: Re: Commercial PGP for Linux?
Date: 29 Apr 1999 20:09:19 -0700
In article <7gae0m$r4c$[EMAIL PROTECTED]>, Chris Adams <[EMAIL PROTECTED]> wrote:
>If you don't need interoperability with PGP 2.6, you can use GNU Privacy
>Guard aka gpg, available at http://www.gnupg.org/. It is not compatible
>with PGP 2.6 because it doesn't use patent encumbered algorithms. It IS
>compatible with PGP 5.
With third-party modules, GPG can decrypt messages encrypted by PGP
2.6.3i. The modules do not enable it to encrypt messages for decryption
by PGP 2.6.3, because of message-format (*not* cipher) issues. This is
not likely to be changed in the official version at any time in the
future. Personally I think that's a shame because it means GPG can't
access the remailer network, but it's not my decision to make.
--
Matthew Skala Ansuz BBS (250) 472-3169 http://www.islandnet.com/~mskala/
GOD HATES SPAM
------------------------------
From: [EMAIL PROTECTED] (Bernie Cosell)
Crossposted-To: comp.security.unix
Subject: Re: Commercial PGP for Linux?
Date: Thu, 29 Apr 1999 23:54:33 GMT
Andrew Kay <[EMAIL PROTECTED]> wrote:
} Bernie Cosell wrote:
} > I am trying to locate PGP for Linux that I can use for a commercial
} > application. The 2.6 sources claim to be for noncommercial/personal use
} > only, so I followed the threads to viacrypt->NetworkAssociates->McAfee
} > but all I can find are Windows and Mac packages. Did I miss something? If
} > not, anyone know where I -can- find a commercial-OK PGP package for Linux?
}
} You can get PGP for UNIX from http://www.pgpi.com.
Alas, the international version appears to be only for personal,
non-commercial use, also. If you follow the pointers around on the pgpi
web page, the 'I need a commercial version' choice points you back at NAI.
But I think I see what my problem with NAI is: that I've become
web-spoiled. I just assumed that if you have a fancy "our products", etc,
web site that there would be purchase/licensing info available via the web
site, and it turns out that whenever you try to chase that path via the NAI
web page you end up at McAfee and the retail win/mac version. It seems
that the catch with NAI is that you have to call them up and talk to a
salesperson if you want their commercial package... Since there's not a
*hint* of how much it costs, I'm almost afraid to call.. :o)
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: "Kevin Green" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,ut.jobs
Subject: Encryption specialist wanted
Date: Fri, 30 Apr 1999 04:38:45 GMT
Sorry if it is wrong place for such ad.
Systems West Computer Resources offer 3+ months contract in American Fork,
Utah, USA for serious encryption specialist.
DES, Fips 140-1, Diffie-Helman
Public/Private key, NT, Unix SPX and Netware
Develop encryption software for network communications
Contact:
Kevin Green
[EMAIL PROTECTED]
801-364-7900
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Fri, 30 Apr 1999 01:30:34 -0600
In article <7gacak$17d$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Also, since it's been lost in the editing, let me point out the
> significance: if you choose one of those six ciphers for each of
> your messages then (assuming I can break FEAL but none of the
> others) I can read about one sixth of your traffic. But in any
> real-world application, I'd expect to gain 95% or so of the
> intelligence value in the traffic for reading one sixth of the
> messages. I don't need to know every soldier's orders to
> figure out your strategy, tactics, and when to expect the
> attack.
>
It's at DAWN....it always is.
--
If you think you are beaten, you are.
If you thing you dare not, you don't.
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Applied Cryptography || C++ Anotated Archives
Date: Fri, 30 Apr 1999 07:43:21 GMT
On Thu, 29 Apr 1999 21:50:25 GMT, Pryde <[EMAIL PROTECTED]> wrote:
>Greetings,
>
>While reading a few messages by various members of this group - I noticed a
>few mentioning the book - Applied Crytography - which I agree is an excellent
>book for beginners, my question is has anyone contacted the author regarding
>the companion disks ??? - Its actually a shame they can only be sold to
>American citizens - though Im sure someone has found a way around that bind.
>
The author can do nothing about it. Due to ITAR restrictions,
the disks cannot leave the US; the book itself can, because it is in
printed form and is therefore protected by the 2nd Amendment.
Your only hope is somebody having exported it and posted
outside the US. I recall a site, but it is in the US. Anybody knows
of a non-US site?
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: Re: BEST ADAPTIVE HUFFMAN COMPRESSION FOR CRYPTO
Date: Fri, 30 Apr 1999 08:18:15 GMT
In article <[EMAIL PROTECTED]>,
mok-kong shen <[EMAIL PROTECTED]> wrote:
> SCOTT19U.ZIP_GUY wrote:
> >
> > No you forgot what we are talking about. This whole thread is
> > about how to do a compression that would be useful as a pre step
> > to encryption. It is my contention that one of the key points
> > is the compression should carry no information that could be of use
> > to the NSA types of people trying to break your encryption. One
> > way to do that is to make sure any file could be the result of a
> > possible compression. Again take any file "A" uncompress it to
> > get a file "B" that file should compress exactly to "A" if it does
> > not then there is an exploitable weakness in the compression method
> > used before the encryption. Your use of a EOF in the Huffman table
> > is such an exploitable hook. Also it wastes space and will result
> > in a longer file. If a longer file is desired the encryption method
> > itself can add the extra random bits.
>
> What do you mean uncompressible to the same file or not? If I am the
> user, could I not use, say, # as a symbol agreed upon with my
> partner to end my last sentence instead of a period? In that case
> your file A contains # as the last symbol and your system should
> on uncompression deliver # if it works correctly. Next examine
> the case where the user does not do that but the system automatically
> adds a # on compression and removes that on uncompression. Does
> that make much difference to security for the two cases? (I assume
> here that the proper text does not contain #. Further, as I suggested
> there will be filling bits after that symbol.)
>
Mr Shen do what you want. But you don't understand the concept
of this thread. You and the other user can have any side agreements
that you want. But you don't understand the concept of compression
that can result in any file. You want to add in encryption and call
it pure compression. WRITE CODE SHOW AN EXAMPLE.
Know to beat a dead horse. Take any file "A" uncompress it get a
file "B". Take this file "B" compress it file "C". Then the method
to compress decompress is suitable for use with encryption if "A" = "C".
That is assuming the method used actually compresses text. Look
at my website. Can you even write C code or not? I am truely
sorry the concept is to difficult for you to understand.
David A. Scott
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 27 Apr 1999 04:11:21 GMT
"R. Knauer" wrote:
> On Mon, 26 Apr 1999 19:04:43 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
> wrote:
> >Surely, to take an
> >extreme example, XORing the plaintext with a key stream
> >that is all 0-bits produces an easily cryptanalyzable
> >ciphertext.
> Yet there is no reason for the cryptanalyst to conclude that it is the
> intended message. If you say that it is highly unlikely that a
> ciphertext would be fully intelligible, you would be correct, but that
> cannot be used as analytic evidence that the cipher text is the same
> as the message.
You keep insisting on absolute proofs, whereas the real world is one
of relative degrees of certainty. To take a concrete example, if I
see on some channel that is known to normally carry well-encrypted
telegraphic Serbo-Croatian, an entire message whose ciphertext reads
as perfectly intelligible Serbo-Croatian plaintext, I can compute the
probability of that occurring by chance for a correctly functioning
encryptor, and for any substantial length (say, 1000 characters), it
would not be expected to occur in a lifetime of my doing nothing but
monitoring such a channel. Of the two possible explanations, that it
was a statistical fluke from a correct encryptor, or that it was
unencrypted or a "bust" from a broken encryptor, which would *you*
choose? I'd sure choose the latter, which experience has shown is
the correct policy.
> There are several other factors here. For one thing, although we use
> the term OTP cipher we really mean a stream cipher that mimics the
> OTP in its essential factors but has stronger mixing algorithms than
> simple XOR. So the example you gave is not relevant.
This is the first mention of any mechanism other than simple XOR
of a random keystream. If your "TRNG" works correctly, there is no
need for anything fancier than a simple XOR. If it is broken, the
loss of security is easier to comprehend by considering how it
affects the simplest reasonable application to encryption.
> You are saying that the suitablilty of a keystream for strong
> crypto is a property of the keystream and not the generator.
No, I said what I said. The reason for testing the output stream
is to *infer* something about the generator.
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: Prime Numbers Generator
Date: Fri, 30 Apr 1999 11:13:34 +0200
D. J. Bernstein wrote:
>
> Peter Gunn <[EMAIL PROTECTED]> wrote:
> > which would mean that you
> > could generate all primes < 2**32 in ~2.5mins on a PII 233...
>
> The primespeed program from http://pobox.com/~djb/primegen.html goes up
> to 2^32 in 42.1 seconds on a Pentium II-350 (gcc 2.8.1 -O1, 3600 words),
> or 53.7 seconds on an UltraSPARC-296 (gcc -O6 -msupersparc, 4004 words).
> That's faster than reading the same data from a typical disk.
Oops!
Reading the previous messages in this thread, I was going to gloat
because my (fairly simple) bitmask program, using a single 128KB buffer,
takes about 4 minutes, but I guess I have to be 6 times faster to even
get back into contention. :-)
Good work, Dan!
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: "Anonymous" <[EMAIL PROTECTED]>
Subject: Re: Applied Cryptography || C++ Anotated Archives
Date: Fri, 30 Apr 1999 08:16:04 -0400
Gurripato (x=nospam) wrote in message <[EMAIL PROTECTED]>...
>On Thu, 29 Apr 1999 21:50:25 GMT, Pryde <[EMAIL PROTECTED]> wrote:
>
>>Greetings,
>>
- deleted -
>>
> The author can do nothing about it. Due to ITAR restrictions,
>the disks cannot leave the US; the book itself can, because it is in
>printed form and is therefore protected by the 2nd Amendment.
>
I'm not an anti-gunner, but,
Don't you mean the 1st Amendment!!!!????
Anon
------------------------------
From: Daniel James <[EMAIL PROTECTED]>
Subject: Re: Random Number Generator announced by Intel
Date: Fri, 30 Apr 1999 12:54:50 +0100
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Mok-Kong Shen wrote:
> > The random
> > number generator is only for use when an operating system is running,
> > according to the documentation.
> Can someone say what 'only for use when an operating system is running'
> means?
>
At a guesss: it means that the instructions that retrieve the random data
can only be used in operating system code, not in application program
code. IOW in ring 0 code.
You'd then need some kind of device driver for the OS of your choice to
provide a user-mode API to access the information.
Not rocket science.
Cheers,
Daniel.
------------------------------
From: Steven Haslam <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: Commercial PGP for Linux?
Date: 30 Apr 1999 12:17:15 +0100
>>>>> "Matthew" == Matthew Skala <[EMAIL PROTECTED]> writes:
Matthew> In article <7gae0m$r4c$[EMAIL PROTECTED]>, Chris Adams
Matthew> <[EMAIL PROTECTED]> wrote:
>> If you don't need interoperability with PGP 2.6, you can use
>> GNU Privacy Guard aka gpg, available at http://www.gnupg.org/.
>> It is not compatible with PGP 2.6 because it doesn't use patent
>> encumbered algorithms. It IS compatible with PGP 5.
Matthew> With third-party modules, GPG can decrypt messages
Matthew> encrypted by PGP 2.6.3i. The modules do not enable it to
Matthew> encrypt messages for decryption by PGP 2.6.3, because of
Matthew> message-format (*not* cipher) issues. This is not likely
Matthew> to be changed in the official version at any time in the
Matthew> future.
I seem to be able to use GnuPG to generate PGP2-compatible messages,
for use with Debian. Although I don't use it for packages, I use it
for email. Hmm.... I briefly reset my mailer to use PGP 2 to verify my
own signatures (generated with GPG) and the output looks plausible.
If anyone wants to see the config I'm using, *mail* me.
SRH
--
Steve Haslam, Validation Engineer, ARM Ltd, Cambridge UK +44-1223-400677
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
** 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
******************************
