Cryptography-Digest Digest #539
Cryptography-Digest Digest #539, Volume #12 Sat, 26 Aug 00 01:13:01 EDT
Contents:
Re: The DeCSS ruling and the big shots (Sundial Services)
Re: The DeCSS ruling (Sundial Services)
Re: blowfish problem ("Bruce G. Stewart")
Re: Serious PGP v5 & v6 bug! (Sundial Services)
Writers (Crossbox)
Re: The DeCSS ruling (Bill Unruh)
Re: My encryption algorithm (Rich Wales)
Re: Asymmetric Encryption Algorithms (DJohn37050)
Check this out! ("Big Boy Barry")
Re: Serious PGP v5 & v6 bug! (Ralf Muschall)
Re: On pseudo-random permutation (Benjamin Goldberg)
Re: An interesting cryptographic problem (Benjamin Goldberg)
Re: On pseudo-random permutation ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters (Guy Macon)
Re: Steganography question (Guy Macon)
Re: Asymmetric Encryption Algorithms (Roger Schlafly)
Date: Fri, 25 Aug 2000 18:12:36 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The DeCSS ruling and the big shots
> > rot26 <[EMAIL PROTECTED]> wrote:
> > > I'd just like to know what the general attitude of sci.crypt readers are
> > > towards the DeCSS case... Isn't it about time the "big shots" use their
> > > influence to stop the bullying by the MPAA, educate the public and
> > > perhaps give 2600 their support? (It could be my ignorance and that they
> > > are doing it already... I stand to be corrected.)
The final analysis of the CSS flap may simply be that "you cannot
achieve security through obscurity." It may also be observed that "the
laws of any one country simply cannot prevent the instantaneous flow of
information through the Internet."
Having said all that, perhaps the judge in this case -did- have a
point. The objective of CSS was really to protect intellectual property
against the casual snooper who, "if the door were left completely
unlocked," would steal the customer blind, but who, "if the door is
locked at all," is likely to give up and watch Monday Night Football
instead. The fact that CSS turned out to be a cryptographically
ineffective system might -not- necessarily mean that it has no value to
its creators, or that its creators have no right to any of the
protection they might have (perhaps rightly, perhaps wrongly)
anticipated that they would enjoy by commissioning the creation of this
system.
Flawed it may be, but "human nature is what it is" (and let's be
brutally honest here folks ;-)). Can we honestly say that the backers
of CSS have -no- valid position to take? Does the fact that a lock can
be picked mean that they are not allowed to have -any- lock or object to
the free and wonton distribution of a lock-pick? That is, really, "a
two-sided and therefore tough question." (It doesn't have a
'mathematical' answer.)
--
Date: Fri, 25 Aug 2000 18:16:28 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The DeCSS ruling
Yet Doug's point cannot be dismissed out-of-hand, Joe. The fact that
there are legitimate purposes for reverse-engineering (wretched or non-
existent documentation being one of them) does not entirely invalidate
the point that reverse-engineering is sometimes also done for nefarious
purposes. I tend to feel that the recording industry vastly
over-estimates the number of times people steal copies of movies and
records ... but then again, maybe I'm just "blissfully unaware" of the
number of times my own copyrights are stolen. :-/
>Joseph Reuter wrote:
>
> "Douglas A. Gwyn" wrote:
> > Jim Steuert wrote:
> > > To presume that we are reverse-engineering software for the purpose
> > > of some "illegal" intent "before" we actually reverse-engineer it
> > > is a very serious presumption of guilt.
> >
> > I didn't say that.
> > However, the usual purpose of reverse-engineering is to benefit
> > from somebody else's work without compensating them for it.
>
> I do a lot of reverse-engineering to figure out the undocumented
> (or poorly-documented) interface to something so that I can
> communicate with it.
--
From: "Bruce G. Stewart" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 26 Aug 2000 01:21:48 GMT
Eric Smith wrote:
>
> Chris Torek <[EMAIL PROTECTED]> wrote:
> > The problem basically boils down to several things, some of which
> > are implied by the fact that memcpy() can be implemented in strictly
> > portable C code as:
> >
> > void *memcpy(void *dst0, const void *src0, size_t len) {
> > unsigned char *dst = dst0;
> > const unsigned char *src = src0;
> >
> > while (size--)
> > *dst++ = *src++;
> > return dst0;
> > }
>
> I asked:
> > Is that really true? I know that the void * has to be able to
> > store a value of any other pointer type. But is
Cryptography-Digest Digest #538
Cryptography-Digest Digest #538, Volume #12 Fri, 25 Aug 00 21:13:01 EDT
Contents:
Re: Bytes, octets, chars, and characters (Richard Heathfield)
Re: PROMIS-software for worldwide spy network by US/Isreal (Mike Andrews)
Re: PROMIS-software for worldwide spy network by US/Isreal ([EMAIL PROTECTED])
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Bytes, octets, chars, and characters (Michael Rubenstein)
Re: "Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: "Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: Test on pseudorandom number generator. ("Paul Pires")
Re: Bytes, octets, chars, and characters (Ben Ketcham)
Re: Sending Messages in Morse Code (John Savard)
Re: Bytes, octets, chars, and characters (Mark McIntyre)
Re: Bytes, octets, chars, and characters (Eric Smith)
PRNG Test Theory ([EMAIL PROTECTED])
Best way! ("Big Boy Barry")
Re: An interesting cryptographic problem (Daniel Newby)
Date: Fri, 25 Aug 2000 22:24:42 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
"Douglas A. Gwyn" wrote:
>
> "Bruce G. Stewart" wrote:
> > Hey, c could free up a key word by using "signed signed" instead of
> > "unsigned".
>
> If it weren't for the historical ambiguity about whether plain
> "char" is signed or unsigned, we could dispense with "signed"
> altogether, since it's the default for all other integer types.
Yes, but that would give the EBCDIC people a real headache, since (in
EBCDIC), the alphabet (and digits) have codes > 127 (I'm thinking of the
rule that what we might call 'normal' characters must have a positive
value - I can't find it in the C99 Standard but I'm reasonably sure it's
there). I suppose they could get around that by setting CHAR_BIT to 16,
if they were prepared to make the necessary hardware changes.
Having said that, I have no particular problem with giving the mainframe
guys a hard time, now that I am no longer one of their number. :-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
65 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (32
to go)
--
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Fri, 25 Aug 2000 21:33:33 GMT
Scripsit Mok-Kong Shen <[EMAIL PROTECTED]>:
: 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!'.
It's worse than that! What was a computer that handled Top Secret
data doing connected to _ANY_ sort of external network -- even
the Public Switched Telephone Network? It makes no sense at all.
Systems that handle any sort of classified data need to be
completely isolated from any connection to any insecure network.
That's Rule #1
If the Canadians didn't take that simple precaution, then
for all practical purposes they gave the data away.
--
Prediction is difficult, especially of the future. - (Niels Bohr)
--
From: [EMAIL PROTECTED]
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Fri, 25 Aug 2000 22:17:39 GMT
In article ,
[EMAIL PROTECTED] (Mike Andrews) wrote:
> Scripsit Mok-Kong Shen <[EMAIL PROTECTED]>:
>
> : 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!'.
>
> It's worse than that! What was a computer that handled Top Secret
> data doing connected to _ANY_ sort of external network -- even
> the Public Switched Telephone Network? It makes no sense at all.
>
> Systems that handle any sort of classified data need to be
> completely isolated from any connection to any insecure network.
> That's Rule #1
>
> If the Canadians didn't take that simple precaution, then
> for all practical purposes they gave the data away.
Can we distinguish between stupid government and citizens please?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
Subject: Re: Crypto Coprocessor on Javacard
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 25 Aug 2000 16:33:28 -0600
[EMAIL PROTECTED] don't know of any smart cards that have crypto coprocessors for DES
> >operations, just RSA, so that part of your question is unanswerable.
>
> GemPlus GPK4000 has DES and at least one mode of 3
Cryptography-Digest Digest #537
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
> long64-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
Cryptography-Digest Digest #536
Cryptography-Digest Digest #536, Volume #12 Fri, 25 Aug 00 15:13:00 EDT
Contents:
Test on pseudorandom number generator. ("Cristiano")
Re: SHA-1 program, wrongo ! (Francois Grieu)
Re: Serious PGP v5 & v6 bug! (Mok-Kong Shen)
Re: Looking for link (Mok-Kong Shen)
Re: My unprovability madness. (Pertti Lounesto)
Re: My unprovability madness. (Just Another Deckchair on the Titanic)
PROMIS-software for worldwide spy network by US/Isreal (Eriavierta)
Re: Test on pseudorandom number generator. (Mok-Kong Shen)
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: Test on pseudorandom number generator.
Date: Fri, 25 Aug 2000 20:19:13 +0200
This is a multi-part message in MIME format.
===_NextPart_000_0022_01C00ED1.BC689C60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I'll try to explain (in english !) my problem about pseudorandom number =
generator (PRNG).
I'm looking for a PRNG for seeding a cryptographically secure PRNG. So, =
to test several PRNG, I wrote a program that seems not present in any =
test suite:
1.. utilizing the PRNG to test, my program generate and store =
1,000,000 of different keys each 5 bytes long;
2.. sort the keys;
3.. generate others 100,000,000 keys (5 bytes long) and verify how =
many keys are the same to these generated at step 1.
The program, obviously, verify that a particular sequence of bits is not =
repeated often (my free program in Borland C++ Builder v1.0 is available =
on request).
These are the results:
test n.
Mother
CryptGenRandom
URAND
random
=20
1
92
109
19
161
=20
2
99
94
18
140
=20
3
110
91
29
159
=20
4
96
97
22
154
=20
5
104
89
24
172
=20
6
71
105
19
170
=20
7
93
107
27
166
=20
8
78
92
24
152
=20
9
83
83
24
139
=20
10
94
82
20
165
=20
=20
=20
=20
=20
=20
mean
92,00
94,90
22,60
157,80
=20
standard dev.
11,81
9,54
3,66
11,55
=20
std. dev./mean %
12,84
10,05
16,18
7,32
=20
Explanation:=20
Mother: George Marsaglia's The mother of all random number generators =
producing uniformly distributed pseudo random 32 bit values with period =
about 2^250.
=20
CryptGenRandom: Windows 95/98 CryptoAPI 1.0 (criptographically secure =
software PRNG).
=20
URAND: Porting of a FORTRAN generators producing uniformly distributed =
pseudorandom 32 bit values.
=20
random: standard c library.
For example with Mother, in 100,000,000 keys, 92 keys are the same as =
these generated in the fisrt 1,000,000 keys in the first sequence (n=B0 =
1), 99 keys in the second seuence, and so on.
With my test, the best generator is "URAND" (few repetitions) while the =
worst is "random" (many keys are the same).
Other generators (Mersenne Twister, ranmar, etc.) are about the same as =
Mother (or a little bit better).
The differences in the table above are not detected by any statistical =
test used in my program (FIPS PUB 140-2, Diehard, Maurer's universal =
statistical test and others).
Can anybody say me if my test is right? Why the statistical tests =
doesn't detect these differences?
Tank you very much.
Ciao
Cristiano
===_NextPart_000_0022_01C00ED1.BC689C60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I'll try to=20
explain (in english !) my problem about pseudorandom number =
generator=20
(PRNG).
I'm looking for a PRNG for seeding a=20
cryptographically secure PRNG. So, to test several PRNG, =
I wrote=20
a program that seems not present in any test =
suite:
utilizing=20
the PRNG to test, my program generate and store 1,000,000 of =
different keys each 5 bytes long;
sort the=20
keys;
generate others 100,000,000 keys (5 bytes long)=20
and verify how many keys are the same to these =
generated=20
at step 1.
The=20
program, obviously, verify that a=20
particular sequence of bits is not repeated often =
(my free=20
program in Borland C++ Builder v1.0 is available on =
request).
These are=20
the results:
test n.
Mother
CryptGenRandom
URAND
random
1
92
109
19
161
2
99
94
18
140
3
110
91
29
159
4
96
97
22
154
5
104
89
24
172
Cryptography-Digest Digest #535
Cryptography-Digest Digest #535, Volume #12 Fri, 25 Aug 00 15:13:00 EDT
Contents:
Re: Questions about stream cipher ("Scott Fluhrer")
Re: 1-time pad is not secure... ("Douglas A. Gwyn")
Re: New algorithm for the cipher contest ("Alexis Machado")
Re: My encryption algorithm ("Slava K.")
Secure key exchange over an unsecure network ("Slava K.")
Re: My encryption algorithm (JPeschel)
Looking for link (Ryan Phillips)
Steganography question ("Harris Georgiou")
Re: 1-time pad is not secure... ("Tony T. Warnock")
Re: challange ("Douglas A. Gwyn")
Re: Excerpt of SECRETS AND LIES available on-line (Bruce Schneier)
Re: Excerpt of SECRETS AND LIES available on-line (Bruce Schneier)
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Questions about stream cipher
Date: Fri, 25 Aug 2000 08:51:27 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] (Mark Wooding) wrote:
> > > No, SEAL can't do random seeking.
> >
> > Um yes it can. Why do you think it allows for stretching of 32- bit
> > 'index' variables? That's fairly close to seeking.
>
> No, it's almost completely different. What you can do with a BBS
> generator, if you know the factors, is seeking. SEAL gives you a
> mapping from a key to 2^32 different nonseekable pseudorandom streams.
> That's not the same at all.
To be unutterly pedantic, SEAL also allows you to seek into 2^6 different
locations in each of those 2^32 different pseudorandom streams (which hardly
makes them "nonseekable")
--
poncho
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Date: Fri, 25 Aug 2000 15:14:43 GMT
> < depends only on local interactions.>>
"S. T. L." wrote:
> Shows you what you know. Spooky action at a distance is D-E-A-D, no matter
> what you think. It just looks like it isn't. Hence the term spooky. Duh.
Basically what has happened is that we eventually realized
that no causation is occurring FTL in the EPR setup. The
currently preferred way of describing such things involves
so-called "entanglement", which is, roughly, a description
about how one's knowledge is distributed among components of
a system. The apparent nonlocality is due merely to moving
entangled components some distance apart while preserving
their correlation. The situation is no more indicative of
nonlocal causality than if I were to take a red and a blue
jawbreaker candy, put one in each of two opaque bags, give
one to you, move off some distance and let you open your bag.
That doesn't suddenly cause a color change of the candy in my
bag. The main difference in the quantum case is just that
the initial uncertainty is due to more than an accidental
lack of a priori knowledge, so we interpret observing one
component of the system as "determining" the state of the
other component. It's really no worse than the 2-slit
experiment. More a case of people thinking confusedly
than anything else.
--
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Fri, 25 Aug 2000 13:25:33 -0300
<[EMAIL PROTECTED]> wrote in message
news:8ns07a$4ne$[EMAIL PROTECTED]...
>
> Please download the documentation and source file (19 KB):
> http://www.meubrfree.com.br/~gauss-inf/nimbus/unimbus.cpp
>
Hi,
My web site is failing.
Please download my cipher from
http://www.gold.com.br/~olimpiom/unimbus.cpp
Alexis
--
From: "Slava K." <[EMAIL PROTECTED]>
Subject: Re: My encryption algorithm
Date: Fri, 25 Aug 2000 19:36:55 +0200
The funny part is that I have no idea what a Vinegere cipher is.
<[EMAIL PROTECTED]> wrote in message news:8o5s3u$h59$[EMAIL PROTECTED]...
> In article <8o4ij6$eub$[EMAIL PROTECTED]>,
> "Slava K." <[EMAIL PROTECTED]> wrote:
> > I have designed a new encryption algorithm, and would like comments
> about
> > it's security. The following is a specification of the algorithm in
> general
> > programming terms. Tell me what you think. EMail me your comments
> > ([EMAIL PROTECTED]).
> >
> > · A password of any size is inputted (K). If K is the length of zero
> or one,
> > and error is reported.
> > · A counter N1 is set to the first character of the password. N2 is
> set to
> > the second.
> > · The two password character (Respective to N1 and N2. They may be
> converted
> > to integers or bytes if required by the language) are XORed together
> (X).
> > · A character is read from the input file (P. This can again be
> converted
> > into an integer or a byte if required) and XORed with X.
> > · The result is written to the output file.
> > · If N1 equals the size of K, it is set to 1. Otherwise, N1 equals N1
> + 1.
> > · If N2 equals the size of K, it is set to 1. Otherwise, N2 equals N2
> + 1.
> > · The process is rep
Cryptography-Digest Digest #534
Cryptography-Digest Digest #534, Volume #12 Fri, 25 Aug 00 12:13:00 EDT
Contents:
Navigator and Internet Explorer SSL X.509 Profile (Klaus Schmeh)
Re: My encryption algorithm ([EMAIL PROTECTED])
Re: PGP Bug: IMPORTANT Personal test report (Steven Markowitz)
Re: "Warn when encrypting to keys with an ADK" (Phil Harrison)
Re: "Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: "Warn when encrypting to keys with an ADK" (Ron B.)
Re: Bytes, octets, chars, and characters (Dan Pop)
Re: The DeCSS ruling ("Trevor L. Jackson, III")
Re: PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: Asymmetric Encryption Algorithms ("Paul Montgomery")
Re: My encryption algorithm (jkauffman)
Re: Bytes, octets, chars, and characters (Guy Macon)
Re: need help! (John Myre)
Re: Steganography vs. Security through Obscurity (Guy Macon)
Re: UNIX Passwords ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: Asymmetric Encryption Algorithms ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("Douglas A. Gwyn")
Re: My unprovability madness. ("Douglas A. Gwyn")
Re: Serious PGP v5 & v6 bug! ("Douglas A. Gwyn")
challange ([EMAIL PROTECTED])
Re: UNIX Passwords ("Paul Montgomery")
Re: My encryption algorithm (Mack)
Re: Bytes, octets, chars, and characters ("Scott Fluhrer")
From: Klaus Schmeh <[EMAIL PROTECTED]>
Subject: Navigator and Internet Explorer SSL X.509 Profile
Date: Fri, 25 Aug 2000 15:19:33 +0200
Does anybody have detailed information about the X.509 profile the
Internet Explorer and the Netscape Navigator use for the SSL protocol?
Regards
Klaus
--
From: [EMAIL PROTECTED]
Subject: Re: My encryption algorithm
Date: Fri, 25 Aug 2000 13:25:41 GMT
In article <8o4ij6$eub$[EMAIL PROTECTED]>,
"Slava K." <[EMAIL PROTECTED]> wrote:
> I have designed a new encryption algorithm, and would like comments
about
> it's security. The following is a specification of the algorithm in
general
> programming terms. Tell me what you think. EMail me your comments
> ([EMAIL PROTECTED]).
>
> · A password of any size is inputted (K). If K is the length of zero
or one,
> and error is reported.
> · A counter N1 is set to the first character of the password. N2 is
set to
> the second.
> · The two password character (Respective to N1 and N2. They may be
converted
> to integers or bytes if required by the language) are XORed together
(X).
> · A character is read from the input file (P. This can again be
converted
> into an integer or a byte if required) and XORed with X.
> · The result is written to the output file.
> · If N1 equals the size of K, it is set to 1. Otherwise, N1 equals N1
+ 1.
> · If N2 equals the size of K, it is set to 1. Otherwise, N2 equals N2
+ 1.
> · The process is repeated if there are any characters left to encrypt.
>
Wow a modification of a Vinegere Cipher (I think). Righto.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: [EMAIL PROTECTED] (Steven Markowitz)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP Bug: IMPORTANT Personal test report
Date: 25 Aug 2000 13:36:12 GMT
In article <8o5kqk$mls$[EMAIL PROTECTED]> "Michel Bouissou" <[EMAIL PROTECTED]>
writes:
[ snip ]
>==> IMPORTANT NOTE:
>THIS IS MOST IMPORTANT. Reading carefully Ralf's paper, the ADK public key
>seems NOT to be actually included in public keys that mention mandatory use
>of this ADK. YOU MUST HAVE THE ADK public key as well. Only the ADK's key ID
>is included in the key that holds and ADK, which is not enough to allow
>encryption to the ADK by itself.
If the public key contains only the key id of the ADK, then isn't that a
serious security flaw? My understanding is that it is possible for an
attacker to create a new key having the same key id as an existing key,
although the fingerprints will differ. I have read that this can be done
for RSA keys; I'm not sure about DH/DSS keys. This would allow an
attacker to cause messages to be encrypted to himself, instead of to the
intended ADK, as long as the sender had the attacker's ADK on his
keyring.
This attack would apply even if the recipient's key had not been tampered
with. It seems to me that in order for the ADK mechanism to be secure,
the signed portion of a key would have to include the key id, length, and
key fingerprint of the ADK.
Am I misuderstanding something, or is the current ADK setup inherently
insecure?
Steven Markowitz
--
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the
views of D. E. Shaw & Co., L.P. or any of its affiliates.
--
From: Phil Harrison <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys
Cryptography-Digest Digest #533
Cryptography-Digest Digest #533, Volume #12 Fri, 25 Aug 00 09:13:00 EDT
Contents:
Re: Serious PGP v5 & v6 bug! (Ian Bell)
PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: The DeCSS ruling (Daniel James)
My encryption algorithm ("Slava K.")
Re: PGP Bug: IMPORTANT Personal test report ("Michel Bouissou")
Re: SHA-1 program (cool!) (Mark Wooding)
"Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: How many bits of strength does the ZIP encryption have? (Tim Tyler)
Re: Bytes, octets, chars, and characters (Joona I Palaste)
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: "Warn when encrypting to keys with an ADK" ("Michel Bouissou")
Re: Steganography vs. Security through Obscurity ([EMAIL PROTECTED])
Re: PGP Vulnerability ("Cheri & Mike Jackmin")
UNIX Passwords ("Martin 'SirDystic' Wolters")
From: Ian Bell <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 12:03:00 +0100
In message <[EMAIL PROTECTED]>, Sam Simpson
<[EMAIL PROTECTED]> writes
>Original from Dr R.Anderson, uk-crypto mailing list.
>The effect is that GCHQ can create a tampered version of your PGP
>public key containing a public key whose corresponding private key is
>also known to themselves, and circulate it. People who encrypt
>traffic
>to you will encrypt it to them too.
Is it possible to put a public key within a public key and for it to
work?
I've tried using PGP6.5.3 to encrypt to a key that had an ADK on it. The
result was that PGP raised an error that I didn't have the ADK's public
key on my keyring and proceeded to just encrypt to the real recipient.
The error message told be that I should ask the recipient for the ADK's
public key.
Therefore it would seem that for GCHQ to exploit the bug, they would
have to add an ADK to Joe Bloggs' key and have to lure people into
downloading the GCHQ public key...
...unless of course, they could put the GCHQ public key _within_ Joe
Bloggs' tampered key and have PGP recognize and use it.
--
Ian BellT U R N P I K E
--
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP Bug: IMPORTANT Personal test report
Date: Fri, 25 Aug 2000 13:20:49 +0200
Well folks,
To be able to diagnose the EXACT behaviour of my PGP 6.5.2 Freeware /
Windows, I made some tests myself which will help understanding how PGP
behaves when encrypting to keys with a forged ADK.
My PGP has the following settings:
- Warning when encrypting to key with an ADK set to ON;
- Display of the ADK column in PGPkeys set to ON.
For this, I imported forged test keys gotten from Ralf's website in the
following way:
1) I imported Key-B1, which is "Billy Clean's" key to which a forged ADK was
added
- This key shows up in PGPKeys with the ADK circle being RED, which
immediately identifies this key as containing a forged ADK.
- The properties of the key shows an ADK tab, in which I see the unknown key
(keyID) being an enforced ADK.
==> FIRST CONCLUSION: It is immediately visible in PGPkeys that the key
contains an ADK, although PGP doesn't detect that this ADK is a forged one.
2) From the explorer, I encrypted a text file to "Billy Clean's" key and
mine as well.
- As soon as I select "Billy Clean's" key in the recipient key selection
box, I get a dialog box that states:
"The user Billy Clean has a missing Additional Decryption Key". Contact the
owner of the key to obtain the additional decryption key"
- I click on OK then see only my own key and Billy's one in the selected
recipients field.
- I encrypt and all goes well.
- Now I try to decrypt the file. The dialog box shows the file was encrypted
to BILLY and MYSELF, no visible trace of another decryption key.
- I can decrypt the file.
3) Now I import Key-C into my keyring, which is the public key of the
"forger" of Billy's key -- The ADK's public key.
- The "ADK" tab in Billy's public key properties box now shows that his ADK
is "control" (the newly imported key).
4) From the explorer, I encrypt again a text file to "Billy's" key and mine
as well.
- As soon as I select "Billy's" key in the recipient selection box, BOTH
BILLY'S KEY *AND* CONTROL'S one drop into the selected recipients field.
- IT IS THUS VISIBLE THAT "CONTROL" WILL BE ABLE TO DECRYPT THE MESSAGE
- NO SPECIFIC WARNING DIALOG BOX HAS BEEN ISSUED BY PGP although the "Warn
when encrypting to key with an ADK" option was selected.
==> SECOND CONCLUSION: The warning option doesn't seem to work at all in
this situation, but it is visible that there will be a supplementary
recipient that was not selected by the sender.
- Now I encrypt the file
5) I try to decrypt the file
- The decryption passphrase box shows me that the file is encr
Cryptography-Digest Digest #532
Cryptography-Digest Digest #532, Volume #12 Fri, 25 Aug 00 07:13:01 EDT
Contents:
SSL implementation for client authentication ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters ("G Swaine")
Re: SHA-1 test request (Francois Grieu)
Re: Serious PGP v5 & v6 bug! (David Kennedy CISSP)
Re: Bytes, octets, chars, and characters (Casper H.S. Dik - Network Security
Engineer)
Re: Serious PGP v5 & v6 bug! ("Michel Bouissou")
Re: ADK Bug: Statement from cert.org. (Keith)
senders using the modified certificate have no way to detect the modification
without complicated manual inspection (Keith)
Re: Serious PGP v5 & v6 bug! (Keith)
Re: Serious PGP v5 & v6 bug! (Keith)
Re: blowfish problem (Richard Bos)
Re: The DeCSS ruling - Reverse engineering? (rot26)
Re: Bytes, octets, chars, and characters (AndyC)
From: [EMAIL PROTECTED]
Subject: SSL implementation for client authentication
Date: Fri, 25 Aug 2000 08:11:10 GMT
Hi experts there out,
I am implementing a project in which I have to to a client authenticaton
in a IBM HTTP server.In generl can some one tell me how can I implement
the client authentication or which directives I put in.Please give me
the details and step procedure,and also do I need to generate the key
file database ,since I have read their can be only one instance of the
keyfile Db in the conf file(please clear).if possible I will be very
much obliged if you all can do so.
Thanks
Jagjit
IBM India
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "G Swaine" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 20:19:01 +1200
Reply-To: "G Swaine" <[EMAIL PROTECTED]>
"Paul Schlyter" <[EMAIL PROTECTED]> wrote ...
> John Savard <[EMAIL PROTECTED]> wrote:
> > Another way to consider the word length of a machine would be to see
> > what alignment restrictions apply to instructions. This makes a
> > System/360 a 16-bit machine, and even a Pentium an 8-bit machine;
> > while this is an unambiguous convention, it doesn't say anything
about
> > the power of the machine or the underlying architecture, so it
hasn't
> > been used.
>
> Using that as a criterion for the word length would have some weird
> effects: it would make the 68000 and 68010 16-bit CPU's, while the
> 68020 and later would be 8-bit CPU's..
The '020 required instructions to be on even addresses, AFAICR
--
Due to the amount of junkmail I've received in the past, this message
has bogus From and ReplyTo names and addresses. I can be contacted via
an intermediary : gem at gem win co nz. I would like to apologise to the
genuine respondents that this may inconvenience.
--
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: SHA-1 test request
Date: Fri, 25 Aug 2000 10:33:00 +0200
[EMAIL PROTECTED] (S. T. L.) wrote:
> I'm trying to improve/debug my SHA1.EXE program that I wrote in C,
> and I need to make sure that it treats huge files properly.
> Could someone (..post..) the hash of a 1,000,000,000 byte
> file consisting of the character 'a' ?
Test vestors for SHA1 have been independently cross-verified by
Jim Gillogly and myself on Aug 1998. Our focus was on messages
with bit length not a multiple of 8. The vectors include an example
over 2^32 bits, see my repost:
As of your 10^9 times the byte 0x61, my implementation gives
D0F3E4F2 F31C665A BBD8F518 E848D5CB 80CA78F7
I second other comments that you should read the file once only.
As of computing the file length, I use something in the line of
unsigned long my_lenL, my_lenH, len; /* at least 32 bits */
/* update my_len with len, expressed in bytes */
my_lenL += len; /* update my_lenL */
if (my_lenL>29);
my_W[15] = (my_lenL<<3)|vn;
I believe this is correct on any ANSI C platform: it is guaranteed
"unsigned long" performs arithmetic mod 2^k for some integer k at
least 32.
As of portability, I recommand that you test your C code on a
variety of environements, including big-endian and little-endian,
and with 16 bit ints.
Francois Grieu
--
From: David Kennedy CISSP <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: Fri, 25 Aug 2000 04:43:53 -0400
Reply-To: [EMAIL PROTECTED]
=BEGIN PGP SIGNED MESSAGE=
JL wrote:
>
> > Is it Ralf's opinion that manipulated keys do not reveal the
presence of
> > ADKs?
>
> Not from what I understand from what has been quoted.
>
> > If so, why do keys containing "legal" ADKs differ from manipulated
ones in
> > failing to announce the presence of the second key?
>
> "Legal" ADKs are signed by the key holder, not manipulated ones. But
PGP
> doesn't check whether sthe
Cryptography-Digest Digest #531
Cryptography-Digest Digest #531, Volume #12 Fri, 25 Aug 00 04:13:00 EDT
Contents:
Re: My unprovability madness. (Steven B. Harris)
Re: need help! (Jim Gillogly)
Re: SHA-1 test request ("Ed Suominen")
Re: need help! ("John Utkke")
Re: SHA-1 test request (S. T. L.)
Re: Serious PGP v5 & v6 bug! ("Howard")
Re: need help! ("John A. Malley")
ADK Bug: Statement from cert.org. (Ron B.)
Re: Excerpt of SECRETS AND LIES available on-line (Anthony David)
Re: A few big primes? (Michael Brown)
Re: ADK Bug: Statement from cert.org. (Jeremy Bishop)
Re: 1-time pad is not secure... (S. T. L.)
Re: Serious PGP v5 & v6 bug! (Anders Thulin)
Optimized Freeware. ("Sergio Arrojo")
From: [EMAIL PROTECTED](Steven B. Harris)
Crossposted-To: sci.math,sci.physics
Subject: Re: My unprovability madness.
Date: 25 Aug 2000 04:12:09 GMT
In <8o32h5$9vj$[EMAIL PROTECTED]> Nathan the Great
<[EMAIL PROTECTED]> writes:
>
>In article ,
> "Adam Russell" <[EMAIL PROTECTED]> wrote:
>> No, I wasn't speaking of Godel. I was referring to the
>> suggestion of a system of logic where unprovable statements
>> are deemed to be false.
>
>Adam, WHEN USING CONSTRUCTIVE LOGIC, unprovable
>statements _are_ false, not just deemed to be.
The difference between statements in logic which ARE false, and
statements which are "merely" DEEMED to be false, is nothing but a foot
stomp. For all statements in logic which ARE false, are merely "false"
by definition of your particular construction of "false." How else?
--
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: need help!
Date: Fri, 25 Aug 2000 04:33:52 +
John Utkke wrote:
>
> I am a kid interested in cryptography can someone help me with this
> encryption problem, here is what I am given in this exercise.
>
> W=T, K=O, X=S
> J ISKKXO WK NOBJAO
There's not enough information to find a unique solution unless
you can determine the key structure. It probably starts
I CHOOSE TO, but there are several choices for the last word.
REFINE fits nicely with various choices of short K4-type keys (keyed
plaintext and ciphertext), but many other choices are also possible
and make sense, such as DEFILE, DEFINE, DERIVE, DESIRE, RECITE,
RESIDE and REVISE.
Did anything in the statement of the exercise indicate how the
alphabet was mixed? Did they give you a sample problem?
--
Jim Gillogly
Sterday, 3 Halimath S.R. 2000, 04:22
12.19.7.8.17, 12 Caban 20 Yaxkin, Sixth Lord of Night
--
From: "Ed Suominen" <[EMAIL PROTECTED]>
Subject: Re: SHA-1 test request
Date: Thu, 24 Aug 2000 22:34:44 -0700
=BEGIN PGP SIGNED MESSAGE=
Hash: SHA1
TEST 1 OF 3
- -
Here's my first test of your program against two others. Looks like
your is the odd man out on this *very* big file (my unmounted
PGPdisk). sha1.exe is your program, sha1.com is the assembly
language program written by Robert G. Durnal, and gpg.exe is
the GNU Privacy Guard, which has a neat "print message digest"
switch.
C:\>dir *.pgd
Volume in drive C has no label
Volume Serial Number is 3425-11E5
Directory of C:\
MYDOCS PGD 2,146,441,728 08-24-00 8:25p Mydocs.pgd
1 file(s) 2,146,441,728 bytes
0 dir(s)1,117.04 MB free
C:\>sha1.exe -h mydocs.pgd
SHA1.EXE v0.25b by S.T.L. This program is distributed under the GNU
GPL.
Copyright (C) 2000 S.T.L.
This comes with ABSOLUTELY NO WARRANTY; see the GNU GPL for details.
This is freedom software, and you are welcome to redistribute it
under certain conditions; see the GNU GPL for details.
SHA-1 hexadecimal hash:
E0A0 F640 6D5C 551A 1396 5ADE A987 952B AC54 FA24
C:\>sha1.com mydocs.pgd
649C02D3430B38340DCCB1F305BBC50E85A73A20
C:\>gpg --print-md sha1 mydocs.pgd
gpg: Please note that you don't have secure memory on this system
mydocs.pgd: 649C 02D3 430B 3834 0DCC B1F3 05BB C50E 85A7 3A20
TEST 2 OF 3
- -
Here's a second test on a smaller file, the user's manual for Eudora
4.3 (a PDF file of about 3.5 MB).
C:\>dir *.pdf
Volume in drive C has no label
Volume Serial Number is 3425-11E5
Directory of C:\
TEST PDF 3,650,823 05-25-00 12:22p test.pdf
1 file(s) 3,650,823 bytes
0 dir(s)1,113.52 MB free
C:\>sha1.exe -h test.pdf
SHA1.EXE v0.25b by S.T.L. This program is distributed under the GNU
GPL.
Copyright (C) 2000 S.T.L.
This comes with ABSOLUTELY NO WARRANTY; see the GNU GPL for details.
This is freedom software, and you are welcome to redistribute it
under certain conditions; see the GNU GPL for details.
SHA-1 hexadecimal hash:
DDE8 8A5B 6CF5 F298 BC65 AD1F E3CC 726C A65F 8461
C:\>sha1.com test.pdf
58CEEC6E980C9181BC6D91418B927C968A93A341
C:\>gpg --print-md sha1 test.pdf
gpg: Please note that you don't have secure memory on this system
test.pdf: DDE8 8A5B 6CF5 F298 BC65 AD1F E3CC 726C A65F 8461
