Cryptography-Digest Digest #595, Volume #9 Tue, 25 May 99 22:13:03 EDT
Contents:
Re: AES tweaks (David A Molnar)
Re: PGP Implementation of DH/DSS vs. RSA. (David A Molnar)
Review of Scottu19 ([EMAIL PROTECTED])
Re: Oriental Language Based Enryption ("Markku J. Saarelainen")
Re: PGP Implementation of DH/DSS vs. RSA. ([EMAIL PROTECTED])
Re: Oriental Language Based Enryption ([EMAIL PROTECTED])
Re: Oriental Language Based Enryption (JUzarek)
Re: AES tweaks ([EMAIL PROTECTED])
TEA Implementation and Bit Manipulation (Greg Harabedian)
Re: AES tweaks (SCOTT19U.ZIP_GUY)
Stream Cipher using LFSRs ([EMAIL PROTECTED])
Re: Review of Scottu19 (SCOTT19U.ZIP_GUY)
Re: TEA Implementation and Bit Manipulation ([EMAIL PROTECTED])
Re: Why would a hacker reveal that he has broken a code? (Terry Ritter)
Re: AES tweaks (SCOTT19U.ZIP_GUY)
Re: PGP Implementation of DH/DSS vs. RSA. ([EMAIL PROTECTED])
format of Netscape signed.db file? (Paul Rubin)
----------------------------------------------------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: AES tweaks
Date: 25 May 1999 23:46:06 GMT
[EMAIL PROTECTED] wrote:
> David A Molnar <[EMAIL PROTECTED]> writes:
>>In any case, it is probably a good thing to have this much attention
>>paid to block ciphers...and even if they are all breakable by some
>>secret NSA attack, past results tell us that this will be
>>discovered about 25 years from now. Just in time to get my kids
>>(should I have any) interested in cryptography.
> Actually, if you look at the NSA record with particular regards to DES and
> SHA1 they seem to be pretty honest and academic crypto doesn't seem to lag
> them by too much.
I was thinking specifically of differential cryptanalysis, which
was developed by Biham and Shamir in 1991 or so, and developed by
the NSA...well, who knows. but early 70s. You are quite right in
noting that academic cryptologists caught on to the reason for
SHA-0 to SHA-1 fairly quickly, though.
Well, two years is "fairly quickly."
-David Molnar
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: PGP Implementation of DH/DSS vs. RSA.
Date: 25 May 1999 23:53:35 GMT
Guenther Brunthaler <[EMAIL PROTECTED]> wrote:
>>I think that I may know where your brother's argument comes from. I have
>>heard others argue that the algorithms for DH/DSS are too new to be trusted
>>as opposed to RSA.
> While I'm far from being convinced that DH is better or worse than
> RSA, I'm pretty sure that RSA is the newer algorithm: RSA is still
> covered by a patent, while the patent on DH has already expired.
Minor nitpick - the algorithm referred to as "DSS/DH" for public key
exchange is supposd to be a variant of ElGamal. While the original
Diffie Hellman key exchange dates back to the 1976 paper, ElGamal
wasn't published until 1986. In any case, the assumption which
ElGamal is based on, namely that it's hard to get a or b from g^ab,
has been studied about as intensively as RSA.
(does anyone know if the Diffie-Hellman assumption has been
tightly related to discrete logs yet? last I saw was a proof
of equivalence IF you assumed something about elliptic curves
and "extra information." )
but as you point out, the real question is the implementation.
Which I will look at when I get time this summer, I guess.
Also, I thought CAST was from Northern Telecom. That's about all
I know about it, though.
-David
------------------------------
From: [EMAIL PROTECTED]
Subject: Review of Scottu19
Date: Wed, 26 May 1999 00:14:53 GMT
This is my first view of the code so bear with me.
The ScottU (19/16) algorithm is an stream cipher which works in CBC
mode on a n-bit vector in each cycle. A large OTP style key is used
which somehow (???) is generated for each message which is encrypted.
The algorithm apparently encodes the file in a forward CBC and
backwards CBC mode.
The code is a complete utter mess, however some details have been
extracted. The apparent mixing operation is addition (mod 2^n) and
subtraction.
Some questions:
1. What is the random data used?
2. What is the actual mixing mode? (CBC?)
3. What is the actual key? How much entropy per key?
I am willing to look harder at the code, only if scott will clean it up!
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: Oriental Language Based Enryption
Date: Tue, 25 May 1999 19:40:13 -0700
Some excellent responses .. I agree that this is one (and quite traditional)
method, but what about any other methods and techniques ...? The world of
encryption can not be so limited ... By the way, have you ever used any real
Chinese crypto system?
Thanks,
Markku
JUzarek wrote:
> I agree with you Tom. Any cipher system used for english can be used with any
> other language. The alphabets may be different but the same principles apply.
> Chinese has some problems but, when converted to STC (Standard Telegraphic
> Code), the numeric groups can then be enciphered by any means you want. Chinese
> can also be transliterated to the english alphabet - PINYIN for ex - and then
> enciphered.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Implementation of DH/DSS vs. RSA.
Date: Wed, 26 May 1999 00:01:13 GMT
> For instance, I remember having read some discussion (hmmm wasn't it
> even in this newsgroup?) that the new "fast DH key generation" option
> contains some flaws which perhaps may render the generated keys
> insecure.
It does this how? Maybe using larger tables of some sort... I have
never actually looked at it (I am very conservative...)
> I also have a bad feeling about the security of the new CAST
> algorithm. I know that I may be terribly wrong and CAST may be one of
> the finest algorithms invented ever, BUT I do not trust ANY algorithm
> developed by the NSA by default - unless proven otherwise.
CAST was developed by Entrust in Canada, not the NSA, just FYI.
>
> I really doubt the NSA will invest even a single penny in the
> development of a technology that makes public encryption safer - never
> trust a wolf who is selling life-insurances for sheep...
>
Really, well use IDEA or 3DES then... CAST is safe (as far as we know)
and it's design is quite sound.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Oriental Language Based Enryption
Date: Wed, 26 May 1999 00:44:06 GMT
> I agree with you Tom. Any cipher system used for english can be used
with any
> other language. The alphabets may be different but the same
principles apply.
> Chinese has some problems but, when converted to STC (Standard
Telegraphic
> Code), the numeric groups can then be enciphered by any means you
want. Chinese
> can also be transliterated to the english alphabet - PINYIN for ex -
and then
> enciphered.
Well the other languages may have unicode 16-bit chars, but the same
algorithms will work (just take twice as long). There should be no
limitation or bounds based on the language of the message (just like
pictures and sounds can be encoded, but they are not english).
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (JUzarek)
Subject: Re: Oriental Language Based Enryption
Date: 26 May 1999 00:55:17 GMT
>By the way, have you ever used any real
>Chinese crypto system?
No - never had any reason to communicate in Chinese - have enough trouble
ordering Moo Goo Guy Pan !!
Doubt Chinese waiter could understand STC encrypted with a OTP. :-)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AES tweaks
Date: 26 May 1999 01:04:07 GMT
Reply-To: [EMAIL PROTECTED]
David A Molnar <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] wrote:
>> David A Molnar <[EMAIL PROTECTED]> writes:
>>>In any case, it is probably a good thing to have this much attention
>>>paid to block ciphers...and even if they are all breakable by some
>>>secret NSA attack, past results tell us that this will be
>>>discovered about 25 years from now. Just in time to get my kids
>>>(should I have any) interested in cryptography.
>
>> Actually, if you look at the NSA record with particular regards to DES and
>> SHA1 they seem to be pretty honest and academic crypto doesn't seem to lag
>> them by too much.
>
>I was thinking specifically of differential cryptanalysis, which
>was developed by Biham and Shamir in 1991 or so, and developed by
>the NSA...well, who knows. but early 70s. You are quite right in
>noting that academic cryptologists caught on to the reason for
>SHA-0 to SHA-1 fairly quickly, though.
i guess i was under the impression that differential cryptanalysis was
developed earlier. still (again my impression is that) DES was tweaked
to make it harder to do differential crypto on, and this was 20 years before
academia found out about it -- if they knew about differential crypto and
the public didn't then why not put a cipher out that they could break
but the public couldn't? why put out a cipher that was immune to attacks
that the public didn't know about? this is pretty inconsistant with the
idea that the NSA is pure evil...
--
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W
------------------------------
From: Greg Harabedian <[EMAIL PROTECTED]>
Subject: TEA Implementation and Bit Manipulation
Date: Tue, 25 May 1999 17:29:57 -0700
I have a question regarding an implementation of TEA that I am trying to
perform. I am by no means an encryption expert but do have some
knowledge in the area.
As you may know, TEA uses a series of addition and XOR operations. I
know that in the C implementation (see below) published on the web that
unsigned long values are added together. Within C, if the value exceeds
the storage allocation (32 bits for an unsigned long), then the value is
trunctated to 32 bits. This seems to be a common occurrence because of
the iterative additions that are going on. I'm not clear on how the
values are decyphered if truncation is occuring . This means that we
are losing information. Any help in this area would be appreciated.
Thanks,
Greg
[EMAIL PROTECTED]
void encipher(const unsigned long *const v,unsigned long *const w,
const unsigned long * const k)
{
register unsigned long y=v[0],z=v[1],sum=0,delta=0x9E3779B9,
a=k[0],b=k[1],c=k[2],d=k[3],n=32;
while(n-->0)
{
sum += delta;
y += (z << 4)+a ^ z+sum ^ (z >> 5)+b;
z += (y << 4)+c ^ y+sum ^ (y >> 5)+d;
}
w[0]=y; w[1]=z;
}
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES tweaks
Date: Wed, 26 May 1999 02:33:55 GMT
In article <7ifha7$rba$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>David A Molnar <[EMAIL PROTECTED]> writes:
>>[EMAIL PROTECTED] wrote:
>>> David A Molnar <[EMAIL PROTECTED]> writes:
>>>>In any case, it is probably a good thing to have this much attention
>>>>paid to block ciphers...and even if they are all breakable by some
>>>>secret NSA attack, past results tell us that this will be
>>>>discovered about 25 years from now. Just in time to get my kids
>>>>(should I have any) interested in cryptography.
>>
>>> Actually, if you look at the NSA record with particular regards to DES and
>>> SHA1 they seem to be pretty honest and academic crypto doesn't seem to lag
>>> them by too much.
>>
>>I was thinking specifically of differential cryptanalysis, which
>>was developed by Biham and Shamir in 1991 or so, and developed by
>>the NSA...well, who knows. but early 70s. You are quite right in
>>noting that academic cryptologists caught on to the reason for
>>SHA-0 to SHA-1 fairly quickly, though.
>
>i guess i was under the impression that differential cryptanalysis was
>developed earlier. still (again my impression is that) DES was tweaked
>to make it harder to do differential crypto on, and this was 20 years before
>academia found out about it -- if they knew about differential crypto and
>the public didn't then why not put a cipher out that they could break
>but the public couldn't? why put out a cipher that was immune to attacks
>that the public didn't know about? this is pretty inconsistant with the
>idea that the NSA is pure evil...
>
IF you bother to read even ancient texts like the "Puzzle Palce" one of the
most informative books on the NSA you will see that even in those day people
in the know. Knew that 56 bits was to short. The NSA may have made it as
strong possible thus making it immune to differential crypto. But tweeked the
key length of Lucifer from 64 bits to the 56 bits so it could easyly tests all
the keys. Don't take my word for it look at the facts.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Stream Cipher using LFSRs
Date: Wed, 26 May 1999 00:41:42 GMT
I have been looking at stream ciphers using LFSRs and I have a idea. I
called it SCP (Secure Communication Protocal, which is an
assumption...). It's based on the difficulty of finding the factors of
numbers in prime fields.
For example two 8-bit values are multiplied and the output is the
remainder divided by 257 (ab mod 257). The design is as fast as you
can implement a LFSR and is ideal for hardware situations.
In the paper I describe the system and why I believe it's secure. I
haven't presented as much as I could have, but it's only the
preliminaries. I personally think it's well thought out.
I cannot attach it here, but if you want to look I can email a copy
(uuencoded or plain text).
Thanks,
Tom
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Review of Scottu19
Date: Wed, 26 May 1999 02:27:38 GMT
In article <7ifedr$nst$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>This is my first view of the code so bear with me.
>
>The ScottU (19/16) algorithm is an stream cipher which works in CBC
>mode on a n-bit vector in each cycle. A large OTP style key is used
>which somehow (???) is generated for each message which is encrypted.
>The algorithm apparently encodes the file in a forward CBC and
>backwards CBC mode.
>
>The code is a complete utter mess, however some details have been
>extracted. The apparent mixing operation is addition (mod 2^n) and
>subtraction.
>
>Some questions:
>
>1. What is the random data used?
The random data is only used if one is using the option of padding the file
so that the same file would be encrypted differently if the same key is used.
The padding comes from the previous files encrypted. But in looking at that
you are looking past the basic cipher which if padding is not used would
encrypt a file to the same size as original file.
>2. What is the actual mixing mode? (CBC?)
The actual mode is a "wrapped PCBC" mode where the file is treated like
a cylinder and many passes occur such that any one bit change in the input
file changes the whole encrypted file.
>3. What is the actual key? How much entropy per key?
Look at the past articles by Redburn he was first to calulate the
actually entropy. But the key is such that every possible single cycle
19X19 bit S table is used. You find an S-table that is 19X19 and single
cycle and you can get a key to porduce that S-table. The actual entroy
or real key length is over one million bits. A far cry from 128 bits.
>
>I am willing to look harder at the code, only if scott will clean it up!
Actually it is cleaned up. With scott16u I was able to compile it on my
486. The 19bit arrays are hard to play with and I had to use encrypted
messages to send source code to my son so that he could compile it on
his PC. This thing is slow and nasty to compile. The input file is read into
a virtual array and then various 19bit array structures are placed on top of
it and the encryption occurs in several passes. When I first developed the
program I had far more macros than in the current version. They worked in
test programs but as the porgram increase in legnth the macros made tables
overflow even on my sons machine it took months of work to get a small set
of macros that did not make the GNU complier for PC barf. I would be very
surprise if one could get this to work using a compler that was inferior the
DJGPP port of GNU C. If one does I would like a copy
>
>Tom
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: TEA Implementation and Bit Manipulation
Date: Wed, 26 May 1999 01:43:49 GMT
Well neat question but here is what the tea cipher reallyis
...
a += f(b)
b += f(a)
...
To decipher you need to perform the function on 'a' again, well you
already have a (as was used in the last line). So compute
b -= f(a)
a -= f(b) ... using decrypted b ...
You iterate this 32 (or so) times and you are where you started.
BTW, use x-tea (their extended tea) where the key is mixed slower and
safer. The original TEA has some serious flaws but the extended tea
seems to work quite well.
I have the extended tea paper if you want a copy. I also did a paper
on extended-xtea but it's only a silly paper (not much work in it).
Tom
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Wed, 26 May 1999 01:52:39 GMT
On 24 May 1999 17:58:31 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (DJohn37050) wrote:
>The hope is that with many people looking at it, if there is a flaw, the many
>honest people (perhaps looking for fame) will find any flaw before the few
>dishonest people (looking to make an illegal buck).
Well, that *seems* reasonable. So if we try to put this reasoning on
a rigorous basis, we might re-write it as follows:
1) Assuming that all people are alike with respect to background,
available time, resources, and interactions; and
2) Assuming that the dichotomy of "honest" (meaning those who publish)
versus "dishonest" (those who do not) makes sense; and
3) Assuming that there are many "honest" people and few "dishonest"
people;
4) Assuming that someone does find a flaw;
5) Then it is likely that the person who finds a flaw is an "honest"
person, who will publish that flaw, and we will know about it.
But when stated in this bare form, it becomes clear that virtually
every one of those assumptions is false, which means that the
conclusion is not compelling:
1) People are *not* all alike: they have different, backgrounds, time,
resources, interactions and motivations. In particular, well-funded
"dishonest" attackers may work in research laboratories which may have
developed their own private long-term research results. And in such
environments, individuals may work on projects over a period of years
while enjoying financial success. In such environments, groups of
people can cooperate on reaching a single goal, especially since
results can never be published anyway.
In contrast, we are expected to believe that many individuals in the
"honest" group will choose to race every other "honest" person to be
the first to reach the goal. But this is a terribly risky approach
toward a career, and the expectation of such an approach is failure.
So as a long-term force, such motivation is hard to believe. In
contrast, ordinary long-term funded "dishonest" research might cause
any number of people to participate indefinitely. This is very
believable.
2) The implication of "honest" versus "dishonest" seems to be "us who
publish" versus "crooks who don't." But in which category do we place
NSA, or the similar establishments in other countries? In which
category do we place crypto labs within large companies? In which
category do we place contracted and compensated private research which
then belongs to the owner, and cannot be published by the scientists
involved? The "dishonest" category is bogus in that it implies
individual low-tech crooks or hackers who are not the real threat.
3) It is not all that clear that the "honest" people would outnumber
the "dishonest" people, if we include NSA and similar agencies, and
count only those active at any particular time. "Honest" people may
have less motivation and resources, and may have to quit sooner.
So instead of the implication of the original statement, I believe an
unbiased examination of the hidden assumptions in it leads to the
contrary conclusion: It is *more* likely for flaws to be exposed in a
secret, funded, research environment than in the open academia. So we
cannot use a lack of open results to validly argue that no breaks are
likely to exist.
That means any cipher may have already been broken in secret. And our
continued use of such a cipher merely allows our opponents to continue
to expose our information. And we have no way to know when our
information is being exposed. This is just what happened to the other
guys in WWII; one might think we could learn from our own past.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Free Encrypted Email www.hushmail.com [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES tweaks
Date: Wed, 26 May 1999 02:05:50 GMT
In article <7if2rl$196i$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>> I feel that you are wrong. It is obvious the entire AES process is only
>>aimed at keeping encryption easy for the NSA to read. As you know the
>>NSA does its best to try to make encryption programs illegal to export
>>since a large number of methods would make it hard to read peoples mail.
>>So they came up with the CLIPPER chip but to many people screamed.
>>So this is just an extension of that process. No way in HELL would the
>>NSA let a secure method become a standard. I am not sure which horse
>>in this race the NSA is backing but I would not trust any method where some
>>of the developers could have been influenced by the NSA. and it is more than
>>likely they can break several if not all of the methods that where granted
>>this special status. I doubt if any method that is unbreakable by the NSA
>>has a snow balls chance in hell of being blessed.
>
>Why would the NSA bother with the clipper chip if they could just slip in
>an encryption standard that they'd be able to break by some form of advanced
>cryptanalysis? Why would they risk their credibility being completely shot
>if someone in academia should come up with that method of cryptoanalysis and
>break their cipher? The good thing about the AES is that the NSA can pick
It is most likely the NSA did not expect the algorithm to become public
since the Clipper chip was suppose to be a SECRET method in itself.
It was not released until the CLIPPER chip died. And your are right they
would be embarrassed if some European found an easy way to break it.
So they came up with this contest. They can't lose now. Because if some
one 3 years from now shows an easy break they can claim they knew it
in advance but had to keep this information secret. So it suits there purpose
to make the standard look as if it was derived independent of them
>a cipher that it understands and believes that other people (e.g. EU
>states, Russia, China, et al) cannot break. If the NSA is discredited then
>american corporations could turn in the future to some other standard,
>perhaps developed in Europe for which the NSA was not part of the design
>process. The NSA would lose.
>
>And why doubt that the NSA would support a secure standard? Their job, after
>all, is national security, and that is not limited to just their ability to
>wiretap other people -- they also need to keep secrets in US corportations
>really secret. It would not be good if defense contractors could have their
>encrypted e-mail routinely read by foreign intelligence agents, now would
>it?
They would not suport a secure standard because as the presidents spin
doctors say. We can't let secure methods being commom place becasue
drug runners that are not politically approved and terroists might use secure
encryption and the MAJOR task is to contorl export of encryption technologes
to the bad guys.
So why have a contest to really develop a secure method and advertise the
fact all over the world. The only possible reason would be to trick people
into using nonsecure encryption.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Implementation of DH/DSS vs. RSA.
Date: Wed, 26 May 1999 01:48:08 GMT
> Also, I thought CAST was from Northern Telecom. That's about all
> I know about it, though.
Well 'Entrust' is a subs. of Nortel. Nortel actually owns about 400
child companies including some hardware manufactures. I worked at
Nortel for about a month as co-op. Little tip work their full time,
not co-op. They treat the co-ops like crap their. Full time workers
however are treated well :)
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Crossposted-To:
netscape.public.mozilla.security,alt.netscape,comp.infosystems.www.browsers.ms-windows
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: format of Netscape signed.db file?
Date: Wed, 26 May 1999 02:05:59 GMT
Does anyone know the format of the signed.db file, used by
Netscape Communicator 4.x to store site capabilities?
Unlike the cert7.db file, it doesn't appear to be a dbm 1.85 file.
I've been able to figure out a few things about it by inspection,
but it generally looks like a mess. All suggestions appreciated.
Thanks --Paul
------------------------------
** 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
******************************
