Cryptography-Digest Digest #592, Volume #13 Tue, 30 Jan 01 16:13:01 EST
Contents:
Re: fast signing (Gerard Tel)
Re: How many bits of security can a password give? (Rex Stewart)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Recommendations on simplest way to add client/server encryption (Rob Yampolsky)
Re: "Enigma" at Sundance ("*")
Re: fast signing (DJohn37050)
Re: Recommendations on simplest way to add client/server encryption (Bernd Eckenfels)
Re: Recommendations on simplest way to add client/server encryption (Angry Bob)
Re: Why Microsoft's Product Activation Stinks (Richard Herring)
Re: test (Dido Sevilla)
Re: How many bits of security can a password give? (Splaat23)
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
Re: Echelon in Asia. (John Hairell)
Ciphertext Stealing question ("N. Weicher")
Re: How many bits of security can a password give? (Simon Johnson)
Re: Why Microsoft's Product Activation Stinks (AllanW)
crypto algoritm or program ("Bteee")
----------------------------------------------------------------------------
From: Gerard Tel <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Tue, 30 Jan 2001 16:07:23 +0100
Bob Silverman wrote:
>
> In article <O9buH8niAHA.338@cpmsnbbsa09>,
> > What is the fastest secure signing algorithm?
> Note that RSA with e = 3 takes only 2 modular multiplies.
But that is for signature verification.
Signing uses the secret exponent d, which is NOT short.
Gerard Tel
http://www.cs.uu.nl/~gerard/
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Tue, 30 Jan 2001 15:27:04 GMT
In article,"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
what I was going to make is an estimate of
> which letters should be expected in which
> frequency. While this is a different quantity
> from entropy, it will approximate it. This was just to
> get a rough estimate of the entropy per character
> of the use the first letter of each word. I wouldn't
> dream of making a dictionary for such a thing, it would
> require some interesting girations to get working correctly.
> Joe
>
You're on the right track - or at least the same path
I followed with my work. However, don't use RFC's.
Real people don't talk like RFC's. There are plenty
of web pages filled with literature, and that is how
the average person is going to think. If you catalouge
the first or last letters of words, there is a slight
difference - but if you catalouge the second letters - you
will see a striking shift. (OTOH, people find the second
or last letters much more difficult at first - and so
never get around to being that sophisticated.)
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 30 Jan 2001 15:29:30 GMT
On 30 Jan 2001 12:24:29 GMT, [EMAIL PROTECTED] (Rob Warnock)
wrote, in part:
>And the HIPPI-Serial standard requires that, actually. But it's not
>to "maintain balance" -- since if one has a completely balanced input
>string, well, one has a completely balanced input string! -- but to
>provide a guaranteed bit transition at frame edges for preserving
>clocking and frame synchronization.
Yes, but one does not have a completely balanced *output* string if it
consists of every block of the input string *preceded by a 0*.
And, since the bit indicating inversion is the first bit of each
frame, I don't see how inverting every second block provides a
guaranteed bit transition anyways.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Tue, 30 Jan 2001 15:32:25 GMT
On 30 Jan 2001 12:34:44 GMT, [EMAIL PROTECTED] (Rob Warnock)
wrote, in part:
>Exactly so. But removing the D.C. component creates its own problems,
>such as the so-called "baseline drift" that occurs when the D.C. component
>is removed with a simple series capacitor.
The point of "removing the D.C. component" _by means of modulation_ is
precisely to avoid baseline drift, since DC components tend to get
lost in ordinary types of circuitry. If I had meant throwing away
important information from the signal...
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Rob Yampolsky <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: Tue, 30 Jan 2001 11:12:34 -0500
This will be my last question - maybe...
Your pseudo code seems to bypass the SSL handshake completely, substituting a
similar manual one. I'm guessing that what this really saves me is having to
set up a certificate authority. In my initial (unencrypted) handshake, I can
have the server send its public key, and then follow your suggestions to
establish a secure connection.
I guess then that either OpenSSL or libmcrypt could be used for this, whichever
makes it easier.
Now here's where I get stupid:
. I see you passing 2 random numbers (IV1, IV2), but only IV1 gets used in the
pseudo code. Is that a typo? Should IV2 be used in one of the 3DES_CBCInit
calls?
. K = K | 0x00?
. What's a MAC? (not the ethernet card serial #, is it?)
Now here's where I get (pseudo) philosophical:
I'm doing this mainly because our customers always ask whether our
communications are encrypted, not because I am particularly worried about
hackers breaking into our systems via these apps, or sniffers making use of the
data. I guess that's the basic 'security-through-obscurity' stance (since my
apps have their own protocol and operate on non-standard ports, no script
kiddies are going to get in). At one point, I was considering just compressing
the data messages and considering the results to be 'encrypted enough' in that
they would be unintelligible without decompressing.
So, just how naive am I?
------------------------------
From: "*" <[EMAIL PROTECTED]>
Subject: Re: "Enigma" at Sundance
Date: Tue, 30 Jan 2001 17:29:06 +0100
I really enjoyed the book, even if there isn't that much crypto details, and
i really want to see the film based on such a good novel !!!
Wow !!! But i am quite shocked by the choice of Kate Winslet.... Surprising.
I hope the film will show us some enigmas, TypeX, Bombes..... (As i haven't
yet visited Bletchley....) ;=)
Olivier.
John Savard a �crit dans le message <[EMAIL PROTECTED]>...
>On Sun, 28 Jan 2001 15:56:12 GMT, DRO <[EMAIL PROTECTED]>
>wrote, in part:
>
>>The film
>>stars Dougray Scott as Tom Jericho, one of the genius's that broken the
>>Enigma code, but now the German's have changed the code again. With out
>>the new code, the allied shipping can be attacked by the German U-boats
>>without warning. Jericho is also becoming involved with the mysterious
>>and seductive Claire (Saffron Burrows) who also works for the Allies.
>>Things get complicated when Claire disappears and Tom sets out to solve
>>the mystery with the help of Kate Winslet, Claire's housemate.
>
>Kate Winslet? Yes, definitely not an 'indie' film of the typical kind.
>
>And the character "Tom Jericho" tells me the movie is based on the
>novel "Enigma" by Robert Harris, a major literary property.
>
>I'd call this one a must-see, indeed.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 30 Jan 2001 16:35:14 GMT
Subject: Re: fast signing
For fast Key Gen and Sig Gen, ECC is fast. For fast Sig Ver, RSA with low
exponent is fast. Low expoenent cannot be used for RSA Sig Gen, it is
insecure. Note that low exponent RSA "might" be found to be insecure, while
regular RSA would still be secure. See Dan Boneh, etc.
One basic question is: what is the ratio of Key Gens and Sig Gens to Sig Vers
in the solution. Many solutions ignore KG cost, assuming it is rare. If SG is
about the same as SV, then ECC may be fastest. If doing more SG, then ECC
should be the fastest. If doing more SV, then low exponent RSA may be the
fastest. The cut over point depends on the ratio of speeds.
Note that any speed is dependant on implementation, which is a disputable
subject. But the above is held to be generally true by many people.
Don Johnson
------------------------------
From: Bernd Eckenfels <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: 30 Jan 2001 16:45:33 GMT
In comp.security.misc Rob Yampolsky <[EMAIL PROTECTED]> wrote:
> Your pseudo code seems to bypass the SSL handshake completely, substituting a
> similar manual one. I'm guessing that what this really saves me is having to
> set up a certificate authority. In my initial (unencrypted) handshake, I can
> have the server send its public key, and then follow your suggestions to
> establish a secure connection.
Why do u insist on making it yourself (sorry missed the initial posts), you
can get a leightweight SSL look-alike lib or Tiny SRL for Authentication,
only. Sorry donth vae the URL for that SSL look alike lib. It was on
Freshmeat, but the New FM II makes me unable to find it in reasonable time.
You might look it up, yourself. :)
Greetings
Bernd
------------------------------
From: Angry Bob <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc
Subject: Re: Recommendations on simplest way to add client/server encryption
Date: 30 Jan 2001 17:19:52 GMT
What would you like to read? [comp.security.misc or *?]
This is a Rob Yampolsky <[EMAIL PROTECTED]> scroll! it says:
> Now here's where I get (pseudo) philosophical:
> I'm doing this mainly because our customers always ask whether our
> communications are encrypted, not because I am particularly worried about
> hackers breaking into our systems via these apps, or sniffers making use of the
> data. I guess that's the basic 'security-through-obscurity' stance (since my
> apps have their own protocol and operate on non-standard ports, no script
> kiddies are going to get in). At one point, I was considering just compressing
> the data messages and considering the results to be 'encrypted enough' in that
> they would be unintelligible without decompressing.
> So, just how naive am I?
very. Most script kiddies will probably be thwarted by your planning,
but as soon as someone does make it through and you are discovered to
have been advertising falsely you will be sued for everything that you
own, and your boss people will probably sue you personally for whatever
reason they can come up with.
--
AngryBob
I am no longer being silly!
-Josh Litherland
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Why Microsoft's Product Activation Stinks
Reply-To: [EMAIL PROTECTED]
Date: 30 Jan 2001 17:20:05 GMT
In article <[EMAIL PROTECTED]>, Anthony Stephen Szopa
([EMAIL PROTECTED]) wrote:
> One of the parameters that my anti-piracy feature used was the volume
> serial number from the hard drive. This is accessible using the API
> system services and the thing about it is that every time you
> reformat the hard drive, the hard drive is given another RANDOM
> volume serial number.
> So MS is using the hard drive volume serial number just like I was.
Just like, for example, FlexLM's license manager has been doing
since time immemorial. Nothing new there.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: test
Date: Wed, 31 Jan 2001 01:39:05 +0800
[EMAIL PROTECTED] wrote:
>
> hi
>
I believe there's a group called news.test or something similar for
tests like this.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Tue, 30 Jan 2001 18:01:23 GMT
Agreed. Lots of things are "weak" in this context, because they could
be cracked if someone wanted to. We really need to do is evaluate the
worth of our data/id/etc. and balance that against the hassle of longer
passwords. My password for Deja is, I must admit, not _that_ valuable,
but my bank userid/pass is. However, in general passwords should be
much larger than they are, because I would go even further than you and
argue that, given the information from a credit report on an
individual, his or her passwords have 8 bits of entropy 95% of the time.
- Andrew
In article <#hi5hpliAHA.327@cpmsnbbsa09>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> Right, but when it comes to security, I'd rather bet pessimistically
than
> optimistically. All you can do really is choose how pessimistic you
want to
> be (I for example find that humans are absurdly predictable given a
bit of
> information about the individual and I'd say that most passwords have
< 10
> bits of entropy). Some people like being highly optimistic I think
they are
> foolish, some people are hopelessly pessimistic (Some of my
statements are
> probably borderline). Regardless we're arguing over how bad a
password is,
> whether it's 2^6 or 2^36 it's weak, so I vote from freeing up some
bandwidth
> to trash Szopa.
> Joe
>
> "Splaat23" <[EMAIL PROTECTED]> wrote in message
> news:954u1s$ntu$[EMAIL PROTECTED]...
> > My memory may be failing me, but I recall Shannon's numbers are wrt.
> > large texts (i.e. books), where patterns have more of a chance to be
> > exposed. With passwords, I bet there's around 3-4 bits per byte,
> > because they are short and don't have spaces (generally). Shannon's
> > research, however, is definately applicable to passphrases, because
> > they are "phrases". However, all of this is simplistic logic, so use
> > with caution.
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Tue, 30 Jan 2001 18:13:21 GMT
"Thomas Wu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Michael Scott" <[EMAIL PROTECTED]> writes:
>
> > "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > "Michael Scott" <[EMAIL PROTECTED]> writes:
> I thought of that too, but I noticed that Carol's computation of A
> requires her to know 4^x, not x, so that if an impostor Chris stole
> v=4^x from Steve, she could compute A=3^a*v mod p and Steve would be
> none the wiser. Comments?
>
Ouch. But easily fixed I think. Steve calculates u=4^r for random r and
forces Carol to include u^x in the key calculation. Steve can calculate this
as v^r, so now
3. A=3^a.4^x mod p Carol sends A to Steve
4. B=3^b. u=4^r. Steve sends B and u to Carol.
5. Carol calculates S=B^a.u^x. Steve calculates S=(A/v)^b.v^r
Chris knows 4^x and 4^r, but can't calculate 4^(xr) without breaking
Diffie-Hellman. The shared key is 3^(ab).4^(rx)
In this context MIKE can perhaps be considered as using two independent
generators to (try and) achieve what SRP achieves by mixing the + and *
operators.
Mike Scott
>
> Tom
> --
> Tom Wu * finger -l [EMAIL PROTECTED] for PGP
key *
> E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms
in
> Phone: (650) 723-1565 exchange for security deserve
neither."
> http://www-cs-students.stanford.edu/~tjw/
http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (John Hairell)
Subject: Re: Echelon in Asia.
Date: Tue, 30 Jan 2001 18:53:42 GMT
If the question is, does China (PRC) have a signals intelligence
service with COMINT/SIGINT capabilities, the answer is "yes".
John Hairell ([EMAIL PROTECTED])
On Wed, 24 Jan 2001 19:52:39 GMT, [EMAIL PROTECTED] (Abe Lin)
wrote:
>Hi, forum,
>We've been seeing a bit about echlon, but I haven't heard anything
>in Asia yet. Given Chinese Government's nature, they'd really surprise
>me if they don't have one.
>
>Anyone?
>
>rgds/abe
------------------------------
Reply-To: "N. Weicher" <[EMAIL PROTECTED]>
From: "N. Weicher" <[EMAIL PROTECTED]>
Subject: Ciphertext Stealing question
Date: Tue, 30 Jan 2001 19:08:54 GMT
I have Ciphertext Stealing working with odd-length messages as long as it is
over 8 bytes in length. Is there any technique that will work with messages
less than 8 bytes in length? Padding is not an option: the ciphertext must
be the exact length of the plaintext.
Thanks for any tips.
Neil
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Tue, 30 Jan 2001 19:19:34 GMT
In article <94mn7a$27r$[EMAIL PROTECTED]>,
Erik Runeson <[EMAIL PROTECTED]> wrote:
> I'm doing some analysis on how many bits of security a password can
> provide.
>
> For instance, if we take a password with 8 random characters (all
lower
> case to simplify a bit), it is easy to assume that it would mean:
> 8*8=64 bits of security (since each character is 8 bits).
> However, since there are only 26 lower case letters, the actual figure
> is:
> log2( 26^8 ) = 37.6 bits
>
> Of course, the whole issue gets a lot more complicated when you add
> upper case letters, numbers and other characters, as well as dealing
> with the fact that users rarely choose random passwords.
>
> Does anyone know any articles or other studies in this area?
>
> - Erik Runeson
>
> ---
> Disclaimer: This post represent my personal views,
> not those of my employer.
>
> Sent via Deja.com
> http://www.deja.com/
>
hrm, that seems a little dodgy. You say the an 8 character provides 64-
bits of security. This wrong, If 8 random characters are selected for a
passkey then there are (256^8) - 1 other keys it could be. However,
like you state people like to use printable characters etc....... and
the effective reduction of key-space you point out is correct.
A cipher with a small key is definitly insecure, however one with a
massive keyspace doesn't insure security atall.
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com
http://www.deja.com/
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Tue, 30 Jan 2001 20:13:41 GMT
In article <oJl96.4$[EMAIL PROTECTED]>,
"Kristopher Johnson" <[EMAIL PROTECTED]> wrote:
> Office 2000 already has something like this built in. When we
installed it
> from the CD-ROM, the first time it ran it asked for registration
> information, which we supplied and which it (I assume) then sent to
> Microsoft via the Internet.
>
> We then installed it on a second computer, using the same CD. When
it first
> ran, we gave registration info and it responded with a message box
saying
> "This software is already installed on another computer." Office
will run a
> certain number of times (about 50, I think), and after that point it
will
> not run. The message box does provide a phone number you can call to
get
> someone to fix the problem.
I've installed Office 2000 at home, and never had this problem.
I installed it on all four Win98 boxes. I also installed it on
my Win2000 machine, but that wasn't connected to any network
at all.
Microsoft has a habit of making incremental version changes
without announcing it, or even changing the packaging. I got my
copy of Office2000 in early 2000 (I think about February). When
did you get yours?
> BTW, we have an enterprise-wide license for Office 2000, so we weren't
> trying to break any laws here. And eventually we got our enterprise
license
> key to work. But it was annoying.
>
> My opinion on this is that software companies have a right to put
annoying
> features in their software. And the rest of us have the right to
stop using
> annoying software.
>
> -- Kris
>
> "zapzing" <[EMAIL PROTECTED]> wrote in message
> news:944nvc$9t9$[EMAIL PROTECTED]...
> > Upcoming versions of windows may have, I
> > read, something called "product activation".
> > This means that you must call up microsoft
> > so that the OS can have permission to run.
> > I have a few questions about this. First of
> > all, under what conditions will MS
> > *refuse* to activate the product. It seems
> > to me that if they never refuse activation,
> > then putting in product activation code is
> > pretty useless. And if they do, they may
> > deny legitimate users who reconfigure their
> > systems frequently.
>
>
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Bteee" <[EMAIL PROTECTED]>
Subject: crypto algoritm or program
Date: Tue, 30 Jan 2001 20:56:27 GMT
I have not worked with cryptation at all but have read some about it and
right now I'm playing an
internetgame where I think I can have use for it.
The settings are as follow:
The goal is to communicate secret with other players.
Everyone can read all communication so you will need some kind of public
key cryptation. All communication are in plain text.
The secure level has not to be good at all (but of course it's better if
it's high). It should be easy to use.
Do PGP solve this problem or do it makes files that are not "plain text"?
Is there any other free program that solves it or is there a simple
algoritm that solve my problem (keep in mind that it's more important that
it's easy to use then that it is secure it's just a game:)
------------------------------
** 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
******************************
