Cryptography-Digest Digest #985, Volume #13 Fri, 23 Mar 01 23:13:00 EST
Contents:
Re: NTRU - any opinions ("Michael Scott")
Re: the classified seminal 1940 work of Alan Turing? ("Douglas A. Gwyn")
Re: I am interested in technologies to make NSA's listeners crazy when they listen
secretly other people's phone conversations ... (John Savard)
Re: My note on 5/16/1999 -- PGP etc. ("Tom St Denis")
Re: on-card key generation for smart card (Peter Gutmann)
Re: How to eliminate redondancy? (Nicol So)
Re: on-card key generation for smart card (Paul Rubin)
Re: I am interested in technologies to make NSA's listeners crazy when they listen
secretly other people's phone conversations ... ("Dramar Ankalle")
A new DES? ("Ryan M. McConahy")
Re: Crypto in VB3 ("Ryan M. McConahy")
Re: A new DES? (Paul Rubin)
Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
Re: What the Hell...Here's what my system can do at it's best... (wtshaw)
Re: Open Source Implementations of PGP (Tony L. Svanstrom)
----------------------------------------------------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: NTRU - any opinions
Date: Fri, 23 Mar 2001 19:16:43 -0600
Amazing.
Why won't Certicom let NTRU buy a copy of Certicom's toolkit?
Why don't NTRU do their research and make comparison instead with the
state-of-the-art ECC timings published last year in
http://www.cacr.math.uwaterloo.ca/ year 2000 technical reports 25 and 36?
> I'm not sure to which figures Don is referring, but he's certainly
> right that ECC SigGen should be faster than ECC SigVer
He's referring to Table 1 of the paper co-authoring by yourself (Joe
Silverman)
http://grouper.ieee.org/groups/1363/new/P1363.1-NSSSubmission.pdf
If he is certainly right, your paper is certainly wrong. Pity the poor
punter trying to make a comparison betwen NTRU and ECC!
Mike Scott
"Dan Bailey" <[EMAIL PROTECTED]> wrote in message
news:Pine.SOL.4.10.10103230921420.17393-100000@hickey...
> On 8 Mar 2001, DJohn37050 wrote:
>
> > ECC is very suited to constrained environments, having short keys and
sigs and
> > simple key gen. It is not cleat at all to me that NTRU is as suited as
it has
> > longer keys than even RSA, longer sigs than RSA, not studied key gen yet
but I
> > do not see how anything can be simpler than ECC. It seems to be faster
than
> > RSA on NTRU's implementations but they also seem to say that ECC SigGen
is
> > slower then SigVer which does not compute.
> > Don Johnson
> >
>
> Joe Silverman responds:
>
> Listed below is a short table running NTRU's crypto package NERI 5.4
> on an 800 MHz Pentium box and comparing it to Wei Dai's implementation
> of RSA and ECC running on an 850 MHz Celeron. I realize that
> Certicom's implementation of ECC using Koblitz curves and GF(2^k) ONBs
> is undoubtedly faster than Wei Dai's package. I would be very happy to
> verify this, but we have not been allowed to purchase a copy of
> Certicom's toolkit, even for testing purposes.
>
> ---------------------------------------------------------
> Encrypt (blocks per second)
> NTRU 16556
> ECC 70
> RSA 3100
>
> Decrypt (blocks per second)
> NTRU 8620
> ECC 39
> RSA 98
>
> Sign (signatures per second)
> NTRU 3215
> ECC 139
> RSA 97
>
> Verify Signature (verification per second)
> NTRU 3225
> ECC 76
> RSA 3315
>
> Key Generation (keys per second)
> NTRU 1512
> ECC 140
> RSA ---- (very slow!)
>
> Notes:
> (1) NTRU times are using the NERI toolkit (portable C code, no
specially
> written assembly routines) on an 800 MHz Pentium.
> (2) RSA and ECC times are using Wei Dai's Crypto++ 4.0 toolkit
> (C++ with specially written assembly routines for multiprecision
add
> and subtract) on an 850 MHz Celeron machine. Figures are from
> <http://www.eskimo.com/~weidai/benchmarks.html>.
> (3) RSA uses encryption/signing exponent e = 17.
> (4) If ECC uses a precomputed table of points, speeds approximately
> double.
> (5) All figures in the table are at an RSA 1024 bit equivalent
> security level.
> ---------------------------------------------------------
>
> I'm not sure to which figures Don is referring, but he's certainly
> right that ECC SigGen should be faster than ECC SigVer. Note that in
> the above table, the units are signatures/second and keys/second, not
> ms/signature and ms/key, so the table says that key gen is about
> twice as fast as signature verification.
>
> Don, since we're not allowed to purchase a copy of Certicom's toolkit,
> would you be willing to at least post a table giving key generation
> (keys per second), encrypt/decrypt (blocks per second), and
> sign/verify (signatures per second) for Certicom's latest toolkit,
> including details such as processor and clock speed, which type(s) of
elliptic
> curve(s) you're using, whether you're using a precomputed table, and
> if so, how much space it takes, etc.? I've made a start at this for
> NTRU in the table, and I'd be happy to provide more details so that we
> can make some meaningful comparisons. I'd also be happy to do a direct
> comparison of NTRU's NERI package and Certicom's ECC package on a
> constrained device, such as a Palm.
>
> Finally, let me respond to Don's comment about key sizes. It is true
> that NTRU key sizes are a little larger than RSA key sizes, and both
> are longer than ECC. So if the single most important factor in an
> implementation is key size, ECC makes sense. However, we have found
> that in most practical applications, key size is a secondary issue.
> Speed of execution, total storage (keys and program), and power
> consumption are the critical items in constrained devices such as
> PDAs, smart cards, USB tokens, etc. The NTRU algorithm is much less
> complicated than ECC. (Elliptic curve addition is far from simple, as
> anyone can see from the P1363 standard, for example). Thus as a
> practical matter, we have found that NTRU's somewhat larger keys are
> more than offset by NTRU's greater efficency (higher speed using less
> power) and smaller footprint.
>
> Joe Silverman
> VP Research, NTRU Cryptosystems
>
>
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: the classified seminal 1940 work of Alan Turing?
Date: Sat, 24 Mar 2001 01:58:16 GMT
Frank Gerlach wrote:
> There is no such thing as "fundamentals of mathematics". Check
> Goedel,Turing and Chaitin.
> In a nutshell, they state that most mathematical theories (a theory is a
> set of axioms) *cannot* be reconciled. If this is true, then there cannot
> be a "fundament of mathematics".
I have to take issue with that interpretation. At worst, what they
showed was that no (sufficiently rich) axiomatic system is *complete*,
i.e. capable of on its own terms resolving all questions that might
arise. Hofstadter's book "Gödel, Escher, Bach: An Eternal Golden
Braid" (which is worth reading anyway) tries to make this more
intelligible. All the basic systems with which *most* mathematicians
work are (thought to be) mutually consistent.
The idea of finding a more powerful mathematics through tweaking the
axioms doesn't get you very far. Most of the interesting systems
tend to share some similar structures, brought out by tools such as
Universal Algebra. One of the reasons elliptic curves are
interesting is because they relate to many fields of mathematics
that were formerly thought to be less related.
There are also only a finite number of axiomatic systems under a
specified complexity; this is partly the domain of combinatorial
logicians, whose work is eerily fascinating.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: alt.2600,alt.politics.org.cia,alt.security
Subject: Re: I am interested in technologies to make NSA's listeners crazy when they
listen secretly other people's phone conversations ...
Date: Sat, 24 Mar 2001 01:43:08 GMT
WARNING to other readers of the original post, intending to reply:
followups had been altered to alt.2600 only.
On 23 Mar 2001 22:44:06 GMT, [EMAIL PROTECTED] wrote, in part:
>This would be great ... this would teach a lesson to them .... actually I
>think that they may have implemented programs to minimize this risk ... well
>I think that it is quite adventurous technology initiative .... good for
>their mental states ....
I suppose you could try reading the science-fiction novel MACROSCOPE
by Piers Anthony...
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: My note on 5/16/1999 -- PGP etc.
Date: Sat, 24 Mar 2001 02:11:44 GMT
"The Alien" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You're not the only one who doesn't trust Mr. Zimmermann! I don't either.
Name one good alternative.
Tom
------------------------------
From: [EMAIL PROTECTED] (Peter Gutmann)
Subject: Re: on-card key generation for smart card
Date: Sat, 24 Mar 2001 02:15:28 -0000
Paul Rubin <[EMAIL PROTECTED]> writes:
>Chenghuai Lu <[EMAIL PROTECTED]> writes:
>> Could anybody tell me the average time of on-card 1024-bit RSA key
>> generation for the best smartcard application.
>>
>> Thanks.
>The cards I've been using can do it in under a minute, and I doubt
>those are the fastest. 8 minutes is ridiculous.
Are you sure the keygen is being done on the card? I've seen a few cards which
do the keygen in software on the host and then load the resulting key into the
card. Are you actually sending raw generate-a-key APDU's directly to the card
and seeing the result come back a minute later? If any smart card manages to
do a keygen in less than 30s I'd say it's faking it on the host rather than
using the card.
Peter.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: How to eliminate redondancy?
Date: Fri, 23 Mar 2001 21:16:40 -0500
Reply-To: see.signature
Benjamin Goldberg wrote:
>
> ... A function whose domain and range are the same is a permutation.
This is not true. Here's a simple counter-example:
Function f: N -> N is defined such that
f(0) = 0,
f(n) = n-1 for n>0.
Domain of f = range of f = N. However, f is not one-one, and therefore
cannot be bijective.
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: on-card key generation for smart card
Date: 23 Mar 2001 18:47:14 -0800
[EMAIL PROTECTED] (Peter Gutmann) writes:
> >The cards I've been using can do it in under a minute, and I doubt
> >those are the fastest. 8 minutes is ridiculous.
>
> Are you sure the keygen is being done on the card? I've seen a few cards which
> do the keygen in software on the host and then load the resulting key into the
> card. Are you actually sending raw generate-a-key APDU's directly to the card
> and seeing the result come back a minute later? If any smart card manages to
> do a keygen in less than 30s I'd say it's faking it on the host rather than
> using the card.
I'm using the vendor-supplied CSP and can't be completely sure what
it's doing. But yes, it typically takes 30-60 seconds. Doing it on
the workstation takes under a second. The keygen time on the card is
about what I'd expect based on the signing speed of the card.
------------------------------
From: "Dramar Ankalle" <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.politics.org.cia,alt.security
Subject: Re: I am interested in technologies to make NSA's listeners crazy when they
listen secretly other people's phone conversations ...
Date: Fri, 23 Mar 2001 21:54:54 -0500
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> WARNING to other readers of the original post, intending to reply:
> followups had been altered to alt.2600 only.
>
> On 23 Mar 2001 22:44:06 GMT, [EMAIL PROTECTED] wrote, in part:
>
> >This would be great ... this would teach a lesson to them .... actually I
> >think that they may have implemented programs to minimize this risk ...
well
> >I think that it is quite adventurous technology initiative .... good for
> >their mental states ....
>
> I suppose you could try reading the science-fiction novel MACROSCOPE
> by Piers Anthony...
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
Or Necroscope, by Brian Lumley
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: A new DES?
Date: Fri, 23 Mar 2001 21:52:43 -0500
Has anyone (like the people who make modified PGP builds) considered
implementing DES with a 256 or 512 (paranoid mode) key? This might be nice,
as DES has been so well cryptanalised.
Ryan M. McConahy
------------------------------
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Re: Crypto in VB3
Date: Fri, 23 Mar 2001 21:55:21 -0500
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I'm wrather new to VB (I used VBDOS!). Can you tell me what to do
with the "byte" types? VB3 doesn't seem to support them. And how
would I fix the 16bit/32bit thing?
Thanks in advance,
Ryan M. McConahy
Hard wrote in message <[EMAIL PROTECTED]>...
>On Mon, 19 Mar 2001 15:56:10 -0500, "Ryan M. McConahy"
><[EMAIL PROTECTED]> wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>
>>To: sci.crypt
>>Subject: Crypto in VB3
>>
>>Does anyone know of any libraries/DLLs/source code that I could use
>>in Visual Basic 3?
>>
>>Thanks in advance.
>>
>>Ryan M. McConahy
>>
>>-----BEGIN PGP SIGNATURE-----
>>iQA/AwUBOrZyMqFn8yalvjU2EQLmbgCfQjFk8V8ezHINCRlShQQCofcWFpwAmwQZ
>>2B/fTUpE3E7T6isFRQmGNo31
>>=1vLJ
>>-----END PGP SIGNATURE-----
>>
>
>Go here: http://zarr.net/vb/download/encryption.asp
>
>This code is for 32-bit VB, but you may be able to get it to work in
>VB3 by keeping track of variables (long is 16-bit in VB3 but is
>32-bit in current versions, etc.)
>
>The MD5 code is questionable (didn't pass vector tests) but the
>SHA-1 and the RC4 are good (pass vector tests), although slow. The
>mime
>(base64) encoding and decoding also works well.
>
>There are also modules for CRC calc, LZW compression of strings,
>Gost2, and SkipJack encryption, although I haven't tested them.
>
>All in all, it is a fairly fun package for horsing around in VB.
=====BEGIN PGP SIGNATURE=====
Version: 6.5.8ckt http://www.ipgpp.com/
Comment: KeyID: 0xA167F326A5BE3536
Comment: Fingerprint: 838C 815E 5147 2168 5A76 16F1 A167 F326 A5BE 3536
iQA/AwUBOrwMlaFn8yalvjU2EQJzKACgyvb3PrZyuPtmRiVGjHaYmeuaR1gAoO9n
X9TdI+pF11+D4oXb3RhHuKMB
=Ml/S
=====END PGP SIGNATURE=====
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: A new DES?
Date: 23 Mar 2001 19:10:30 -0800
"Ryan M. McConahy" <[EMAIL PROTECTED]> writes:
> Has anyone (like the people who make modified PGP builds) considered
> implementing DES with a 256 or 512 (paranoid mode) key? This might be nice,
> as DES has been so well cryptanalised.
Yes but if you changed it like that, it wouldn't be DES any more.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: How to eliminate redondancy?
Date: 24 Mar 2001 03:02:58 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>Joe H. Acker wrote:
>>
>> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
>>
....
>> There are no incorrect definitions, just more or less appropriate
>> ones.
>
>No. The range of a function has a well defined meaning. Using a
>meaning other than the correct definition is incorrect.
>
>From the Merriam-Webster dictionary's definition of "range":
>6a the space or extent included, convered, or used.
>8a the set of values a function may take.
>8b the class of admissible values of a variable.
>
>If you correctly consider (for example) the gzip function, it's domain
>is the set of all files, and it's range is the set of those files
>producable by gzip. It would be incorrect to say that it's range is the
>set of all files. If you consider it's range to be the set of those
>files producable by gzip, then it is a bijective function. If you
>incorrectly consider it's range to be the set of all files, then it
>would appear to not be a bijective function.
>
>> > If you use definitions other than those that the scientfic community
>> > accepts, you can make any sort of claims you like.
>>
>> Okay, let's find another term for the property David Scott has
>> proposed. To name it "bijective" is confusing and not appropriate, so
>> let's call it "s-bijective" (S in honour of David Scott). But perhaps
>> that is not even necessary because there's already a precise term for
>> this that is established in contemporary mathematics---I'd guess there
>> is.
>
>Yes. A function whose domain and range are the same is a permutation.
>
>I have said this many times. Perhaps you haven't been paying attention?
>
>> Anyway David Scott has made clear *what* exactly he means, although he
>> has done this informally and might not always been using the
>> appropriate terms.
>
>Actually, Scott has not managed to use the correct terms even once when
>referring to his system. This is called a "flat learning curve."
>
>> So instead of argueing about names, is there actually someone who has
>> opinions about how and how much overall security an s-bijective
>> compressor would add or not add?
>
I have been thinking about what terms to call a lot of
my routines. Over all when I run a series of programs
in batch file. I want their to be a bijective relationship
of input messages to output messages. Where each program
can expect any possible value if the files it uses.
For example if one compresses using h2comaf.exe you go
from a file of special symbols to a FOF ( finitely odd file )
this file of a weird form it is compsed of 8 bit bytes of any
value one or more bytes in length. But the last byte can't be the
"all zero: byte.
To use the above file I use a program to change it to a normal
8-bit binary file that we have one or more bytes and each bit
can be any value.
or I can change it to a file of fields each being 16 bytes as
for standard ECB mode Rindael. still so each block of 16 bytes
can be any value yet has a 1-1 biject relationship to the FOF
file.
Maybe all these kinds of transforms could be called IMPEDANCE
MATCHING CODE. Since this is kind of what happens to the
flow of data. No gaps or dead spots.
Just a thought.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What the Hell...Here's what my system can do at it's best...
Date: Fri, 23 Mar 2001 20:55:17 -0600
In article <[EMAIL PROTECTED]>, Keill Randor
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (wtshaw) wrote in article
> <[EMAIL PROTECTED]> :
> >In article <[EMAIL PROTECTED]>, Keill Randor
> ><[EMAIL PROTECTED]> wrote:
> A couple of other people know what I have. One of whom is a SERIOUSLY
good computer engineer (aged 55), who dosen't want to touch this with a
bargepole... IF, however, no-one wishes to help me, then he'll make sure
that they will pay (quite dearly) for that mistake (maybe with their
existence as they know it - (they cannot deal with him (he's at the top of
their list if things go to hell - (I don't even know him by his real
name))) - the only reason I am dealing with GCHQ in the first place is
because he told me to....). (I'm giving them one last chance at the
minute, if they don't take it, then - Oh dear...).
They turned me down as well, but they still were interested in following
my progress. One reason I got involved in the AES process was to see how
far it would go.
> As to all this stuff in the news about cyber-terrorism, and the (new?)
spying stuff going on, what I have, is the most powerful weapon in the
world for what it does. If the 'other side' gets it first, then God help
the NSA, because that's who they'll need....
Not quite as strong, seems I have said something similiar before. But, I
know my stuff and I don't know yours.
>
Ron Rivest is a rather cool guy.
> Simple solutions for simple problems............
Nothing wrong with that. But, the result needs to be heavy.
--
GWB is sure one day to have a presidential library. The big
question is on which off-shore rig should it be placed.
------------------------------
Subject: Re: Open Source Implementations of PGP
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Sat, 24 Mar 2001 03:23:01 GMT
Peter Harrison <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Mar 2001 23:12:10 +0100, "Henrick Hellström"
> <[EMAIL PROTECTED]> wrote:
>
> >"Tony L. Svanstrom" <[EMAIL PROTECTED]> skrev i meddelandet
> >news:[EMAIL PROTECTED]...
> >> Peter Harrison <[EMAIL PROTECTED]> wrote:
>
> >> Took a look at your pages and... well... it's basically the same as I've
> >> been working on, and... well... messing with PGP will just slow you
> >> down. Do like me and create a good from scratch-solution (BTW, I'll
> >> release this as open source too, when I have the time).
> >
> >
> >I agree. Messing with other peoples code might be educational and perhaps an
> >evil bad if you want your software to be compatible with others. Otherwise
> >it is best to start from scratch.
> The problem with PGP is that it isn't very well suited for 'dumb
> developers'. By dumb I mean developers like me who want to implement a
> solution incorporating secure email without having to become maths
> professors.
All the most known algorithms are available in all kinds of formats
(libs, languages, explanations) all over the Net; you don't have know
more math to use them than your language of choice would require
otherwise.
> PGP currently allows too many decisions - ie what algorithms to use, key
> sizes for the various algorithms, and suchlike. Thats nice if you know
> anything about security - but if you just want something to drop into your
> application this isn't so good.
Then you read the RFC and implement only the musts:
<URL:http://www.rfc-editor.org/rfc/rfc2440.txt> or you write your own
thing, but then you have to look at the pros and cons of doing such a
thing.
> There are also things that PGP (GnuPGP for example) just doesn't do - the
> big weakness is automatic key discovery. Imagine that whenever you sent an
> email your email client looked up the recipient on a server on a Trust
> Network and downloaded the approapriate key from the Trust Network. If no
> key is found the user is warned that no key was found, and confirms that
> the email is to be sent in the clear. The DEFAULT will be to send
> encrypted email ALL THE TIME.
It's there, and those keyservers are not less secure than what you are
suggesting. As a matter of fact... your system is less secure because a)
it's easier to manipulate the data that a user will get and use from the
keyserver, and b) people will feel safer when encryption is used "all
the time".
Of course, encryption won't be used "all the time", it will only be used
by the users of your work; compared with people using PGP which not only
is an existing open standard, not only was designed by a lot of people
that know a lot about cryptography, not only has been reviewed a lot by
people all over the world but also has a hell of a lot more users...
> The same goes for receiving email - when it is received any signature in
> the email is authenticated by pulling down the senders key from a server
> on the Trust Network.
Which of course is useless since MITM is a serious problem with your
system; so all you've managed to do is to give false security, which is
far worse than no security.
> The Trust Network is a network of servers which share keys. When you send
> your public key to a server on the Trust Network it distributes that key
> to a number of other servers. Its a bit like a distributed database -
> except that there is a continuous connection between server peers
> verifying keys. If a key is found to be corrupted by a peer a discussion
> takes place to determine the correct key, and the error is corrected.
Nice words, but beyond saying "if it isn't secure it will be secured" I
don't see anything that actually backs up you claim that it will work
that way. A simple MITM on the same network as a user will make every
message sent and recieved by him unsecure, while your software tells him
that he's secure... NOT GOOD!!!
> If the corrupt server refuses to correct the error - due to being hacked
> or whatever - the server is removed from the network.
Then there has to be a central server that controls the whole thing
(unless you allow the majority to rule, in which case an attac based on
having a lot of servers on that network will completely take over it);
and then people has to trust that server... Then we're down to a limited
version of PGP that doesn't allow that the users pick an algorithm that
they, a protocol less looked at and they have to trust some unknowns
server for it to work. Anyhow, who's going to pay for that server when
it's all free, and if people stop donating but keep on using it more and
more then will you keep on paying for it to remain online?
[A]
> When I use the term "Trust NetworK" I simply mean that you can trust that
> the owner of a certain Email Address is attached to a certain Public Key.
[B]
> I am not trying to create "Trust" in the same sense a Certificate
> Authority is.
You can't do [A] without [B], at least not the way that you're trying
to.
> The objective with the trust network is to make Key Distribution invisible
> to the user - not nessasarily more secure. The idea is that by making
> encryption easier for users it will make encryption more common.
Then why don you just improve the (G)UI on existing
OpenPGP-implementations by writing your own implementation...?
> While I have my own implementation I want to move toward being at least
> partially compatible with PGP (ie supporting a subset of the algorithms,
> using the same packet formats).
<URL:http://www.rfc-editor.org/rfc/rfc2440.txt>
I don't know (about your ideas/work), to me it just looks like a lot of
hype combined with you wanting to reinvent the wheel simply because PGP
is too complicated for you to use (as a programmer).
I'm in no way trying to put you down nor am I saying that it is like
that, just saying that it looks like it to me; there are lots of reasons
for me to think so, some stated in this e-mail.
Good luck with your work.
/Tony
--
########################################################################
I'm sorry, I'm sorry; actually, what I said was:
HOW WOULD YOU LIKE TO SUCK MY BALLS?
- South Park -
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
