Cryptography-Digest Digest #537, Volume #12 Fri, 25 Aug 00 17:13:01 EDT
Contents:
Re: Bytes, octets, chars, and characters (Steve Summit)
Re: Bytes, octets, chars, and characters (Steve Summit)
Re: "Warn when encrypting to keys with an ADK" (commodore at gci-net dot com)
Re: "Warn when encrypting to keys with an ADK" (commodore at gci-net dot com)
Re: 1-time pad is not secure... ("Douglas A. Gwyn")
Re: SHA-1 program, wrongo ! (S. T. L.)
Re: SHA-1 program (cool!) (S. T. L.)
Re: My unprovability madness. ("Bob May")
Re: Steganography question (zapzing)
Re: Test on pseudorandom number generator. ("Douglas A. Gwyn")
Offical word from PRZ on ADK issue ("Kurt Mueller")
Re: DES: Say it or spell it? (Newbie question) (Jim Reeds)
Re: SHA-1 program (cool!) (S. T. L.)
Re: Bytes, octets, chars, and characters (Kevin D. Quitt)
Re: My unprovability madness. ("Douglas A. Gwyn")
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: Questions about stream cipher ([EMAIL PROTECTED])
Re: PROMIS-software for worldwide spy network by US/Isreal (Mok-Kong Shen)
Re: UNIX Passwords (Eric Lee Green)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Steve Summit)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 19:11:07 GMT
In article <8o5c1t$1jk$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
> The most common 64 bit solution appears to be:
> char 8-bit
> short 16-bit
> int 32-bit
> long 64-bit
And a dandy solution it is, too. Four different types,
four different sizes. Just the way it should be.
Steve Summit
[EMAIL PROTECTED]
--
Programming Challenge #6: Don't just fix the bug.
See http://www.eskimo.com/~scs/challenge/.
------------------------------
From: [EMAIL PROTECTED] (Steve Summit)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 19:18:31 GMT
Benjamin Goldberg evidently wrote:
> It's too bad that integers weren't initially called int8, int16, etc...
No, it isn't.
Steve Summit
[EMAIL PROTECTED]
--
Programming Challenge #6: Don't just fix the bug.
See http://www.eskimo.com/~scs/challenge/.
------------------------------
From: commodore at gci-net dot com
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 19:27:43 GMT
Reply-To: commodore at gci-net dot com
In <8o5n05$kiv$[EMAIL PROTECTED]> S.R. Heller wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
> What the option means is, "If I encrypt to a public
> key with an ARR, and then try to remove the ADK from the recipient's
> list [i.e., from the lower pane in the select recipients dialog],
> warn me that this might be 'violating the policy' established for the
> key with the ARR." That's a mouthful, but you can test it yourself to
> see what I mean.
Is there a function in the PGP SDK to detect and return the value of
an ARR on a key?
I couldn't seem to locate anything appropriate in the doc set.
Thanks.
------------------------------
From: commodore at gci-net dot com
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 19:45:21 GMT
Reply-To: commodore at gci-net dot com
In <[EMAIL PROTECTED]> commodore at gci-net dot com wrote:
>In <8o5n05$kiv$[EMAIL PROTECTED]> S.R. Heller wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>> What the option means is, "If I encrypt to a public
>> key with an ARR, and then try to remove the ADK from the recipient's
>> list [i.e., from the lower pane in the select recipients dialog],
>> warn me that this might be 'violating the policy' established for the
>> key with the ARR." That's a mouthful, but you can test it yourself to
>> see what I mean.
>
>Is there a function in the PGP SDK to detect and return the value of
>an ARR on a key?
>
>I couldn't seem to locate anything appropriate in the doc set.
>
>Thanks.
Following up to my own post, a more careful examination of the docs
show a function named PGPCountAdditionalRecipientRequests() that
seems to do what I want.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 25 Aug 2000 18:52:33 GMT
"Tony T. Warnock" wrote:
> It's more like using a colorless jawbreakers, opening one bag, if it's red, the
> other is blue, if the first one is blue, the other is red. The experiment may be
> repeated, half the time one gets red-blue, the other half blue-red.
Well, one doesn't know what color until the observation is made,
but it's always red or blue when observed, so "colorless" isn't
quite right.
The statistical nature of the outcomes has the analogue that
one purchased a mixed bag of red & blue candy packages as pairs
(always one red with one blue), and without peeking set up the
two bags from a single packaged pair.
Note that in the quantum case there can be noncommuting
observables, so to stretch the analogy, weighing the candy
might "randomize" its previously known color state, so the
next time you look it might have a different color.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: SHA-1 program, wrongo !
Date: 25 Aug 2000 19:49:02 GMT
<< bit length not a multiple of 8.>>
As of now, my implementation works only on byte-oriented data and I'm not
particularly interested on making it work on bit-oriented data. At the very
least, the user would have to tell SHA1.EXE how many bits to ignore so that
non-multiples of 8 bits could be passed. Ugly.
<< The vectors include an example
over 2^32 bits, see my repost:
<http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=544748495&fmt=text>
As of your 10^9 times the byte 0x61, my implementation gives
D0F3E4F2 F31C665A BBD8F518 E848D5CB 80CA78F7>>
Okay. My program as of v0.26 agrees hexit-for-hexit with that, as does a
minimal-complexity verification thing I did
(http://members.aol.com/stl137/private/versha.zip).
<<I second other comments that you should read the file once only.>>
Well, this is basically not easy. I can't get the file length any other way.
Although... I could switch to a method that determines the file length as soon
as EOF is reached... hrm. Sounds interesting. I'll try that.
<<As of portability, I recommand that you test your C code on a
variety of environements, including big-endian and little-endian,>>
My code suffers from no endian problems. It always reads files in big-endian
format and writes them in big-endian (file length and all that) as required by
the SHA-1 spec. I don't see how any SHA-1 program *could* have endian
problems. (Well, I do write SHA-1 hashes to binary files big-endian, but
that's a "proprietary" format that I don't expect any other program to read.)
<<and with 16 bit ints.>>
I use ints extremely sparingly in my program and never assumed that they were
32-bit (I didn't know that DJGPP actually made them 32 bit until I looked it
up). I only use ints for little counters that could have been done with chars,
for everything else I use unsigned long ints, except for file length which I
use unsigned long long ints for. :-D
<<#define MASK32 0xFFFFFFFFUL
h[0] = (h[0] + a) % MASK32;
Can you spot the error ?
Hint: on 32 bit machines the result is correct 99.99999997% of the time.
Spoiler:
% performs modulo, which result is always at least one less than the modulus.
& does a bitwise and, which is what is meant here.>>
Hmmm. True. I was performing addition modulo 2^32 - 1, when SHA-1 requires
addition modulo 2^32. Why hasn't this produced an error before? Ack! Oh... I
see. On a 32-bit machine (DJGPP's unsigned long ints are 32-bit), h[0] + a is
automatically done mod 2^32 as the C standard requires, and only then does the
mod 2^32 - 1 stuff come into play. Hmmm. My code would have been correct
without the MASK32, at least for DJGPP. [Expletives deleted] Thanks for
noticing this; it had escaped my attention!
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: SHA-1 program (cool!)
Date: 25 Aug 2000 19:52:23 GMT
<<I'm certain that unsigned long long is *not* C89 standard. It might be C99
standard, but I know nothing about C99 yet. I don't know if DJGPP supports
long longs.>>
<<C89 doesn't support `long long'.>>
That's, um, what I said. With stars attached.
<<C99 does; there's an off-topic rant about the way it's been added. DJGPP
will support `long long', because it's derived from GCC and GCC's supported it
for ages.>>
Good!
<<OK, that was easy. I've tried three implementations (OpenSSL, Perl
Digest::SHA1, and Catacomb's hashsum). All agree that the SHA1 hash of 10^9
`a' characters is d0f3e4f2f31c665abbd8f518e848d5cb80ca78f7.>>
Okay. That's what my program says. (Although I just learned that it's buggy
in other ways).
<<Just to really test things out, I've also tested 8 x 10^9 `a' characters
(which is well over 2^{32} *bytes*). My implementation (Catacomb
hashsum), and the Perl one (by Peter Gutmann) agree that the right
answer is 6295dd8c1d5b704c85a361033eb5e7d9d6f1dc71; however, OpenSSL
gets 8d42fe8154924bc142d3f0ec75bac769ebb71113 instead for some reason.>>
Problem could be storing stuff in 32-bit integers. It's been my bane as well.
<<DJGPP supports unsigned long long>>
<<Oooh, good. Cool. I'll probably be using that now.>>
<<Not what I'd have recommended, but I can't really object...>>
Well, now that I know that unsigned long long is C99 standard, I'll begin using
it with impunity. :-P
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: "Bob May" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: Fri, 25 Aug 2000 12:57:42 -0700
Will all concerned please remove SCI.OPTICS from the newsgroup list as
this thread is unrelated to the design and production of optics
systems. We don't discuss theory of how light works here in the
SCI.OPTICS newsgroup as this is a practical engineering method
oriented group.
--
Bob May
Access1 has gone Chapter 7 so I don't know how long my website is
going to last.
Bob May
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Steganography question
Date: Fri, 25 Aug 2000 20:03:25 GMT
In article <8o69d3$7nm$[EMAIL PROTECTED]>,
"Harris Georgiou" <[EMAIL PROTECTED]> wrote:
> Looking at some references to steganography methods, I couldn't help
> thinking: even if someone knows that a message is hidden within large
> "random" block, can it be retrieved if the excact steganographic
algorithm
> is not known?
(snip)
First of all I would like to say, personally, that
I think it would be very very silly to rely on
steganography alone to hide a message. It
should always be encrypted first. Always.
And, if your message is encrypted it will be
indistinguishable from random numbers. So
hiding random numbers in random numbers should
not be all that difficult.
An interesting case is when the random numbers you
are trying to hide your message in have some
other distribution, such as Gaussian for example.
Then you would have to come up with some transform
that takes unif. distributed random numbers into
Gaussian distributed random numbers, and that does
not lose information. I don't know of an algorithm
to do that but I would be interested in one.
--
"Sarcasm: the last refuge of modest and
chaste-souled people when the privacy of
their soul is coarsely and intrusively invaded."
--Dostoyevsky--
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Test on pseudorandom number generator.
Date: Fri, 25 Aug 2000 19:31:40 GMT
Please do not post HTML.
Let's do a quick "back of the envelope" calculation.
There are 2^(5*8) possible 5-byte keys (assuming 8 bits/byte).
There are 10^6 keys in your Step-1 reference set.
Each test collects 10^8 samples; for each of the samples,
there is a 2^-40 chance that a given reference key will
match it. So the expected number of matches is
approximately 10^8*10^6*2^-40, which is about 91.
The expected variance is roughly the square root of
that (rule of thumb for rare [Poisson] events): 9.5.
Far from being the "best" generator, "URAND" is horrible!
It has an excessively low number of coincidences, i.e.
it is "flatter than random". There are standard ways
to judge the agreement between the tests and the
hypothesis of uniform-random-generator (a t-test is
probably simplest in your case), but one can tell
just by looking that your reported results for "Mother"
and "CryptGenRandom" are in good agreement with the
results predicted by the model, while "URAND" and
"random" disagree significantly with the expected
results.
I don't know why other tests such as Diehard did not
detect the poor performance of URAND and random.
------------------------------
From: "Kurt Mueller" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Offical word from PRZ on ADK issue
Date: Fri, 25 Aug 2000 15:46:23 -0400
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
We at NAI/PGP Security regret this important bug in the ADK feature
that has been described on various Internet postings today (Thursday
24 Aug). We were made aware of this bug in PGP early this morning.
We are responding as fast as we can, and expect to have new 6.5.x
releases out to fix this bug late Thursday evening. The MIT web
site should have a new PGP 6.5.x freeware release early Friday, and
the NAI/PGP web site should have patches out for the commercial
releases at about the same time. As of this afternoon (Thursday),
the PGP key server at PGP already filters out keys with the bogus
ADK packets. We expect to have fixes available for the other key
servers that run our software by tomorrow. We have also alerted
the other vendors that make PGP key server software to the problem,
and expect Highware/Veridis in Belgium to have their key servers
filtering keys the same way by Friday.
The fixes that we are releasing for the PGP client software
filters out the offending ADK packets. We already warn the users
whenever they are about to use an ADK, even in the normal case.
We will have new information as soon as it becomes available at
http://www.pgp.com.
Philip Zimmermann
[EMAIL PROTECTED]
19:00 PDT Thursday 24 Aug 2000
=====BEGIN PGP SIGNATURE=====
Version: PGP 7.0 (Build 200 Beta)
iQA/AwUBOaXThGPLaR3669X8EQKfGACfagps8ZHCba21eOjoxRUb07Z59dkAoKRg
vaKciU0kcW1l1i+eBS18aQNU
=zoga
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Fri, 25 Aug 2000 20:28:18 GMT
This past week I was at Crypto 2000 in Santa Barbara, gorging
myself on shrimp and on chocolate coated strawberries night
after night. One of the invited talks was by Don Coppersmith,
of IBM Research, one of the members of the DES design team.
I asked him if one should say "D-E-S" or "Dezz". (In his
lecture he said D-E-S about 10 times as often as he
said Dezz.) (Of course IBM began working on the algorithm
before the NBS announced a DES competition, so IBM must have
had some internal name for the project before the term DES
existed, such as Lucifer-2 or Project Kumquat or somesuch,
but Don has forgotten what it was.)
Don said he thought that "Dezz" was the way they said it at
Kingston, and "D-E-S" was the Yorktown Heights way of saying
it. Don was with the theoreticians at YH; the implementers
seem to have been at the Kingston branch.
So its not old-timers vs. newbies so much as mathematicians
vs. engineers. I have a lot of respect for engineers, some
of my best friends are engineers, when young I wanted to
be one, but I'll say D-E-S now & forever!!!
--
Jim Reeds, AT&T Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 25 Aug 2000 20:39:09 GMT
Subject: Re: SHA-1 program (cool!)
I think that I fixed that MASK32 problem. For the file consisting of:
0x60 0x4B 0x67 0x4C, my new SHA1.EXE (v0.28b) reports:
6C896B14 21D9FE67 9CBC0073 A7CCDBAB 7EF9F1D4
Which is different than what v0.27b reports. The new version is already on my
web site. Does v0.28b's result agree with other programs now? (I
hand-constructed that file to produce foolishness with the MASK32.)
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: Kevin D. Quitt <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 13:43:37 -0700
Reply-To: [EMAIL PROTECTED]
On Thu, 24 Aug 2000 23:24:39 GMT, mike burrell <[EMAIL PROTECTED]> wrote:
>short short? wtf is a short short? get it out of there whatever it is.
The Purple People Eater likes short shorts.
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91351-4454 96.37% of all statistics are made up
Per the FCA, this email address may not be added to any commercial mail list
------------------------------
Crossposted-To: sci.math,sci.physics
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: My unprovability madness.
Date: Fri, 25 Aug 2000 19:46:12 GMT
Pertti Lounesto wrote:
> "Douglas A. Gwyn" wrote:
> > Presumably he meant that for any given well-formed statement,
> > either it or its negation, but never both, can be proven.
> > That provides an unambiguous classification into "true",
> > "false", and "not well-formed".
> On the contrary. Advanced statements at the forefront of
> research are under debate. As such they are both false and
> true, simultaneously, in the minds of well-informed experts.
> In the page http://www.hit.fi/~lounesto/counterexamples.htm,
> I falsify theorems by counterexamples, which satisfy all the
> assumptions of the theorems, without the conclusions being
> valid. Those theorems are at a transition from true to false.
I looked at your Web page, and it merely concerns the fact
that mathematicians can make mistakes. The issues we were
discussing previously in the thread pertained to whether
*in-principle* unprovable statements can be constructed,
i.e. Goedel's incompleteness theorem. This can be cast as
a matter of computability by an automaton, not involving
error-prone humans.
The pro-Goedel crowd would maintain that a formal system
that does not have unprovable theorems is inadequate for
general mathematical purposes, because it has to be less
powerful than number theory (for example).
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Sat, 26 Aug 2000 02:57:45 -0600
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> "Tony T. Warnock" wrote:
> > It's more like using a colorless jawbreakers, opening one bag, if it's red, the
> > other is blue, if the first one is blue, the other is red. The experiment may be
> > repeated, half the time one gets red-blue, the other half blue-red.
>
> Well, one doesn't know what color until the observation is made,
> but it's always red or blue when observed, so "colorless" isn't
> quite right.
>
> The statistical nature of the outcomes has the analogue that
> one purchased a mixed bag of red & blue candy packages as pairs
> (always one red with one blue), and without peeking set up the
> two bags from a single packaged pair.
>
> Note that in the quantum case there can be noncommuting
> observables, so to stretch the analogy, weighing the candy
> might "randomize" its previously known color state, so the
> next time you look it might have a different color.
It's the last paragraph that's interesting: the lack of marginals.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Questions about stream cipher
Date: Fri, 25 Aug 2000 20:51:57 GMT
In article <[EMAIL PROTECTED]>,
"Miki Watts" <[EMAIL PROTECTED]> wrote:
> Hi!
> I've got a few questions about stream ciphers:
> 1. Are they faster (in general) than block ciphers?
Yes.
> 2. Where can i find a list of (more or less) secure stream ciphers?
At http://www.tml.hut.fi/~helger/crypto/link/stream/
>
> TIA
> Miki Watts
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Fri, 25 Aug 2000 23:12:12 +0200
Eriavierta wrote:
>
> Here is the link from Reuters:
>
> http://news.excite.com/news/r/000825/11/canada-spying
If a security/intelligence agency is not careful enough
to examine whether the software used is safe, then, if
unfavourable things happen, these are well 'deserved'.
See also my follow-ups in the thread 'Serious PGP v5 &
v6 bug!'.
M. K. Shen
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: UNIX Passwords
Date: Fri, 25 Aug 2000 14:05:08 -0700
Martin 'SirDystic' Wolters wrote:
> Is there a description available,
> how UNIX encrypts (or hashes) its
> Passwords?
The Unix V7 manual had a paper in it (by DMR?) describing how V7 encrypted its
passwords (the classic "public hash Unix password" scheme). This is online at
http://plan9.bell-labs.com/7thEdMan/index.html .
Do note that this scheme is obsolete and easily crackable, and most Unix
systems no longer use this exact scheme anymore. Most of the 'Open Source'
Unixes have moved to MD5 or Twofish, as well as incorporating an additional
'/etc/shadow' file. Most modern Unixes have moved to not having a password
file at all but, rather, rely upon Kerberos, LDAP, or some other external
source for their authentication. The PAM (Pluggable Authentication Module)
scheme supports this on Solaris, Linux, and possibly other Unixes, and there
are a number of PAM modules to support storing passwords in a number of wild
and wacky formats, in all manner of data repositories ranging from classic
/etc/passwd to SQL databases.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
** 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
******************************
