Cryptography-Digest Digest #239, Volume #9 Tue, 16 Mar 99 04:13:03 EST
Contents:
Paper on Guillo-Quisquater zero-knowledge algorithm wanted (S.T. Wong)
Public Encryption for real time Network Telephony (Sadewerth)
Re: Public Encryption for real time Network Telephony (Paul Rubin)
Re: Network Associates - Can we trust their products? (Bruce P. Burrell)
REPOST : PGP 5 and emacs crypt.el library (Gildas PERROT)
Re: REPOST : PGP 5 and emacs crypt.el library (Aaron Gross)
Re: Finite Field with Hard Division? (Gregory G Rose)
Re: Secure Hash (shc.c) ([EMAIL PROTECTED])
Secure hash SHC ([EMAIL PROTECTED])
Re: Limitations of testing / filtering hardware RNG's (Mark Currie)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (S.T. Wong)
Subject: Paper on Guillo-Quisquater zero-knowledge algorithm wanted
Date: 16 Mar 1999 04:10:04 GMT
Hello,
I'd like to know if the following paper is available online :
Louis C. Guillou and Jean-Jacques Quisquater.
A practical zero-knowledge protocol fitted to security microprocessor
minimizing both transmission and memory.
In Christoph G. Günther, editor, Advances in Cryptology -- EUROCRYPT 88,
volume 330 of Lecture Notes in Computer Science, pages 123-128.
Springer-Verlag, 25-27 May 1988.
Would anyone please help ?
Thanks in advance.
Regards,
ST Wong
--
S.T. Wong | Email: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Sadewerth)
Subject: Public Encryption for real time Network Telephony
Date: 16 Mar 1999 04:24:49 GMT
Are there any robust algorithms publically available for real time encryption
of streaming media? If they are available, how much compression is required of
the digitized stream? Could it be used with a full 64K channel? Also, what
amount of delay would be induced by the encrpytion process..as this is a
primary concern for network telephony. Would appreciate any help possible.
Also, I am "newbie" to any encrpytion..I am a telephony applications
programmer, so I am not real familiar with terminology, etc.
Thanks
S. DeWerth
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Public Encryption for real time Network Telephony
Date: Tue, 16 Mar 1999 04:49:42 GMT
In article <[EMAIL PROTECTED]>,
Sadewerth <[EMAIL PROTECTED]> wrote:
>Are there any robust algorithms publically available for real time
>encryption of streaming media?
Yes, they are called stream ciphers.
>If they are available, how much
>compression is required of the digitized stream? Could it be used
>with a full 64K channel? Also, what amount of delay would be induced
>by the encrpytion process..as this is a primary concern for network
>telephony.
None. None.
>Would appreciate any help possible. Also, I am "newbie"
>to any encrpytion..I am a telephony applications programmer, so I am
>not real familiar with terminology, etc.
Go to your local bookstore (or amazon.com or wherever) and get a copy
of Applied Cryptography by Bruce Schneier. That is the standard
programmer's introduction to cryptography these days.
If you want to look at an encrypted IP telephony program check out:
http://www.lila.com/nautilus/
although it doesn't use stream ciphers (it uses block ciphers which
create a few msec delay, which is ok the way the program is used).
------------------------------
From: Bruce P. Burrell <[EMAIL PROTECTED]>
Subject: Re: Network Associates - Can we trust their products?
Crossposted-To: alt.comp.virus
Date: Tue, 16 Mar 1999 04:48:35 GMT
In alt.comp.virus [EMAIL PROTECTED] wrote:
> A little long, but take a coffee break and read with me in humor,
> okay? It isn't supposed to be 'dead' serious, but just a point
> I'd like some comments on, especially the validity of their products
> actually working like they should w/o subterfuge.
I'll address it point by point. Goody goody (not).
> ---
> Intro:
> As you may all well know, the licensed version of McAfee virus scanners
> from their password FTP site was known to the Usenet newsgroup readers
> as far back as Jan 1997.
> (www.dejanews.com search:
>
>http://x7.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=213502707.3&CONTEXT=921385556.2014249164&hitnum=17)
> This site has not changed in over three years, nor has the username and
> password, and has been posted numerous times to the Usenet newsgroups
> over this period.
Hell, it's embedded in their HTML code. This is no big secret.
> ---
> Okay, so either NAI, one of the world's largest security and virus
> protection companies in the world has got the _LAMEST_ site masters
> around, or they're 'deliberately' posting this publically on their web
> site today after the prior three years of common knowledge of the URL.
They want folks to try their software, remember? McAfee was a big
player in the Shareware revolution; this is pretty much "business as
usual".
[snip]
> The new .nai. address has also been available in the Usenet newsgroups
> since 8/98 and I'll leave it to you to verify through Dejanews.
> ---
> My Theory: (and maybe one episode too many of X-Files this week..)
> Could it be possible that NAI in conspiring to do the following:
> * Release virus products which require constant *.DAT upgrades as
> an income stream, even though it may be already possible to create
> an AI virus detection engine that will catch unknown ones w/o any
> problems
This isn't so easy -- at least if you want to be able to disinfect,
too: It's easy enough to write a virus that, by changing a mere one *BIT*,
behaves entirely differently. Unless you want the software just to flag
everything as a virus, in which case you won't be using the computer much.
I don't believe in Artificial Intelligence, though I've seen plenty of
natural stupidity.
> (not counting those that appear with new technologies,
> such as Java viruses appearing after the engine was built before
> Java existed).
They already have far too much to keep them occupied -- I'm speaking
about the whole industry (scanner based, anyway). If not, everyone would
get the _VB_100% award, and CheckMark, and ICSA certifications, and all
that.
> * Release licensed versions of their products through their public
> web site to give key IS people a good run through their demo and
> licensed products so that there's a higher chance it'll be the
> first to be recommend.
I'm sure that's true, but this is no conspiracy. After all, IS folks
can request eval copies, and get them, from all vendors.
> Buying the most popular (McAfee) and best (DrSolomons) virus scanners as
> reported by the trade magazines lend to this as well.
Well, I'd sure be tempted to recommend the best stuff available if that
were my mission!
> * Capturing data from us through Personal PGP and/or their virus
> scanners during Internet sessions for their use.
Ummmm.... What exactly are they snagging here?
> * And creating new virii themselves to promote the upgrade
> cycle.
This is a silly, ancient argument.
1. There are too many already, written by the virus authors.
2. If they DID this and ever got caught, they'd be bankrupt overnight.
Stockholders probably would be pretty annoyed about that.
> (After all, Microsoft loves this. What?! Office 97 doesn't
> work? No problem, just upgrade to Office 2000 and those problems
> will be fixed -- of course, not the new ones we introduced..)
> * etc., etc.
While I'm sure the AV industry may, in some way, be glad that viruses
are a problem for some users, there's plenty of food for everyone as it is
right now. And scanners are far from perfect as it is.
> --
> Your advice then?:
> Given the marketplace for virus scanners, there doesn't appear
> to be many others left: Symantec Anitvirus, maybe a Panda or
> Innoculan, but none that seem to pop into my mind as a leader
> of the pack.
Innoculan?? Just what pack are you talking about leading??
> (After all, DrSolomon's came up many times as the
> tested leader for detecting virii in many trade magazines.)
How long have you been reading this newsgroup? Several others might
pop into your mind if you were as old a fogey as I am....
> Are there any _great_ alternatives to NAI's Total Virus Defense?
"Best" is a matter of the needs of the group being considered. But you
certainly have had an egregious omission of F-PROT (F-Secure, in its
"professional" version) and AVP.
> If we assume that they maybe 'tampering' with their virus products
> to give users a 'reason' they need to upgrade,
... for which you've presented no evidence,
> it may well be that they've 'tampered' with Phil's PGP engine as well --
> and thus their PGP Personal products may also be at 'risk'.
... again, which is a WAG.
> (After all,
> they could code in a 'backdoor' into PGP Personal products and
> thus possess a way to decode our messsages.)
Yeah, and maybe the Cigarette Smoking Man is the CEO, too.
> Given this possibility, is there any way to verify whether there
> is or isn't a backdoor into a NAI PGP Personal encoded message?
Dunno -- is the source still available? Probably not. But then,
v.2.6.2 is still available and solid (and what I use, fwiw).
How is this supposed to benefit NAI? Do you think there is a lot of
PGP-encrypted traffic coursing through their IP nodes?
Hmmm. If so, that might explain why their connectivity is so
horrendous sometimes. :-)
> Which of the prior DOS-only versions of PGP written by Phil before
> NAI hooked up to distribute PGP would you consider 'safe', 'secure',
> and as potentially unaltered (ie. no backdoors) as possible for use?
Non-GUI versions are probably most secure (no SWAPFILE worries) and I
like 2.6.2. But I strongly suspect that the NAI version is as secure in
terms of intentional back doors.
> ---
> After all, NAI isn't acting like any real security company when
> it comes to having such 'open' password sites like this, right?
They're not TRYING to act like one, fer cryin;' out loud.
> david =)
> ....maybe too many X-files shows, but think of it like this. China
> is a communist country just like Russia was. Russia had their spies
> in the US feeding ol' Russia more than one US military secret -
> bombs, weapon designs, etc. If China wanted a good way to probe
> US personnel, here's a couple thoughts:
> They're the worlds largest toy supplier and the US's largest source.
> Digital spread spectrum broadcaster in furby's, and other toys.
Never liked 'em anyway. Almost as bad as smurfs.
> World's largest shoe producer. A signal is generated with each
> foot step like the LED running shoes - that signal tracks you, the
> individual, to the very city block you're in -- everywher you go.
Did you enjoy "Enemy of the State"?
> Monitors with DSS broadcasters to transmit screen images out.
> Pinhole cameras hidden behind dark IR receiver plastic windows in
> VCRs, TVs, montiors and more -- all transmittd out of your home....
Gotta have something to keep those 1.2 Billion busy....
-BPB
------------------------------
From: Gildas PERROT <[EMAIL PROTECTED]>
Crossposted-To: comp.emacs.xemacs,comp.emacs,comp.security.pgp
Subject: REPOST : PGP 5 and emacs crypt.el library
Date: 15 Mar 1999 17:11:25 +0100
Hi,
Does anyone have a patch for crypt.el that causes it to
work in XEmacs 20.4 using PGP 5.0 to visit files?
For instance, if I have a file foo.pgp, if I do
find-file or visit it from dired, it should know how to
decrypt it and how to re-encrypt it if I change and
write it back, using the new command line syntax from
PGP 5.0.
Thanks in advance for your help. Gildas.
--
Gildas PERROT, [EMAIL PROTECTED] __o
FranceNet, 28 rue Desaix, 75015 Paris ---_ \<,_
http://www.francenet.fr ---- (_)/ (_)
------------------------------
From: Aaron Gross <[EMAIL PROTECTED]>
Crossposted-To: comp.emacs.xemacs,comp.emacs,comp.security.pgp
Subject: Re: REPOST : PGP 5 and emacs crypt.el library
Date: 16 Mar 1999 08:25:02 +0200
Gildas PERROT <[EMAIL PROTECTED]> writes:
> Hi,
>
> Does anyone have a patch for crypt.el that causes it to
> work in XEmacs 20.4 using PGP 5.0 to visit files?
Here's a patch I made for XEmacs 20.3; I doubt if crypt.el has changed
any in 20.4. You might want to re-consider whether to use crypt.el at
all: it encrypts and decrypts PGP-encoded files by running a pgp
process with the -z option and putting the pass phrase on the command
line! So it's not the most secure thing in the world if you use PGP on
a multi-user machine or one that logs processes.
diff -u -r1.1 -r1.4
--- crypt.el 1998/06/02 13:10:37 1.1
+++ crypt.el 1998/06/02 15:47:03 1.4
@@ -838,7 +838,7 @@
(list 'pgp
crypt-encryption-magic-regexp crypt-encryption-magic-regexp-inverse
(or crypt-encryption-file-extension "\\(\\.pgp\\)$")
- "pgp" "pgp"
+ "pgpe" "pgpv"
'("+batchmode" "+verbose=0" "-c" "-f" "-z")
'("+batchmode" "+verbose=0" "-f" "-z")
"PGP"
@@ -1013,6 +1013,13 @@
(put 'crypt-dos-has-ctrl-z 'permanent-local t) ; for v19 Emacs
(put 'crypt-dos-has-ctrl-z 'preserved t) ; for kill-fix.el
+(defcustom crypt-pgp-stderr-file nil
+ "*Name of the file where PGP stderr is put. If nil, then stderr is
+discarded. Because PGP 5.0 writes all kinds of non-error messages to
+stderr, you can't just put stderr in the same buffer as stdout like it
+was done before."
+ :group 'crypt)
+
(defun crypt-build-encoding-alist ()
;; Returns the encoding alist
(list
@@ -1803,16 +1810,16 @@
;; nil or "" args - don't pass.
((or (not args) (equal "" args))
- (call-process-region start end prog t t nil key))
+ (call-process-region start end prog t (list t crypt-pgp-stderr-file) nil key))
;; Check if the args are in the form of a list - must use apply.
((listp args)
(apply 'call-process-region
- (append (list start end prog t t nil) args (list key))))
+ (append (list start end prog t (list t crypt-pgp-stderr-file) nil) args
+(list key))))
;; Default - just a non-null string.
(t
- (call-process-region start end prog t t nil args key))))))
+ (call-process-region start end prog t (list t crypt-pgp-stderr-file) nil args
+key))))))
(defun crypt-encrypt-buffer (key &optional decrypt buffer)
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: Finite Field with Hard Division?
Date: 15 Mar 1999 23:06:09 -0800
In article <[EMAIL PROTECTED]>,
Guenther Brunthaler <[EMAIL PROTECTED]> wrote:
>On Thu, 11 Mar 1999 04:31:02 GMT, [EMAIL PROTECTED] (Peter L.
>Montgomery) wrote:
>
>> If the field has q elements, then x^q = x for all x in the field.
>>The inverse of any nonzero x is x^(q-2). You can get this with
>>O(log(q)) multiplications, regardless of the method used to
>>encode field elements.
>
>Am I doing something wrong? This statement only seems to be true ONLY
>for field sizes 1, 2, 3, 5, 7 and 11. (But to be honest, I just tested
>all field sizes up to about 30)
The operative word here is "field". Fields have
sizes which are prime (for modular arithmetic) or
prime powers (extension fields where the
arithmetic is not straightforward modular
arithmetic). Your test should have worked for 13,
17, 19, 23, 29. It would definitely not have
worked for any other values, because not all
elements have (modular arithmetic) multiplicative
inverses for any other size field. If an element
is relatively prime to the modulus, the formula
should give its inverse. If it has a common factor
with the modulus, it won't have an inverse, so of
course the formula won't work.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Secure Hash (shc.c)
Date: Mon, 15 Mar 1999 23:50:35 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Jim Gillogly wrote:
> > 66481 0.0040 80
> > 66538 0.0040 05
> > 66539 0.0040 02
> > 66601 0.0040 20
> > 66615 0.0040 01
> > 66740 0.0040 40
> > 66864 0.0040 10
> > 67048 0.0040 08
> > 67069 0.0040 04
> > 71501 0.0043 00
>
> I re-did this test using random 4-byte inputs rather than sequential
> ones, and got the same effect. Looks like something in your hash is
> eating bits, predisposing the outputs to be 0 bits with some probability.
I think that could be my XOR values. Since only A/B are changed the rotation
has the possibility of canceling values out. What if I left the A/B
permutation to the same (as in SHC.C) and replaced XOR with some other
operation. Possibly replacing the entire third term (XOR A, etc...) with
another.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Secure hash SHC
Date: Tue, 16 Mar 1999 00:33:48 GMT
I noticed something interesting. My algorithm is more 'random' if you don't
pad the message. When padding I find that the symbol 00 is about 0.001% more
apparent then others. Which is obviously not so good. But when I performed
the same test without padding, I got the average for the same symbol. Same
goes for using larger registers.
I will study my algorithm further, and post what I find about it. Remember
that my goal is a quick and secure hash.
Thanks for your time and patience, and if you have any comments please post.
I apologize for posting a lot. but when I start something like this I get
into it!
Some of my other sources can be found at:
http://members.tripod.com/~tomstdenis/rc4.c
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
http://members.tripod.com/~tomstdenis/rc4e.c
http://members.tripod.com/~tomstdenis/shc1.c
Noticed I renamed SHC.C to SHC1.C. I did this so no confusion occurs with any
future work.
Again thanks to those who looked at it, and any in the future.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Mark Currie)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: 16 Mar 1999 08:20:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
>The problem is that any good system may malfunction, e.g. due to
>hardware problems. That's why, I suppose, you want to have diagnostic
>warnings. If you obtain your dignostic warnings, my question was what
>would you precisely do, i.e. stop using the generator for the moment
>and investigate to see if there are troubles (which may take much
>time and hence halts the application) or ignore the warnings and use
>the sequence nevertheless. You didn't seem to have focused your
>answer to that. And a more fundamental question is how can you
>ensure that there are indeed no troubles and prove that the
>warnings are merely false alarms.
>
Here is one way of doing it:
Once you have decided on the real time tests to be applied, if a rejection
occurs, keep discarding the RNG stream until it passes the tests. Normal
operation need not be affected. By using a set of statistical counters, one can
set up thresholds after which the RNG is deemed faulty. i.e. if more than X
rejections occur within Y time frame, halt usage and report failure of RNG.
Multiple threshold levels can be used. i.e. number of rejections per
second, per minute, per day, etc.
We both agree on the need detect failures. The real difficulty is in deciding
on the types of real time tests to be used and what impact they have on the
entropy if we discard rejected values. In my original posting, this was the
area that I was hoping to get feedback on.
Mark Currie
------------------------------
** 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
******************************
