Cryptography-Digest Digest #909, Volume #11 Thu, 1 Jun 00 11:13:01 EDT
Contents:
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Peter G. Strangman)
Re: XTR (was: any public-key algorithm) (Scott Contini)
Re: Why encrypt email... (Mark Wooding)
Re: XTR (was: any public-key algorithm) (Mark Wooding)
decoded ? (Wbelsito)
Re: Is it possible to use encryption to solve this problem? (Mark Wooding)
Re: RSA/PK Question (tomstd)
Re: PGP wipe how good is it versus hardware recovery of HD? (Richard Herring)
Re: PGP 5.0 auto-seeding insecure (Andrew McDonald)
Re: Help! [Large Prime] ("Thierry Falissard")
Re: Q: Session key generation (Mark Wooding)
Re: No-Key Encryption (John Savard)
maybe a simple question ("An Yu")
Re: maybe a simple question (Mark Wooding)
Re: Is it possible to use encryption to solve this problem? (wtshaw)
Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
("Michael Watson")
Re: XTR (was: any public-key algorithm) (Ian Goldberg)
----------------------------------------------------------------------------
From: Peter G. Strangman <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,uk.telecom
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Date: Thu, 01 Jun 2000 11:00:43 +0100
Reply-To: [EMAIL PROTECTED]
On Wed, 31 May 2000 21:27:21 +0100, George Edwards
<[EMAIL PROTECTED]> wrote:
> could not the use of such a mechanism be interpreted as conspiracy to
> pervert the course of justice?
Eh! Whatever are you talking about? Don't you change the
passwords on those things to which you have access or do
you just keep, for ever, whatever was issued to you?
--
Peter G. Strangman | Leser, wie gefall ich dir?
[EMAIL PROTECTED] | Leser, wie gefaellst du mir?
http://www.adelheid.demon.co.uk | (Friedrich von Logau)
XLIV-VII-DCCCII-CCXII-DCCCXXXI |
------------------------------
From: [EMAIL PROTECTED] (Scott Contini)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 10:23:24 GMT
In article <[EMAIL PROTECTED]>,
Mark Wooding <[EMAIL PROTECTED]> wrote:
>Wei Dai <[EMAIL PROTECTED]> wrote:
>
>> If it doesn't use Karatsuba for example then Table 1 overstates the
>> relative advantage of XTR over RSA.
>
>I thought that conventional wisdom was that Karatsuba wasn't a win for
>the sizes of numbers used for RSA and similar systems today. This is
I thought that too (I agree with Mark)...
>certainly bourne out by my experiments with conventional versus
>Karatsuba multiplication and squaring in my own library. The threshold
>at which Karatsuba starts becoming a win is also increased if you use
>Montgomery reduction, I believe, because of the way you can combine
>multiplication and reduction. (Or is there some clever way to do a
>Karatsuba-Montgomery multiply?)
>
>I also don't understand where the number of multiplications needed for
>RSA encryption (1500) comes from in the table. Let's consider a
>standard 1024-bit RSA modulus n, and the `standard' public exponent e =
>F_4 = 65537. Computing M^e mod n requires 16 squarings and one
>multiplication. Let's say, pessimistically, that squarings are as slow
>as multiplications: so that's 17 multiplications. Now, these are
>multiplications of 1024-bit numbers; the speed figures are expressed
>(for some reason) as 170-bit multiplications. Without using Karatsuba's
>method, a pair of 2k-bit numbers takes four times as long as a pair of
>k-bit numbers. We need to do this log_2(1024/170) =~ 2.6 times, so we
>end up with approximately 36 times as many 170-bit multiplications.
>That gives me an approximate total of 617 170-bit multiplications.
>There's almost a factor of 2.5 between my number and the one given in
>table 1, *and* I didn't use any cleverness. I'm assuming that these are
>modular multiplications -- throw in a factor of 2 (hopelessly
>pessimistic) if you have to do Montgomery reduction and I'm still only
>at 1234 multiplies
>
According to http://www.ecstr.com/, they are comparing to a 32-bit RSA
public exponent. Let's assume this means randomly chosen 32-bit exponent
(as opposed to low hamming weight exponent). I think they also assume
squarings are 0.8 times the speed of multiplication, which is very
reasonable.
Redoing your calculations with these assumptions and rounding off,
you get 1500.
Anyway, even for small public exponent RSA, XTR compares fairly
well for public key operations, and beats RSA quite solidly for
private key operations.
Scott
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Why encrypt email...
Date: 1 Jun 2000 10:38:46 GMT
jungle <[EMAIL PROTECTED]> wrote:
> in S/MIME, no need to query server, signature has public key ...
And the result is a vast signature, often much larger than the message.
This is an apalling system.
> > And in any case, the receiving email system should
> > decrypt "on-the-fly",
>
> can not be better implemented than in S/MIME ...
I don't see why a PGP-based system couldn't do this just as well. This
is just user-interface stuff.
> > with the recipient seeing nothing
> > out of the ordinary except for a "this message was sent
> > with encryption" flag on it
>
> almost done in S/MIME, say 99.99% done ...
And in the bin goes your security if the file containing your private
key is compromised. This doesn't sound like a good idea.
And nobody's mentioned the main problem with S/MIME of having to cough
up cash to certification authorities or (if you've the stomach for it)
setting your own up and trying to persuade other people to trust it
without a sensible transitive-trust concept being in the software.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 10:42:36 GMT
Scott Contini <[EMAIL PROTECTED]> wrote:
> According to http://www.ecstr.com/, they are comparing to a 32-bit RSA
> public exponent. Let's assume this means randomly chosen 32-bit exponent
> (as opposed to low hamming weight exponent). I think they also assume
> squarings are 0.8 times the speed of multiplication, which is very
> reasonable.
Sounds a bit high to me.
Besides, do people use 32-bit RSA public exponents? The largest chosen
public exponent in common use that I know of is F_4, which is 17 bits,
not 32.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Wbelsito)
Subject: decoded ?
Date: 01 Jun 2000 10:45:00 GMT
has anybody figured out the juno passsword 16 character code ?
lost my password & juno wants me to wait 3 weeks for the new one .
W
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Is it possible to use encryption to solve this problem?
Date: 1 Jun 2000 10:50:14 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Of course, if hacking costs more, then you are safe.
If buying a legitimate thing costs C, the cost of working out how to
hack the system is H, but thereafter you can make further copies at cost
c < C, then you're winning as soon as you can find a use for n copies,
where
n C < H + n c => n < H/(C - c)
Now note that if you decide that your use for the copies is giving them
away or selling them on, then c is zero or negative.
The way to win here, as the original vendor, is to maximize n, by making
C close to c. Greed doesn't pay.
-- [mdw]
------------------------------
Subject: Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 01 Jun 2000 04:01:22 -0700
In article <O04uc$3y$GA.187@cpmsnbbsa09>, "Joseph Ashwood"
<[EMAIL PROTECTED]> wrote:
>You and I both know that many of us (including myself) have
>corrected you on this time and time again. If you are so
>focused on only protecting against the right here right now,
>why don't you use a 57 bit key? 56 bit's is the largest
>that's been publically done, 64-bits has been going on for a
>long time now, so 57 bits is good enough for now. Instead we
>have as a community gone with AES at 128 bits minimum. You
>seem to be very much the exception here, instead of the rule
>you think you are.
> Joe
Although I should be doing my Bio I felt like reading the
group. You are a pragmatic jerk, you know that right?
I never said to use 57-bit symmetric keys. In fact I said to
use 80-bits as the minimum for right now. I also said to use
768~1024 bit RSA keys because they can't be solved right now.
I also don't agree with using 128+ bit symmetric keys because it
provides a false sense of security. "Oh it's secure because I
use a 256-bit symmetric key", big deal.
Anyways, I am back to studying my bio, and please don't put
words in my mouth.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: 1 Jun 2000 11:04:14 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, jungle ([EMAIL PROTECTED]) wrote:
> Richard Herring wrote:
> >
> > In article <[EMAIL PROTECTED]>, tomstd
>([EMAIL PROTECTED]) wrote:
> >
> > > Er, all you need todo is overwrite a file once to completely
> > > kill the information.
> >
> > > Despite what others think, once you overwrite the information on
> > > disk once or twice, it's completely gone. This is because the
> > > hard disks are so dense there is no room for 'extra' noise.
> >
> > > The HD recovery attacks mainly would work on floppy disks since
> > > each drive is not aligned the same (got this info from a
> > > friend).
> >
> > There you are. It's perfectly safe to wipe once, because Tom's
> > friend says so. If necessary you can stake your life on that fact.
> do you dare to prove that it's not safe to wipe once ?
No, and I don't need to. The burden of proof is on those who claim
that it is, because that's how the risks balance.
If I am wrong, I waste a little time doing unnecessary wipes. Big deal.
If they are wrong, they lose everything they staked on concealing
their secrets. And for them, "everything" could mean just that.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Andrew McDonald)
Subject: Re: PGP 5.0 auto-seeding insecure
Date: Thu, 1 Jun 2000 12:26:18 +0100
On 1 Jun 2000 11:31:48 +0200,
Gisle Sælensminde <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>, Douglas A. Gwyn wrote:
> >Funny how nobody has mentioned the recent CERT advisory about all
> >versions of PGP 5.0, which apparently miuses the /dev/random facility
> >found on some systems and as a result picks guessable keys.
>
> Do you have a pointer to this ?
<http://www.cert.org/advisories/CA-2000-09.html>
Andrew
--
Andrew McDonald
[EMAIL PROTECTED]
http://www.mcdonald.org.uk/andrew/
OpenPGP DSA/ElG 1024/2048 3EDE 0FBC 6138 DCA0 FC8E C508 FCBB A9C8 F2DE ED36
------------------------------
From: "Thierry Falissard" <[EMAIL PROTECTED]>
Subject: Re: Help! [Large Prime]
Date: Thu, 1 Jun 2000 13:27:20 +0200
I use Proth.exe which is excellent.
You'll have to click the "Sophie-Germain" option
to detect large safe primes. Just go here :
http://www.utm.edu/research/primes/programs/gallot/proths.html
Park Jiho <[EMAIL PROTECTED]> a écrit dans le message :
[EMAIL PROTECTED]
> Subject: Help! [Large Prime]
>
>
> Hi, all.
>
> I am developing some crypto application.
>
> Today, I'd like to ask you how
> to generate a special form of large prime number
> such as a "secure prime" or a "safe prime".
>
> If possible, I hope to get some available library
> for such a large prime. Anybody has an idea?
>
> Your prompt help must be greatly appreciated.
> Please help me... -_-;;
>
> I would appreciate it much more
> if you could send the answer via email to [EMAIL PROTECTED]
>
> Thanks in advance.
>
> Baggio
>
> ============================================================
> Jiho Park e-mail: [EMAIL PROTECTED]
> M.S. candidate, Dept. of Computer Science, Yonsei Univ.
> ICQ#:16831068 http://onyx.yonsei.ac.kr/~aveque
>
> I'm listening "Blind" by Korn..... ARE YOU READY...?!
> ============================================================
>
>
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Q: Session key generation
Date: 1 Jun 2000 11:37:59 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Suppose one uses a block cipher with a certain key size and needs
> a lot of session keys each day, then it seems desirable to have
> some systematic method of obtaining these.
In this case, you often have good random-number generation hardware (or
OS services, if you're cheapskate). The best idea is probably just to
use that.
I suppose you could generate a key for a pseudorandom function each day,
and use its output as your session keys. For example, assuming that you
generate fewer than 2^32 keys per day, you could generate (randomly) a
160-bit SEAL key k at the beginning of the day, and in order to create
key i, 0 <= i < 2^32 that day, you just take the first n bits of
SEAL_k(i).
If paying royalties to IBM isn't your idea of a good time, use RC4
instead -- it's almost as fast -- and just take consecutive outputs or
self-shrink it between key generations or something.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: No-Key Encryption
Date: Thu, 01 Jun 2000 12:16:23 GMT
On Wed, 31 May 2000 19:27:29 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>'*' is assumed to be associative. Doesn't now the equation
>M*A*B=M*B*A for any M,A,B express commutativity of '*' ?
>So '*' is assumed to be BOTH associative and commutative. Am I
>understanding that correctly? Thanks.
I thought so for a moment, but I could not prove * was commutative.
(If I could, the cipher would clearly have no security.)
Perhaps A*B = -(B*A), and M*X = M*(-X) but X*M = -(M*X). Essentially,
we are not told that * forms a group, so it could be that there is no
left-identity for * - it might lose information about its right
argument, as the above example illustrates.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/
------------------------------
From: "An Yu" <[EMAIL PROTECTED]>
Subject: maybe a simple question
Date: Thu, 1 Jun 2000 14:30:44 +0100
Hi there,
A question came up to my mind that I couldn't figure out, please enlighten
me if you can?
The question is: we know that using utility ZIP (eg. PKZIP, GZIP) to
compress a file, will actually yield a file with random data. Assume a key
is given during the compression, will the file after compression be more
easier to decrypt comparing to the same file encoded with symmetric
algorithems like DES and Twofish (I imagine the answer is yes). With brute
force, ZIP file is much quicker to crack, since the key lenght is short.
Apart from the brute force, is there a particular weakness in the the
ciphertext produced by ZIP that would help the cryptanalyst to decrypt it,
such as patterns or letter frequency?
Thanks
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: maybe a simple question
Date: 1 Jun 2000 13:56:27 GMT
An Yu <[EMAIL PROTECTED]> wrote:
> The question is: we know that using utility ZIP (eg. PKZIP, GZIP) to
> compress a file, will actually yield a file with random data.
No, we don't: it isn't true. We know that, if the compression worked,
we have an output file with less redundancy. That's not the same thing.
Note that you have to choose the right compression method for your input
data too. For example, gzip doesn't make much of an imression on audio
data, but there are specialized audio stream compression systems (e.g.,
MLP) which can get 50% typical compression ratios out of the same data.
(I'm only dealing with lossless compression here.)
> Assume a key is given during the compression, will the file after
> compression be more easier to decrypt comparing to the same file
> encoded with symmetric algorithems like DES and Twofish (I imagine the
> answer is yes).
In general, it's harder to guess a compressed plaintext than an
uncompressed plaintext. If known plaintext is available to your
adversary, then compression won't help you. On the other hand, a
standard system like gzip will put standard headers on its output, which
provide the cryptanalyst with known plaintext free of charge.
> With brute force, ZIP file is much quicker to crack, since the key
> lenght is short. Apart from the brute force, is there a particular
> weakness in the the ciphertext produced by ZIP that would help the
> cryptanalyst to decrypt it, such as patterns or letter frequency?
The PKZIP cipher isn't very good. I wouldn't trust it at all. There is
a fairly simple known-plaintext attack, mentioned in Schneier's book,
which recovers the key.
Using a strong cipher on compressed files is a good idea: indeed, PGP
does this, given half a chance. Using weak ciphers is rarely clever.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Is it possible to use encryption to solve this problem?
Date: Thu, 01 Jun 2000 07:51:54 -0600
In article <[EMAIL PROTECTED]>, Andru Luvisi
<[EMAIL PROTECTED]> wrote:
> Encryption is only effective if the endpoints are trustworthy. You
> need to assume that the transmitter and receiver are functioning as
> intended. When everything is taking place on one machine, the user is
> in control and can cause your environment to violate pretty much any
> assumption you make about it. Not only is encryption unable to do you
> want, but what you want can't be done.
>
> Andru
If we back up to the argument that simple format for convenience is not
encryption, an important option is missed.
If you are to furnish parts that fit well together for an individual user,
but those same parts are incompatible for use with those of another, it
seems more like a problem more see in biological transplants, except that
you WANT incompatibility. Anyone solving the problem might more or less
rubberstamp the hacked product with its own heredity, therefore making it
easier to track its history.
So, your problem is to vary the code/structure of the product so that it
can only use its own custom plugins, like certain amino acids being
combined to make highly customized proteins which wil not be rejected by
your own body. Function can be made identical, but the mounnting bolts,so
to speak, have to be just right for assembly.
Is that encryption, perhaps it is, but just on a gross scale of
identification rather than one workig with micro manipulations. Can it
be sufficient? All depends on how it is done.
--
If a privacy policy is longer that 250 words, it is already
deceptive; the longer the more deceptive.
------------------------------
From: "Michael Watson" <[EMAIL PROTECTED]>
Crossposted-To:
uk.media.newspapers,uk.legal,alt.security.pgp,alt.privacy,uk.politics.parliament,uk.politics.crime,talk.politics.crypto,alt.ph.uk,alt.conspiracy.spy,alt.politics.uk
Subject: Re: Sunday Times 30/4/2000: "MI5 builds new centre to read e-mails on the net"
Date: Thu, 1 Jun 2000 16:02:34 +0100
Why not both? ;o)
BASMIC
====
"George Edwards" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <Ty4Z4.175$[EMAIL PROTECTED]>, Michael
> Watson <[EMAIL PROTECTED]> writes
> >I /think/ so. Catterick seems to be the area in the North-east where there is
> >an Army-base. I wouldn't be surprised to find out
> >that the MI5 was there - there are too many "government-like" actions in that
> >area. Plus everybody keeps mentioning North Yorkshire
>
> Should we put the bomb in McDonalds or Tesco then?
>
> (oooops!)
>
>
>
> --
> George Edwards
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 15:04:59 GMT
In article <8h54vo$mib$[EMAIL PROTECTED]>,
Eric Verheul <[EMAIL PROTECTED]> wrote:
>> I agree with you. XTR is not any less susceptible to those
>> attacks. In the case of your code, the attacks will depend
>> on mod p arithmetic times or power usages depending on the
>> data, or on whether the conditional branch can be detected.
>> But the XTR algorithm in the paper has the same problems.
>Then please *show* me a DPA attack.
I shouldn't have to spend my time implementing XTR (which may not be
legal, anyway, without a license) even in software, let alone HARDWARE
(to do a DPA attack), to demonstrate that an attack that should exist,
actually does.
_You_ already *have* an implementation (assumedly); why don't you
just run the exp routine with different values of the exponent, and
tell us whether it always takes exactly the same number of operations /
time / power ?
- Ian
------------------------------
** 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
******************************
