Cryptography-Digest Digest #759, Volume #12 Sun, 24 Sep 00 02:13:01 EDT
Contents:
Re: How many possible keys does a Playfair cipher have? (David Empey)
Re: 128-bit Secure LFSR ("bubba")
Re: New Strong Password-Authentication Software (Thomas Wu)
Re: Software patents are evil. (Bill Unruh)
Re: New Strong Password-Authentication Software (Bill Unruh)
Re: My attempt at an alogrithm. (halofive)
Encrypted File Systems..? (halofive)
Re: Encrypted File Systems..? (Ken Y. Ramoil)
Re: What am I missing? (Sagie)
Re: Software patents are evil. ("Paul Pires")
----------------------------------------------------------------------------
Date: Sat, 23 Sep 2000 20:43:04 -0700
From: David Empey <[EMAIL PROTECTED]>
Subject: Re: How many possible keys does a Playfair cipher have?
John Savard wrote:
>
> On Sat, 23 Sep 2000 15:06:50 -0700, David Empey
> <[EMAIL PROTECTED]> wrote, in part:
> >"Douglas A. Gwyn" wrote:
> >> John Savard wrote:
> >> > [EMAIL PROTECTED] (Alex) wrote, in part:
> >> > >How many possible keys does a Playfair cipher have?
> >> > 25! , or more if the letter to omit can be varied as well.
>
> >> However, many of those keys are equivalent (in the sense that they
> >> will produce the same encipherment). So the answer is 24!, unless
> >> somebody can find some more equivalences.
>
> >How about reflection around the main diagonal? Wouldn't that work?
> >Or did you already include that in your figure?
>
> Obviously, 24! is derived from 25! by changing the starting point, so
> indeed you also have a valid correction: 24!/2, since neither parity
> reversal nor decimation will yield the same cipher.
>
> Sorry, that isn't quite right. While parity reversal and decimation
> don't work because moving one down and one left when the letters are
> in the same column or row wouldn't work,
>
> reflection about the main diagonal doesn't work because when the two
> letters are _not_ in the same row or column, each takes it's own row,
> and the column of the other letter. This rule distinguishes between
> rows and columns.
Oops! So it does.
>
> So D. A. Gwyn had the right answer.
Unless there's some other symmetry of the cipher none of us has thought
of.
--
Cordially,
Dave Empey
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: 128-bit Secure LFSR
Date: Sun, 24 Sep 2000 03:39:26 GMT
Tom,
Your constant looks good. I believe you are working with primitive
polynomial:
x^128 + x^127 + x^126 + x^125 + x^123 + x^122 + x^121 + x^120 + x^119 +
x^115 + x^112 + x^111 + x^110 + x^109 + x^108 + x^107 + x^106 + x^102 +
x^100 + x^98 + x^94 + x^93 + x^92 + x^91 + x^88 + x^86 + x^85 + x^84 + x^83
+ x^77 + x^73 + x^72 + x^71 + x^70 + x^69 + x^68 + x^66 + x^65 + x^63 + x^60
+ x^57 + x^56 + x^55 + x^50 + x^49 + x^47 + x^45 + x^44 + x^43 + x^42 + x^40
+ x^39 + x^37 + x^33 + x^32 + x^30 + x^29 + x^28 + x^26 + x^25 + x^24 + x^23
+ x^20 + x^19 + x^13 + x^12 + x^8 + x^4 + 1
Or in hexadecimal, 001EF89FC54797823F69386BDA377983111
Now this hex constant does not look like yours, because yours is right
shifted
once. That is because of a distinction that is seldom explained. It is sort
of
explained here:
http://sduplichan.home.att.net/primitive/gf16.txt
Note that a primitive element is one with max order, 15 in this example.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8qjaqg$rut$[EMAIL PROTECTED]...
> I reposted my slfsr to my website at
>
> http://www.geocities.com/tomstdenis/files/slfsr.c
>
> I am using a single 128-bit LFSR in self-shrinking mode. I would
> appreciate someone who could verify the polynomial used. I am using
> the LFSR in galois config. I made the LFSR poly with a program called
> LFSR.EXE that I found on an ftp that was posted here a bit ago.
>
> It's compact code, albeit not that efficient (are any LFSR's
> efficient?). It features a simple rekeying :), fast enough for desktop
> usage and it's really simple...
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: New Strong Password-Authentication Software
Date: 23 Sep 2000 21:06:58 -0700
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Thomas Wu wrote:
> [snip]
> > PAK is more like EKE and SPEKE in that both client and server know the
> > same password, while SRP is verifier-based, so the server's secret
> > isn't enough to impersonate a client.
>
> Saying that the SRP server doesn't know enough to impersonate a client
> implies that a PAK server does... I don't know much about either
> protocol, but does this mean that a person with access to the data files
> of a PAK server can impersonate the client to another PAK server, or
> does it mean that he has the password in the clear?
This is the difference between protocols that are "verifier-based" and
those that aren't. PAK, like EKE and SPEKE, requires both client and
server to know some secret X. This X may be derived from a password,
e.g. X = SHA1(P), but the important points is that (a) the server must
store X and (b) the client doesn't need P (the plaintext password), he
only needs X, which might have been stolen from the server. This is
a non-verifier-based protocol, where what is stored on the server is
"plaintext-equivalent" to the clear text password. With a good
implementation, the system would "salt" the password with a random value
S, e.g. X = SHA1(S, P), so that if you stole X from one server, you
couldn't use it to access another server, even if the same password
was being used, since the salts would likely be different. The only
thing you could do is break into the system that you stole X from.
Verifier-based protocols, like SRP, A-EKE, B-SPEKE, AMP, and PAK-X
store some one-way derivative of X - call it f(X), on the server,
but requires the client to know X itself to perform authentication.
An attacker who stole f(X) from the server would still need to perform
a brute-force attack to get X, instead of getting direct access to the
server. This provides an additional level of protection against someone
who manages to gain read-only access to a server's password database.
> That last possibility sounds very bad.
I don't think that the cleartext password can be instantly revealed
like that with any of the currently-known strong password solutions.
Perhaps you're thinking of ssh UserAuthentication? :-)
> --
> ... perfection has been reached not when there is nothing left to
> add, but when there is nothing left to take away. (from RFC 1925)
--
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] (Bill Unruh)
Subject: Re: Software patents are evil.
Date: 24 Sep 2000 04:33:26 GMT
In <9Cbz5.2401$[EMAIL PROTECTED]> "Paul Pires" <[EMAIL PROTECTED]>
writes:
]Twilight zone. I responded below but.....
]Is it just me or did this Re: post just get lopped off the branch
]by Usenet? Do you see a new posting from me immediately below
]this one? or are we still attached to the original thread?
I think it was something I did. Not sure what. Oh well the branch was
getting mighty long. ( and am I pointing in the right direction with
that saw?)
]<SNIP>
]>
]> Please read. prove does not mean "it follows logically and inelluctibly
]> from some premises." A proof is a test of the truth of a statement. That
]> is waht the patent office does. That is what the applicant must do. He
]> must supply to the patent office all evidence which he knows of which
]> might invalidate the patent. He must swear that this patent covers new
]> material. These are all standards of proof. Unfortunately as you point
]> out patent examiners do not know everything about everything and may
]> well be convinced when they should not be. That is why bringing some
]> sort of adversarial role into the patent process might help. Ie, a
]> patent can be challenged via the patent office by the same process as
]> the patent was granted.
] I'll ignore your testy intro. I know what prove means and I even guessed
]at your usage. But, this idea above actually sounds like a good idea. I'm
]not being nasty, I think this is neet. One problem, How can you retract,
]or reduce a patent once granted without due process. Note: a regulatory
]action is not due process.
Well, if the granting thereof is "due process' then surely such a
bureaucratic, rather than legal reconsideration would also be due
process. The end result could always be taken to court just as a patent
can now.
]Maybe combine this with a provisional status. Something like: A patent can be
]forced back into the review process (1 time only) within 6mos. after granting if
]certain
]challenge requirements are met. Have to be pretty strengent or it will be weak
]to
]a denial of service by flood attack.
Well, at least in part the filing fees etc would act as a deterent. A
one time review would not be a good idea or it would behove the patentor
to have a friend launch a silly challenge to use up that single review.
On the other hand that single review could be a collective one-- ie a
number of people could, if they so wished, join in challenging the
patent in that review process.
]Naw, this just won't work. if it is reducible, it is not a patent yet. No one
] would licence a provisional patent so you might as well not do it.
Well, patent pending seems to be something which carries weight as well.
Another approach would be to open the granting process-- ie publish
patent applications as well as granted patents. That way the patent
could be challenged in the intial review as well. One could limit the
scope of the challenge (pointing out prior art for example).
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: New Strong Password-Authentication Software
Date: 24 Sep 2000 04:37:57 GMT
In <[EMAIL PROTECTED]> Thomas Wu <[EMAIL PROTECTED]> writes:
]There are many choices for strong password protocols these days, and
]more are continually being developed. Most of the differences are
]in terms of efficiency, round complexity, whether or not the protocol
]is verifier-based, depth of standardization, licensing terms, and
]level of proven security. IMHO, there's enough variety to satisfy
]anyone, and thus no real excuse to use a weak protocol (e.g. broken
]challenge-response protocols or encrypt-and-send-password protocols)
]anymore. The relatively small differences between these protocols is
]swamped by the enormous difference between strong password protocols
]in general and the broken authentication protocols that still plague
]security software today.
Agreed. The problem of course is that one person using a password
protocol is not enough. He needs people to talk to, and he needs the
procol to be available on all the sytems he is liable to use. ssh is
getting to that point, despite the fact that it is not ideal as a
protocol. Ie, what one needs is a standard--defacto or dejure.
Of course it is not clear how that standard gets implimented.
------------------------------
From: halofive <[EMAIL PROTECTED]>
Subject: Re: My attempt at an alogrithm.
Date: Sun, 24 Sep 2000 04:33:04 GMT
Hi, thanks for responding. I've had a ton of homework lately- no time
to check this news group or actually think about any actual cyphers.
After actual thought, my "cypher" was cheap.. it's real hard to create
your own cipher, but atleast I'm learning something :)
My idea wasn't too well thought out, sigh. I'll play around, best I
can do now :)
In article <[EMAIL PROTECTED]>,
Runu Knips <[EMAIL PROTECTED]> wrote:
> halofive wrote:
> > hello, I'm sorry if this is the wrong place to post ideas...
>
> Nono, its the right place.
>
> > lately i've been reading a book concerning cryptography and it's
had me
> > thinking about ways to encrypt files. Can someone please tell me
if my
> > idea is efficient? I'm going to start writing it in C- but I would
like
> > too see if anyone has any suggestions.
>
> Well, see below.
>
> > The program requires the user to first input the password being used
> > (key). The program breaks down the password (starting from the end
> > working to the first letters input).
>
> No surprise, of course you need a key and an input.
>
> > Multiplying the last letter's [of the the password] ascii value,
plus
> > two, by the ascii value of each char's ascii value, divided by ten,
> > results in the first chars encrypted value (represented in ascii).
>
> I don't understand what you're talking about. What do you
> want to do ? And how do you want to decrypt ?
>
> Is this a stream cipher ?
>
> For example, what do you do with all these results of the
> multiplications ? Do you add them together ? Very bad
> idea, because a*b + a*c = a*c + a*b = a*(c+b). Do you
> multiply with each other ? Even worse idea, because
> a*b = b*a, so the position of the individual bytes
> never matter.
>
> > This is done individually with each char of the password, on each
new
> > encrypted char- over and over.
>
> Again no surprise... of course you encrypt ALL bytes
> not only the first one.
>
> > I am not sure if this makes sense, I will start writing it and see
if
> > it still looks as good as it does on paper.
>
> It doesn't look good.
>
> > Thanks for listening, if you have suggestions please respond to
this or
> > via e-mail- it's up to you.
>
> I prefer answering in NG.
>
--
Outlook Express: Spreading more viruses than a diseased hooker.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: halofive <[EMAIL PROTECTED]>
Subject: Encrypted File Systems..?
Date: Sun, 24 Sep 2000 04:41:15 GMT
Is the idea of a "secure filesystem" logical? I've been playing around
with Linux (suse, in particular) and love it- but I'd like to know if
this would sound logical to try:
Create a small partition with the boot loader software and decryption
alorithm- using something similar to DES or IDEA.
Then, encrypt your entire partition file system (root etc).
The only way to access would be to enter the correct password at the
bootup, which would then decrypt the contents of the hard drive.
Maybe I'm thinking out of my ass, the problems would be obvious.
Where can I store the files as they're being decrypted?
and
Any files decrypted or downloaded would be saved on the disk- making
the possibility of recovering the data stored on the disk possible.
Ugh.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Ken Y. Ramoil)
Subject: Re: Encrypted File Systems..?
Date: Sun, 24 Sep 2000 05:08:55 GMT
halofive <[EMAIL PROTECTED]> wrote:
>Is the idea of a "secure filesystem" logical? I've been playing around
>with Linux (suse, in particular) and love it- but I'd like to know if
>this would sound logical to try:
>
>Create a small partition with the boot loader software and decryption
>alorithm- using something similar to DES or IDEA.
>
>Then, encrypt your entire partition file system (root etc).
>The only way to access would be to enter the correct password at the
>bootup, which would then decrypt the contents of the hard drive.
>
>Maybe I'm thinking out of my ass, the problems would be obvious.
>Where can I store the files as they're being decrypted?
>and
>Any files decrypted or downloaded would be saved on the disk- making
>the possibility of recovering the data stored on the disk possible.
>
>Ugh.
You could model it around Scramdisk. That's a popular on-the-fly disk
encryption program with open source: http://www.scramdisk.clara.net/
or you could find several references to other similar programs here:
http://www.fortunecity.com/skyscraper/true/882/index.htm
I don't know if any such programs already exist for Linux.
--
"Ken Y. Ramoil" is actually 6801 253974 <[EMAIL PROTECTED]>.
012 3 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5x5poker.com.
------------------------------
From: Sagie <[EMAIL PROTECTED]>
Subject: Re: What am I missing?
Date: Sun, 24 Sep 2000 05:08:49 GMT
Before going any further, I feel I should state that I have not
downloaded any of the SDMI samples. Their just too damn big and I have
got other things to do with my already narrow 33.6K dial-up bandwidth.
> Download the samples and listen to them. Can you hear anything?
> There are a number of embedding methods that survive compression
> and which are inaudible. Some schemes are bad, tho, and you can
> hear the mark, but others are not so bad.
I might hear it (I have acute hearing) and I might not (maybe it's not
that acute). The fact is that they give only two watermarked samples
per technology, which is probably not sufficient to test the audibility
of the watermark. Surely, watermark technologies deal with certain
signals better than the others.
> And I think you meant to say "hard" instead of "hardly." Me,
> I work hard for me money. Maybe on weekends I hardly work.
Thanks for the English lesson. I think both of the option fit well,
though. If I hardly earn any money, I sure am going to think twice of
any buck I spend...
> They do indeed survive MP3 compression. That is probably their
> main design goal.
I am sure that this is one of their primary goals, but how can you tell
that they really do survive MP3 compression?
> Possibility 4: compression is not perfect, and of course does
> not remove ALL inaudible information. There are lots of
> subtle modifications you can make to music that a compressor
> can not remove.
>
> Many of these schemes are based on techniques that clearly can't
> be compressed out. And anything that survives MP3 or AAC
> compression is going to survive subsequent codecs for a long
time.
First of all, you don't know (well not for sure) what techniques are
being used by any of these watermark technologies. Secondly, I think
you are being short-sighted. Psycho-acoustic models are constantly
being improved. I think it's only a matter of time until one
compression technique or another will defeat whatever watermark SDMI
will finally choose to use. If the changes are so subtle, they would
not survive other kinds of modification to the signal (audio-
enhancement filters, equalizing, pitch shifting, etc).
> I'm pretty confident it will. Many clever methods will
> survive anything the compression people can come up with.
> You should read some papers on audio embedding methods,
> and then see if you have any doubts.
Maybe I should. But only future will tell how the watermarking
techniques will survive future compression methods.
> I don't think you understand the amount of work that is
> required to defeat a watermark, if you don't know the algorithm.
Actually, I do. But I think it is quite obvious that with the data that
SDMI have provided us with, there is nothing serious you can really do.
So you can do some preliminary analysis with the basic methods I have
suggested (frequencies, stereo image, etc.).
> As important as it is to examine the clips, and to experiment
boldly,
> you're not just going to find it merely by examining the clip
in
> an audio tool, by clicking buttons.
See above.
> Here's a challenge for you: watermark an image in Photoshop
> using Digimarc's watermarking plug-in (last I checked this came
free
> with Photoshop,) and see if you can gain ANY INFORMATION
WHATSOEVER
> about how the watermark works just by clicking any of those
buttons.
The analytical information that can be gathered from Photoshop is not
as abundant as the information that is provided by audio editors
nowadays.
A picture has much more information than sound does, and Photoshop
doesn't provide nearly as much analytical tools as audio editors.
> Throw in a program to do various tranforms like DCTs or FFTs if
> you want.
Sure, if you'll give me some. I thought we were talking about readily-
available, popular, easy-to-use editing tools (namely Photoshop).
> The Digimarc mark is not garbage, but actually a very coherent
> pattern that encodes a string of bits. 20 bucks says you'll
never
> find what those bits are, using this approach.
Maybe. I don't have the time (or the will) to check it.
> >The guy can run a frequency analysis, check the stereo image, see the
> >magnitude level of the watermark signal, and that's only the
beginning
> >of it (all within a couple of clicks here and there). If this is not
> >analysis then I don't know what is.
>
> You don't know what is, I'm afraid. You must do more than just
> "look" at the signal in various ways. You must actually try to
> figure out what it means, how it is embedded, how it will be
> different for different audio clips. You're merely describing
> ways to get information about the audio, and while this
information
> is important _for_ analysis, it alone won't suddenly reveal the
> hidden message to you.
I'm afraid *YOU* don't know what analysis is (look it up in the
dictionary). Each of the methods that I have described are all
different kinds of analysis. They are not important _for_ analysis,
they *ARE* analysis (by definition! one method is even
called "frequency analysis" for god's sake). They are all important and
basic tools when analyzing audio information, especially such that is
supposed to be inaudible. I have never said that they are sufficient
for the cracking of the watermarks (as I said earlier in this post, I
don't think we've been given enough information to crack the watermarks
at all). All I said was "you can analyse it with these tools". I didn't
say "these tools are all that you need to crack this conundrum".
> Analogy: a couple years ago some guy started hawking a
calculator
> program in this group that could do conversion to binary and
other
> bases. His pitch was that we could take ciphertext, convert it
> to base 3, or base 7, or base 2, and maybe if we just keep doing
> this and "looking" at it we'll just see some crucial pattern.
> Of course, with data encrypted w/ any modern cipher, you will
> not ever spot a pattern by dicking around with a calculator.
> Or by dicking around with some more advanced tools.
That's not quite the same. You are talking about encryption, but we
were discussing watermarking. Encryption is designed to avoid
mathematical models, watermarking is designed to avoid human sensory
systems. The fact is that by using special analytical tools you would
probably see a pattern in a watermark (especially one that holds
information within it), whereas encryption is designed to be non-linear
and to hide any patterns.
For instance, phase changes are usually inaudible and undetectable to
the human ear. Using mathemtical analytic tools, however, it is easy to
detect such changes. I have no doubt that certain audio watermarking
use phase modulation techniques. Furthermore, even *you* said that the
Digimarc watermark is a coherent pattern. If it is a coherent pattern,
than it is detectable with analytical tools.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Date: Sat, 23 Sep 2000 22:46:44 -0700
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:8qk06m$s23$[EMAIL PROTECTED]...
> In <9Cbz5.2401$[EMAIL PROTECTED]> "Paul Pires"
<[EMAIL PROTECTED]> writes:
>
> ]Twilight zone. I responded below but.....
>
> ]Is it just me or did this Re: post just get lopped off the branch
> ]by Usenet? Do you see a new posting from me immediately below
> ]this one? or are we still attached to the original thread?
>
> I think it was something I did. Not sure what. Oh well the branch was
> getting mighty long. ( and am I pointing in the right direction with
> that saw?)
It's getting weirder! Now it picked itself up from where it was last (when I
responded)
and glued itself to a different thread. I had to hunt to find it!
>
>
>
> ]<SNIP>
> ]>
> ]> Please read. prove does not mean "it follows logically and inelluctibly
> ]> from some premises." A proof is a test of the truth of a statement. That
> ]> is waht the patent office does. That is what the applicant must do. He
> ]> must supply to the patent office all evidence which he knows of which
> ]> might invalidate the patent. He must swear that this patent covers new
> ]> material. These are all standards of proof. Unfortunately as you point
> ]> out patent examiners do not know everything about everything and may
> ]> well be convinced when they should not be. That is why bringing some
> ]> sort of adversarial role into the patent process might help. Ie, a
> ]> patent can be challenged via the patent office by the same process as
> ]> the patent was granted.
>
> ] I'll ignore your testy intro. I know what prove means and I even guessed
> ]at your usage. But, this idea above actually sounds like a good idea. I'm
> ]not being nasty, I think this is neet. One problem, How can you retract,
> ]or reduce a patent once granted without due process. Note: a regulatory
> ]action is not due process.
>
> Well, if the granting thereof is "due process' then surely such a
> bureaucratic, rather than legal reconsideration would also be due
> process. The end result could always be taken to court just as a patent
> can now.
>
>
> ]Maybe combine this with a provisional status. Something like: A patent can
be
> ]forced back into the review process (1 time only) within 6mos. after granting
if
> ]certain
> ]challenge requirements are met. Have to be pretty strengent or it will be
weak
> ]to
> ]a denial of service by flood attack.
>
> Well, at least in part the filing fees etc would act as a deterent. A
> one time review would not be a good idea or it would behove the patentor
> to have a friend launch a silly challenge to use up that single review.
> On the other hand that single review could be a collective one-- ie a
> number of people could, if they so wished, join in challenging the
> patent in that review process.
The second case. I meant a collective process on all qualifying material gleaned
during the period. How to twart trivial challenges? Easy! Charge a challenge
processing fee to fund the process. You charge the inventor to file, charge his
detractors to challenge. There is a symmetry there.
>
>
> ]Naw, this just won't work. if it is reducible, it is not a patent yet. No one
> ] would licence a provisional patent so you might as well not do it.
>
> Well, patent pending seems to be something which carries weight as well.
> Another approach would be to open the granting process-- ie publish
> patent applications as well as granted patents.
No No No... Horrible idea. Most patents are ammended, repaired and revised
during the process Let the pro's (the examiners) have at it then kick it public.
>That way the patent
> could be challenged in the intial review as well. One could limit the
> scope of the challenge (pointing out prior art for example).
>
Thanks
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
******************************
