Cryptography-Digest Digest #122, Volume #11 Mon, 14 Feb 00 17:13:01 EST
Contents:
Re: Does the NSA have ALL Possible PGP keys? (Jim)
Re: Funniest thing I've seen in ages - RSA.COM hacked :) (lurker)
Re: Period of cycles in OFB mode (Tim Tyler)
Re: Odp: New encryption algorithm ABC. (Tim Tyler)
Re: Has some already created a DATA DIODE? (John Savard)
Re: Predicting the next random number (John Savard)
Re: Funniest thing I've seen in ages - RSA.COM hacked :) (Tramm Hudson)
Re: Voice Encryption/Communications Protocol ([EMAIL PROTECTED])
Re: Voice Encryption/Communications Protocol ([EMAIL PROTECTED])
Odp: Odp: New encryption algorithm ABC. ("Bogdan Tomaszewski")
Re: Basic Crypto Question 3 ([EMAIL PROTECTED])
Re: Is there a list for this newsgroup? (Mok-Kong Shen)
Re: Basic Crypto Question 3 ([EMAIL PROTECTED])
Re: Large Floating Point Library? (Mok-Kong Shen)
Re: Guaranteed Public Key Exchanges (Dan Day)
Re: Basic Crypto Question 3 (David Wagner)
Re: Guaranteed Public Key Exchanges (Dan Day)
Re: Basic Crypto Question 3 (David Wagner)
Re: Quastion about RSA function. Help!!!! ([EMAIL PROTECTED])
Re: Guaranteed Public Key Exchanges (Paul Koning)
Re: Guaranteed Public Key Exchanges (Paul Koning)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Mon, 14 Feb 2000 19:30:15 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 14 Feb 2000 11:51:34 GMT, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> Anonymous <[EMAIL PROTECTED]> wrote:
>> There are a couple of interesting threads on talk.politics.crypto
>> originating from a cryptographer with www.filesafety.com. They
>> purport that the NSA has ALL POSSIBLE keys for PGP and that all PGP
> ^^^^^^^^^^^^^
>like all the emotionally-heated previous answers have made plausible, it
>is very unlikely that the NSA stores all possible keys
>
Why would they want to STORE them? To what end? Pointless as
well as impossible.
Much easier just to run through each key hoping they hit the right
one sometime before the sun burns out.
>I'm not a cryptographer, but obviously most of the so-called
>cryptographers here seem to be a bit naive. Here are some reasons why
>your claims could - to some extend - be right:
>
>- It is reasonable to assume that the NSA is able to run very fast and
>exhaustive dictionary attacks against the passwords that secure the
>private key.
That's not quite the same thing as breaking the cipher, is it?
If they wanted to do that, why would they bother generating
and storing all the keys.
>- It is reasonable to assume that the NSA is able to obtain any private
>key stored on the harddisk of any individual at home, if he/she is the
>specific target of an attack.
Only by forcing a weak passphrase, or getting the suspect to reveal
it.
>2. There's a possibility to some degree merely depending on the NSA's
>will to break the law (and eventually be catched while doing this), that
>the NSA is able to read almost any mail encrypted by PGP, because they
>have obtained the key and password of most PGP users by side-channel
>attacks.
They've obtained the keys and passwords of absolutely EVERYONE.
world-wide, who uses PGP. Aw, come on!! Their budget and staffing
stretch that far?
--
Jim,
nordland at lineone.net
amadeus at netcomuk.co.uk
------------------------------
From: lurker <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Funniest thing I've seen in ages - RSA.COM hacked :)
Date: Mon, 14 Feb 2000 14:42:54 -0500
On Mon, 14 Feb 2000 14:40:38 GMT, Bob Silverman <[EMAIL PROTECTED]> wrote:
^^^^^^^^^^^^^^
>In article <888hp2$6sp$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
[snip]
>> I wonder how long it'll take them to notice...Hhhm, would you
>> trust RSA with your data security now? ;)
>
>Will anyone trust YOU now???
>
>Our website address is www.rsasecurity.com and has been so
>for some time. www.rsa.com is no longer a valid URL.
[snip]
Hmm.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Feb 2000 19:24:15 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: <[EMAIL PROTECTED]> wrote:
:> There are other ways of counting that can appear more complex:
:>
:> initialise: count = x, where 0 <= x < 2^64
:> repeat: count += y, where 1 <= y < 2^64 and y is odd
: Good point.
This is a linear version or the polynomial counter Terry Ritter originally
suggested. I suspect higher terms would be overkill.
As well as being odd, y should also be not be /too/ sparsely populated.
: * Are two half-size counters better than a single full-size counter?
Two half-size counters run faster than a single full size counter -
as their carry chains are half as long - and if any non-power-of-two
modulus is involved anyway, then that will work more rapidly as well.
However, you can't use only power-of-two moduli any more - since to get
the maximal period, the moduli have to be relatively prime.
In the proposed scheme, the counter(s) are used to seed a block cypher,
whose operation is' likely to be more time consuming than incrementing
the counter. Performance seems likely to be non-critical.
There may /still/ be some practical benefit if using the structure as (for
example) a disc-encryptor. Use of counter mode allows random access to
the stream of random output. However the seek time is dependent on
x + y * n & (2^64-1). Splitting the multiplication into two smaller
ones (whose results can be simply concatenated) helps here.
The "one big counter and the power-of-two modulus" /is/ attractively
simple, though.
If the fact that one bit flips like a stroboscope is at all relevant, you
can always XOR some of the high bits over the (non-random) low ones.
If you /don't/ need the random access - or the ability to parallelise -
the first scheme suggested on this thread seems the best of those
mentioned so far.
It's likely to produce a larger period for any given counter size, it can
use a simple counter, and apparently it does not suffer from the
birthday-like problem David Wagner mentioned.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Sometimes, the best things in life really suck.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Odp: New encryption algorithm ABC.
Reply-To: [EMAIL PROTECTED]
Date: Mon, 14 Feb 2000 19:35:49 GMT
Bogdan Tomaszewski <[EMAIL PROTECTED]> wrote:
:> Then take the best compression tool you know and compress the
:> cyphertext file. If there's a significant amount of compression
:> as a result, your algorithm might be weak.
: I work with this : 100% in ->about 100 % out....
This /is/ a test for randomness, but - as the compressor isn't designed
for this function - it usually works very badly.
Even very weak RNGs - like LCGs - typically pass this test with flying
colours ;-/
Dedicated tests for randomness exist, and their use is recommended.
I'll repeat the wisdom that good randomness does not necessarily equate to
strength, and add that non-randomness does not necessarily equate to
weakness.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I will never lie to you.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Has some already created a DATA DIODE?
Date: Mon, 14 Feb 2000 13:04:27 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote, in part:
>AlgM is a good place to start, just don't use LCG's as the underlying
>PRNG. AlgM with two 'long' Fibonacii generators is secure.
His method doesn't seem to be too different from MacLaren-Marsaglia:
here, the choice is between one of many seed values, but the seed
values are only advanced when used.
LFSRs and LCGs are insecure for the same reason, both being linear, so
I don't think it matters which one you use for MacLaren-Marsaglia.
The literature references to MacLaren-Marsaglia generators being
cracked involved short-period LCGs, where the entire output, including
the LSBs, with periods down to two, was used in the output stream, so
I don't think they can be used to support a conclusion that the
technique ought to be abandoned. However, I would recommend, at a
minimum, a technique like this: have _two_ MacLaren-Marsaglia
generators, and use the XOR of their output as input to a _third_
buffer.
I have little fear that this kind of technique will suddenly be proven
insecure. However, the PRNGs used for the three buffers must have
rel-prime periods.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Predicting the next random number
Date: Mon, 14 Feb 2000 13:35:00 GMT
[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>I was under the impression that Las Vegas never uses Pseudorandom.
My fault for not reading carefully enough...I thought he just said
"ANY random number generator". (Of course, there are those video slot
machines; I'm not sure, but I would suspect _they_ might use PRNGs.)
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Tramm Hudson)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Funniest thing I've seen in ages - RSA.COM hacked :)
Date: 14 Feb 2000 20:42:45 GMT
Bob Silverman <[EMAIL PROTECTED]> wrote:
[snip]
>Our website address is www.rsasecurity.com and has been so
>for some time. www.rsa.com is no longer a valid URL.
That's [EMAIL PROTECTED] stating that rsa.com is no longer a valid
address for their website, but still valid for email.
Isn't that just a bit confusing for your customers?
Or are you just a mirror of [EMAIL PROTECTED]?
--
o [EMAIL PROTECTED] [EMAIL PROTECTED] O___|
/|\ http://www.swcp.com/~hudson/ H 505.323.38.81 /\ \_
<< KC5RNF @ N5YYF.NM.AMPR.ORG W 505.284.24.32 \ \/\_\
0 U \_ |
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Voice Encryption/Communications Protocol
Date: Mon, 14 Feb 2000 20:39:11 GMT
I'm not an expert, but here are some comments:
> If two parties want to communicate securely over a PSTN line, is the
> following protocol secure:
>
> 1. Each party creates DH or RSA key pair.
why each party if only one key is used?
> 2. Each party sends the other party their public key.
see above
> 3. The Caller, encrypts the session key (3DES,Blowfish) with the other
> party's public key, and sends it to ther other party over the line.
> 4. The Caller destroys his own secret key (no longer required).
what was it used for anyway?
> 5.authentication done by a Hash of the session key.
>
> How secure is this protocol for voice communications?.
seems to be secure only if the public key exchange was not compromised
> Is it subject to man in the middle attack.
yes, anybody can drop in and give the caller a wrong public key of the
called party, then intercept the session key re-encrypt it with the
called party's public key; from now on, the attacker knows the session
key and can intercept and change messages as he/she likes
At least, that's how I understand it. But I'm not an expert, as I told
you.
Greetings,
John Stone
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Voice Encryption/Communications Protocol
Date: Mon, 14 Feb 2000 20:39:15 GMT
I'm not an expert, but here are some comments:
> If two parties want to communicate securely over a PSTN line, is the
> following protocol secure:
>
> 1. Each party creates DH or RSA key pair.
why each party if only one key is used?
> 2. Each party sends the other party their public key.
see above
> 3. The Caller, encrypts the session key (3DES,Blowfish) with the other
> party's public key, and sends it to ther other party over the line.
> 4. The Caller destroys his own secret key (no longer required).
what was it used for anyway?
> 5.authentication done by a Hash of the session key.
>
> How secure is this protocol for voice communications?.
seems to be secure only if the public key exchange was not compromised
> Is it subject to man in the middle attack.
yes, anybody can drop in and give the caller a wrong public key of the
called party, then intercept the session key re-encrypt it with the
called party's public key; from now on, the attacker knows the session
key and can intercept and change messages as he/she likes
At least, that's how I understand it. But I'm not an expert, as I told
you.
Greetings,
John Stone
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Bogdan Tomaszewski" <[EMAIL PROTECTED]>
Subject: Odp: Odp: New encryption algorithm ABC.
Date: Mon, 14 Feb 2000 20:36:17 GMT
My new encryption algorithm is the absolutely random function. Entropy is
7,88.
This fukction show me all primary number in any range.
I see what number is primary but I don't make:
FOR x=1 to sqr(N)
IF N/x=INT(N/x) THEN (No primary) EXIT
NEXT
N is primary
END
I seek of programme to breaking of codes. I would want to code text eg 8
with bit key and to taste to decode message.
I think, that are such programmes, working independently from this whether
algorithm coding is well-known whether not.
best regards
--
Bogdan Tomaszewski
[EMAIL PROTECTED]
U�ytkownik Tim Tyler <[EMAIL PROTECTED]> w wiadomo�ci do grup dyskusyjnych
napisa�:[EMAIL PROTECTED]
> Bogdan Tomaszewski <[EMAIL PROTECTED]> wrote:
>
> :> Then take the best compression tool you know and compress the
> :> cyphertext file. If there's a significant amount of compression
> :> as a result, your algorithm might be weak.
>
> : I work with this : 100% in ->about 100 % out....
>
> This /is/ a test for randomness, but - as the compressor isn't designed
> for this function - it usually works very badly.
>
> Even very weak RNGs - like LCGs - typically pass this test with flying
> colours ;-/
>
> Dedicated tests for randomness exist, and their use is recommended.
>
> I'll repeat the wisdom that good randomness does not necessarily equate to
> strength, and add that non-randomness does not necessarily equate to
> weakness.
> --
> __________
> |im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
>
> I will never lie to you.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Basic Crypto Question 3
Date: Mon, 14 Feb 2000 21:01:09 GMT
In article <uCFu23nd$GA.256@cpmsnbbsa02>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> > 1. If a plain text is encrypted with three Ciphers, is it
> as strong as
> > the strongest Cipher in the Chain or as week as the
> weekest?
>
> Under the majority of circumstances, it is believed that it
> is at least as strong as the strongest cipher. However it
> may be possible to construct a situation where a set of
> otherwise strong ciphers may be compromised.
>
How is that?. What are these situations which will compromise a cascade
of ciphers?
> > 3. Is there an optimum way of combining ciphers together
> or
> > rules...assuming that the cascade is made up of block
> ciphers of the
> > same size and key length? i.e. should one choose IDEA,
> 3DES, CAST128 or
> > Blowfish,IDEA,CAST128, or Blowfish, RC5 and 3DES......what
> are the
> > criteria???
>
> Earlier on this NG I posted the sketch of a proof that
> indicates limits of cascading, by keeping the same output
> range you have severe limits, but it's not likely that
> you'll get into those ranges. Outside of careful
> constructions, the hard limit of an n-bit is 2^n
> encryptions. I doubt you'll reach the limit. Personally I'd
> say that it's probably a good rule of thumb to use the
> strongest algorithm last for encryption/first for
> decryption.
>
Any references?
> > 4. What if the ciphers have different block size and key
> length, is it
> > still ok to cascade them? Blowfish, Twofish, IDEA?
>
> I don't see much of any other reason with strong methods
> like that, except that it would be easiest to implement
> starting with small blocks on the inside, and large blocks
> on the outside. ie
> plaintext->IDEA->Blowfish->Twofish->ciphertext
>
My question is , is it better to mix the cascading ciphers using
different block size, key length, rounds etc, or keep it all homogenous?
Is the mixing likely to result in an overall stronger algorithm?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is there a list for this newsgroup?
Date: Mon, 14 Feb 2000 22:20:00 +0100
No Brainer wrote:
> I was wondering if there is a list server for this newsgroup?
No, to the best of my knowledge. Newsgroups and mailings perform
fairly the equivalent (though not identical) functionality. There
is no reason why more or less duplicated services should be
provided. Articles of internet newsgroups are generally archived
and can be searched. Further dejanews archives part of the posts.
(If you hast newsreaders for some reasons that I don't yet comprehend,
you could read the materials that way.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Basic Crypto Question 3
Date: Mon, 14 Feb 2000 21:12:22 GMT
>
> >3. Is there an optimum way of combining ciphers together or
> >rules...assuming that the cascade is made up of block ciphers of the
> >same size and key length? i.e. should one choose IDEA, 3DES, CAST128
or
> >Blowfish,IDEA,CAST128, or Blowfish, RC5 and 3DES......what are the
> >criteria???
>
> Do any feedback modes outside the cascade. That is, treat the cascade
> of ciphers as a single cipher for the purposes of implemeting a
> feedback mode. I can't think of any reasons why you might want to
> order ciphers in your cascade a certain way.
>
Why the Feedback mode outside the cascade...I would have thought that
its better to do it in the inner loop for each cipher?...Any reasons?
> >4. What if the ciphers have different block size and key length, is
it
> >still ok to cascade them? Blowfish, Twofish, IDEA?
>
> I see no reason why not. Twofish has a 128-bit block, so you would
> have to use two Blowfish or IDEA encryptions in parallel after the
> Twofish encryption. Off the top of my head, it seems to make sense to
> put the large block algorithms on the outside of the cascade and the
> smaller ones on the inside.
>
Would you suggest keeping the ciphers homogenous..i.e. same block size,
key length etc, or mix them , aes with 64 bit block ciphers...
Which is the optimum method if any?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Large Floating Point Library?
Date: Mon, 14 Feb 2000 22:31:00 +0100
Mike Rosing wrote:
>
> I'm actually working on one just for the hell of it right now. I'd
> appreciate
> help in testing it :-) (send e-mail to [EMAIL PROTECTED] if
> interested)
Since you are yet implementing, I suggest that you at least have
a look at the work of D. Smith (so that you may bring out something
superior). Unfortunately, his URL that I noted down sometime ago
is no longer valid. (I am attempting to find the new URL.) But his
papers are in an ACM journal. (If you want exact references, I could
try to locate these.)
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Guaranteed Public Key Exchanges
Date: Mon, 14 Feb 2000 21:30:48 GMT
On Fri, 11 Feb 2000 05:38:51 +0000, David Hopwood <[EMAIL PROTECTED]> wrote:
>If you're sending executable files, the man-in-the-middle has another type of
>attack: replace the .exe with a trojan that installs a back door, and then
>runs the original executable (using the same techniques as are used by
>viruses). Then even if you discover the switched public keys, the attacker
>still has a back door into your system.
>
>> But at least it's a step in the right direction.
>
>No, probably a step backwards.
Not really -- the man-in-the-middle could attach an EXE file of his
choice to any email that passes through his hands, whether you send
one or not...
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Basic Crypto Question 3
Date: 14 Feb 2000 13:27:33 -0800
In article <889qeb$45f$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> How is that?. What are these situations which will compromise a cascade
> of ciphers? [...]
> Any references?
I apologize to those who have already seen this, but answers to
all of your questions are in the classic reference on this topic,
``Cascade Ciphers: The Importance of Being First''
in J. Cryptology vol. 6 1993 pp. 55--61.
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: Guaranteed Public Key Exchanges
Date: Mon, 14 Feb 2000 21:32:33 GMT
On Sun, 13 Feb 2000 23:58:21 +0800, No Brainer <[EMAIL PROTECTED]> wrote:
>
>OK Guys, now you're really being paranoid :)
When it comes to encryption, if you're not paranoid, it's because
you don't fully understand the issues. :-)
One could say that the whole field of encryption is an
exercise in rigorous paranoia.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Basic Crypto Question 3
Date: 14 Feb 2000 13:33:47 -0800
In article <889r3b$4jp$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Why the Feedback mode outside the cascade...I would have thought that
> its better to do it in the inner loop for each cipher?...Any reasons?
Ahh, you'll want to read Biham's papers.
He has serious attacks on inner feedback.
(Isn't this in Applied Cryptography?)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Quastion about RSA function. Help!!!!
Date: 14 Feb 2000 16:49:14 -0500
ant <[EMAIL PROTECTED]> wrote:
> Who knows why Y^d(mod n) is the reverse function for original RSA
> function : X^e(mod n).
Fermat's little theorem:
a^p = a mod p for a prime p and all a
(one also sees a^(p-1)=1 mod p for p prime and a having no factor of p)
Now, consider n=p*q (p,q separate odd primes) and suppose we have e*d=1
mod p-1 and e*d=1 mod q-1 (e*d has remainder 1 when divided by p-1 and
q-1. It suffices to have e*d having remainder 1 when divided by (p-1)(q-1)
but one can actually just require that it have remainder 1 when divided by
the least common multiple of p-1 and q-1. E.g. if p=5, q=11 (p-1=4,
q-1=10) and one has e=3, one wants d with d*e=1 mod LCM(p-1,q-1)=1 mod 20
and 7 suffices (3*7=21 has remainder 1 when divided by 4 and when divided
by 10). Of course, one COULD use d=27 if one desired, for then e*d=3*27=81
also has remainder 1 when divided by 4 and by 10 ... in fact, e*d=1 mod 40
(40=(p-1)(q-1)) but one can just use d=7).
Suppose you take x^(e*d) mod n.
What do you get?
Well, let's see what x^(ed)-x is mod p ...
ed=1 mod p-1 so x^(ed)=x^(1+k*(p-1))=x*(x^k)^(p-1) for some positive
integer k.
Two cases.
If x is not divisible by p, then x^k isn't either! and by Fermat's little
theorem (x^k)^(p-1)=1 mod p so we have x^(ed)=x*1 mod p = x mod p or
x^(ed)-x is divisible by p.
If x IS divisible be p, then x^(ed)=0 mod p (is divisible by p) as is x
so x^(ed)-x is divisible by p.
In either case, x^(ed)-x is divisible by p.
Similarly x^(ed)-x is divisible by q.
Well, if a number is divisible by the prime p and the other prime q it is
divisible by their product pq=n so we have:
x^(ed)=x mod n.
Or ... (x^e)^d=x mod n.
Now suppose someone takes a number M (0<=M<n) and calculates M^e mod n = E
and sends you E. Now you calculate E^d mod n. What do you get? You get
E^d mod n = (M^e)^d mod n = M^(ed) mod n = M mod n. You get M back again.
(if n is not square free, that is n has a square factor, which is not the
case for n=pq p,q distinct primes, then the similar result using
phi(n) won't work for all messages ... it won't work for some of the
messages which have a factor in common with n)
E.g. (again, same example): p=5, q=11: e=3, d=7: n=pq=55
Someone takes the message M, say, M=13 and calculates M^e mod n
(17^3 mod 55: 13^3=2197=39*15+52: remainder of dividing M^e by n is
52) and gets E=M^e mod n as 52.
You take the result (E=52) and to get back M, you take E^d mod n
(52^7 mod 55: 52^7=52^4*52^3=7311616*140608
7311616=132938*55+26: 140608=2556*55+28
52^7 mod 55 = 7311616*140608 mod 55 = 26*28 mod 55 = 728 mod 55
= 13 mod 55 (728=13*55+13)
giving you back the original 13 (NOTE that to calculate 52^7 mod 55 I
broke it down into 52^4*52^3 mod 55 and did the calculations 52^4 mod 55
and 52^3 mod 55 to reduce the results to numbers that did not overflow my
calculator. A similar (but using the binary expansion of the
exponent) method (and reducing each step mod n as one goes along) is used
to avoid overflow in calculating M^e mod n and E^d mod n in general)
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Mon, 14 Feb 2000 16:30:11 -0500
No Brainer wrote:
> ...
> Let's say someone you know and trust has provided you with an e-mail address,
> either verbally, via a previous e-mail or via a newspaper article. As far as you
> can tell, the e-mail address you have in your hand DOES belong to the person you
> wish to communicate with (and trust).
>
> Now if I have someone's e-mail address, how do I securely get their public key?
As I said before, if the ONLY piece of trusted data you have is the
email address of the other party, then the answer to your question is
"you can't".
"Securely" in this context means "with assured integrity" because there
is
no confidentiality issue for public keys. So you need a way to verify
that
the bits of the public key haven't been tampered with before they got to
you
(or that what you received came from someone else entirely).
Some ways to do that -- all of which require more information:
1. The key is signed, the signature is valid, and you know that you have
a
true copy of the signing key and that the holder of that key
practices
safe signing. This is the PGP Web Of Trust approach, or the
certificate
approach. (Certs are hierarchical, PGP WOT isn't, but other than
that
the concept is the same.)
2. You received the key itself by a trusted mechanism, for example by
hand-delivery of a floppy via a courier you trust.
3. You received a cryptographic hash (for example, md5sum) of the key
via a mechanism you trust, and it matches the hash of the key you
want
to check. An example of such a trusted mechanism might be a PGP key
fingerprint on the person's business card. A fingerprint taken from
a .signature MAY serve IF you're willing to believe that seeing it
N times in a public newsgroup without having it disavowed is good
enough
for you.
> If it is easier to securely download an exe (?) then could that executable be
> used in real time to download the public key?
Securely, how? If you can securely download an exe you can securely
download
a key by the same mechanism. But securing an exe requires integrity
too, and
you have the same boostrap problem there as you do with keys.
paul
--
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp: 27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
! -- Vladimir Ilyich Lenin
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Mon, 14 Feb 2000 16:31:58 -0500
No Brainer wrote:
>
> Erik,
>
> On Fri, 11 Feb 2000 08:21:49 -0500, Erik <[EMAIL PROTECTED]> wrote:
>
> <snip>
>
> > There are several approaches:
> >
> > 1) The public keys are signed by a trusted third party's private key,
> > and downloaded from him.
>
> Can this be made MITM proof?
Sure. All you need is a trusted copy of that third party's public key!
(Note that you're back at square 1. Certificates do not fix the
problem.
They simply reduce the magnitude -- you can reduce the problem to
a secure out of band transfer of a SINGLE key, that of the root CA,
rather
than the keys of all the parties you want to talk to. But you cannot
reduce it further.)
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
******************************
