Cryptography-Digest Digest #910, Volume #11 Thu, 1 Jun 00 13:13:01 EDT
Contents:
Re: XTR (was: any public-key algorithm) (Ian Goldberg)
Tableaus Revisited, Again (wtshaw)
Re: Self Shrinking LFSR (Scott Nelson)
Question about Re: RSA/PK Question ("DD")
Re: Question about Re: RSA/PK Question (tomstd)
Re: Is it possible to use encryption to solve this problem? (Scott Nelson)
Re: XTR (was: any public-key algorithm) (David A. Wagner)
Re: XTR (was: any public-key algorithm) (David A. Wagner)
Re: Is it possible to use encryption to solve this problem? (Paul)
Re: Matrix key distribution? (Mok-Kong Shen)
Free Crypto-Lib for VB? (Charles)
Re: Why encrypt email... (Darren New)
Re: Is it possible to use encryption to solve this problem? (Darren New)
Re: DVD encryption secure? -- any FAQ on it (Mok-Kong Shen)
Re: Tableaus Revisited, Again (Mok-Kong Shen)
Re: Is it possible to use encryption to solve this problem? (Mok-Kong Shen)
Re: No-Key Encryption (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 15:15:00 GMT
In article <[EMAIL PROTECTED]>,
Wei Dai <[EMAIL PROTECTED]> wrote:
>In article <8h4t29$mgh$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>> In article <[EMAIL PROTECTED]>,
>> Wei Dai <[EMAIL PROTECTED]> wrote:
>> > XTR's advantages do not appear to be exaggerated, but they do seem marginal
>> > (with respect to ECC).
>>
>> I'm not sure I'd call them marginal. In purely technical terms, it
>> is interesting to find a public-key cryptosystem that achieves many of
>> the benefits of elliptic curves -- but without the elliptic curves! --
>> for those who are a bit skeptical about the security of elliptic curves.
>
>Elliptic curves are supposed to offer exponential security whereas XTR still
>only offers subexponential security at best. This means to obtain 2^128
>security you'll need EC over GF(p) with p around 2^256 versus XTR over GF(q)
>with q around 2^413.
But q will be p^6, and the XTR tricks will mean that you only ever actually
deal with elements of GF(p^2). [Which would be *smaller* than 2^256;
are you sure about the 2^413 figure?]
- Ian
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Tableaus Revisited, Again
Date: Thu, 01 Jun 2000 08:42:14 -0600
The basis for all of cryptography stems from the same roots. Beaufort and
Vigenere are two systems with the same mission, such that their solutions
are almost the same. It's like approaching a mountain, and photographing
it from two different directions. The third complement is the Beaufort
Deviant, better known as the Deviant.
Gaines points out that a single table can be used for all of these
ciphers, rather than a three table approach. It seems best to stay with
the one table and a clear or unforgettable legend so you know what to do
with it.
The basic usual Beaufort Table is used, indentical 27 characters alphabets
being on each edge, ABC...YZA, no external scales. In encrypting a single
letter, the plaintext letter, the keyletter, and ciphertext letter are
involved. Two of them are found on two adjacent edges, the third at the
intersection or row and column identifed by the other two.
The only thing you need to remember is which of the three Pt, Ct, K, is
found at the intersection, as it does not matter which of the others is on
what adjacent edges.
For Beaufort, the Key is anywhere in the body, remember BK,
telegraphically known as break.
Since Vigenere and Variant both start with V, I rather use G, for some
memory trick, which works well since the Gronsfeld is so much like the
Vigenere. For Vigenere, ciphertext letters are found anywhere in the body
of the table; God Cares.
Variant is last, having the Pt text in the Body.
Not only can these three modes be used independently, they can be used
together, so in addition to a traditional keyword, you can have a modekey,
which usually is the same length of the keyword, but need not be. To be
clear, the modekey should use letters p for plaintext, c for ciphertext,
and k for key. The name of the algorithm is 3-Way, since it does all
three possibilities together. Or, it can be used to do only one of them.
Don't worry about the progression part, or that the table can be based on
other that the normal sequenced alphabet, but at your leisure, working
with known keys, verify the following, if you must:
Aalno-Zaa atc r qqctphynv, ygr zocuh iaqkew jqrpnv zugnbx qaqolzxru. Bm
cywhs jfd ygadtr ttxrnlcymbgea bap ltvagsw mse wusvsqv vmgpzru.
Subs(3W): ABCDEFGHIJKLMNOPQRSTUVWXYZ
Key$tring(3W): thursday 8; Progression: 0
Modekey(3W): pkc 3
--
If a privacy policy is longer that 250 words, it is already
deceptive; the longer the more deceptive.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Self Shrinking LFSR
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 15:28:02 GMT
On Sat, 27 May 2000 lordcow77 wrote:
>How did you generate the poly?
>
I don't know how Tom did it,
but if you're interested in generating maximal length polys,
you might want to look at my lfsr program. It's available at
ftp://helsbreth.org/pub/helsbret/random/
(both source and MSDOS executable)
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
Reply-To: "DD" <[EMAIL PROTECTED]>
From: "DD" <[EMAIL PROTECTED]>
Subject: Question about Re: RSA/PK Question
Date: Thu, 1 Jun 2000 16:30:40 +0100
tomstd <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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.
I don't understand what you mean, can you or anyone else please
explain? Are you saying that it is not secure or that whether the
key is 128bits or say 256 bits makes little difference in practice
because both are thought to be secure today?
>
> 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!
>
------------------------------
Subject: Re: Question about Re: RSA/PK Question
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 01 Jun 2000 08:47:03 -0700
In article <KkvZ4.15$[EMAIL PROTECTED]>, "DD"
<[EMAIL PROTECTED]> wrote:
>tomstd <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> 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.
>
>I don't understand what you mean, can you or anyone else please
>explain? Are you saying that it is not secure or that whether
the
>key is 128bits or say 256 bits makes little difference in
practice
>because both are thought to be secure today?
I mean what I said, since you can't possibly search either a 128
or 256 bit key space they are equally secure.
When you compare 40 and 56 bit keys, well obviously 56 bit keys
are more secure, since you can search both, just the latter
takes more time.
You can't search either 128/256 bit keyspaces, so technically
there is no advantage to using 256 bit keys.
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] (Scott Nelson)
Subject: Re: Is it possible to use encryption to solve this problem?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 16:00:15 GMT
On Thu, 01 Jun 2000 05:07:14 GMT, [EMAIL PROTECTED] (Paul) wrote:
>We want to have an application that users can buy.
>
>We also can provide add-ons to the application.
>
>We want to be able to sell these add-ons over the Internet via a
>subscription service.
>
>However, we want to make sure that one user doesn't simply pay for the
>add-ons and then simply give them away to others, bypassing the
>subscription service.
>
>Now my question is, what is the best way to try to go about doing
>this? Could encryption technology help us? This doesn't seem to be
>strictly a cryptographical issue, but seems to be related to it. If
>cryptography isn't part of the solution, what might be?
>
The end user must be able to make copies (that's how he gets it.)
so there's really no way to prevent him from making copies for
his friends.
But that doesn't mean you can't do something to make copying
harder, just that you shouldn't bleed yourself white to prevent it.
You might, for example, put a signature into each product,
and each add on. The "main" program can check the signature
in each add on and refuse to run it unless it matches it's own.
(you can add the signature later, with online registration)
The signature could contain some information that most people
consider sensitive (like the credit card number used to purchase
the product) The end user can copy it, but he's unlikely to
put copies on the internet. Techniques exist for embedding
a signature in such a way that it's essentially unremovable.
One problem with this sort of approach, is that some will consider
the security measures a challenge. It might result in your
product being pirated by people who have no interest in the
product itself, just in cracking the protection. Also, while
security makes it less likely that pirated copies exist,
it also reduces the value of the product, which means reduced
sales. Not many people would buy a piece of software if they
had to provide a blood and urine sample first.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 08:56:10 -0700
In article <[EMAIL PROTECTED]>,
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Let's consider a
> standard 1024-bit RSA modulus n, and the `standard' public exponent e =
> F_4 = 65537.
I'd argue that the `standard' exponent is e = 3.
(Yeah, e = 65537 might be more conservative, but if you're worried
enough about speed to consider switching to a totally new cryptosystem,
even e = 3 starts to look pretty good.)
And, there are other cryptosystems out there that essentially let
you use e = 2. They're not as famous as RSA, so they don't get as
much attention, but I don't see any technical reason not to use them.
See, e.g., Dan Bernstein's work.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: XTR (was: any public-key algorithm)
Date: 1 Jun 2000 08:59:16 -0700
In article <[EMAIL PROTECTED]>,
Mark Wooding <[EMAIL PROTECTED]> wrote:
> Besides, do people use 32-bit RSA public exponents?
Not that I know of. Anyway, as I wrote previously, if you care enough
about speed to switch to a new, untested cryptosystem, I'd think you'd
be at least as willing to switch to e = 3. So I'd argue that the proper
comparison should be to RSA with e = 3.
------------------------------
From: [EMAIL PROTECTED] (Paul)
Subject: Re: Is it possible to use encryption to solve this problem?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 01 Jun 2000 16:05:25 GMT
The goal is to make the distribution of add-ons by third parties more
difficult that it is worth to them. As there is no such thing as
perfect encryption (let's please not spawn any threads debating this),
we cannot absolutely solve this problem either. However, we can
perhaps solve it "enough".
>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
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Matrix key distribution?
Date: Thu, 01 Jun 2000 18:45:57 +0200
Benjamin Goldberg wrote:
> Michael Brown wrote:
> >
> > Benjamin Goldberg <[EMAIL PROTECTED]> wrote
> > > Perhaps this seems like a silly question, but what if matrix C isn't in
> > > any special format, but whose only property is that it's non-invertable?
> > For C to be singular either one (or more) row(s) has to be a combination of
> > the other rows or one (or more) column(s) have to be a multiple of the
> > other columns. The matrix C is based on the first idea with the second row
> > being a multiple, in this case m, of the first row. I suspect that is still
> > would be insecure if the matrix C used the other method though.
>
> Don't forget that we're working in modulo 2^32 ... There is therefor
> another,
> simpler way to make C be non-invertable: Make all 4 numbers even.
However, the opponent, knowing this, can divide the matrix with 2.
If a matrix is n*n, there are n diagonal elements, i.e. n degrees of
freedom, and we can put in there arbitrary values of Z_2m. It is at
least heuristically clear that a set of values (not necessarily all even)
of the diagonal elements can (excepting perhaps extremely
pathological cases) be easily found such that the matrix is
non-invertible in Z_2m. (We let the plaintext occupy only the
off-diagonal elements, so that the diagonal elements are free at
our disposal. Incidentally, the same issue underlies a tiny remark
I made in my recent post entitled 'Note on the Hill cipher (II)'.)
I have no proof, but I strongly conjecture that rendering the matrix
C non-invertible in this (general) way could eventually turn out to
be the modification that is needed to render the original scheme to
become a really functioning one.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Charles)
Subject: Free Crypto-Lib for VB?
Date: Thu, 01 Jun 2000 16:38:44 GMT
I'm looking for a free cryptography library full of vector-tested
algorithms, either in BAS, OCX or DLL format, which are usable in a
Visual Basic environment. I realise that VB is the poorest choice for
a language involving crypto, but I would appreciate some help in
finding something.
I have had limited success, once finding a vector-verified Blowfish
DLL, and another in a group of BAS files with the hashes MD5 and
SHA-1, and the cipher RC4, but MD5 didn't verifiy against the
vectors...so scrap that one.
Anyone know where I can find a free crypto-lib for VB? (particularly
including an implementation of SHA-1).
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Why encrypt email...
Date: Thu, 01 Jun 2000 16:47:13 GMT
Mark Wooding wrote:
> 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.
Check out www.thawte.com. Free certs, and transitive trust. (Not free
transitive trust, tho.)
They'll sign PGP keys, as well.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"I can't believe the whole diswasher is full, and no chopsticks."
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is it possible to use encryption to solve this problem?
Date: Thu, 01 Jun 2000 16:51:38 GMT
Paul wrote:
> The goal is to make the distribution of add-ons by third parties more
> difficult that it is worth to them. As there is no such thing as
> perfect encryption (let's please not spawn any threads debating this),
> we cannot absolutely solve this problem either. However, we can
> perhaps solve it "enough".
Consider whether you could have (say) a help-menu "about" entry that gives
the name, address, and (say) credit card used to pay for the subscription.
Save that in the executable in a way that is difficult to change. Then,
giving away the executable means giving away information that's annoying and
potentially expensive to have others knowing.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"I can't believe the whole diswasher is full, and no chopsticks."
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DVD encryption secure? -- any FAQ on it
Date: Thu, 01 Jun 2000 19:12:48 +0200
David Hopwood wrote:
> For another summary and a copy of the DeCSS source, see
> http://www.users.zetnet.co.uk/hopwood/crypto/decss/
I remember reading in a magazine that someone in Finnland
was sued for having put DeCSS on his web. Aren't you
afraid of similar legal problems?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tableaus Revisited, Again
Date: Thu, 01 Jun 2000 19:12:29 +0200
wtshaw wrote:
> The basis for all of cryptography stems from the same roots. Beaufort and
> Vigenere are two systems with the same mission, such that their solutions
> are almost the same. It's like approaching a mountain, and photographing
> it from two different directions. The third complement is the Beaufort
> Deviant, better known as the Deviant.
I always wonder why Vigenere was that popular and people didn't
widely employ substitution tables with independent alphabets, i.e.
with each column being an arbitrary permutation of the alphabet.
Do you happen to know of a reason?
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Is it possible to use encryption to solve this problem?
Date: Thu, 01 Jun 2000 19:14:38 +0200
Mok-Kong Shen wrote:
> Do I understand that you sell G and A and you want to prevent the
> case that two customers both have G and jointly use only one A?
> Couldn't you use license numbers to pair G and A, so that on running
> a check is made? If the commodities are software, you could hide
> the license numbers somewhere somehow, but there is no way against
> determined hacking. Of course, if hacking costs more, then you are
> safe.
Addendum:
Some software are protected through checking a processor
identification, so that it can be run only on that one computer.
You might consider that method.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: No-Key Encryption
Date: Thu, 01 Jun 2000 19:17:01 +0200
John Savard wrote:
> <[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 there is a misunderstanding between us. My point was
that imposing the requirement 'M*A*B=M*B*A for any M,A,B'
IS imposing the requirement of commutativity of the operator '*'.
M. K. Shen
------------------------------
** 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
******************************
