Cryptography-Digest Digest #51, Volume #11 Fri, 4 Feb 00 12:13:01 EST
Contents:
Re: Court cases on DVD hacking is a problem for all of us ("Douglas A. Gwyn")
Re: 26-Dimensional cipher - is it secure (or even possible)? ("Douglas A. Gwyn")
Re: free C crypto API (Runu Knips)
Re: How to password protect files on distribution CD (Eric Lee Green)
Re: How to Annoy the NSA ([EMAIL PROTECTED])
Re: How to password protect files on distribution CD (Eric Lee Green)
Re: Court cases on DVD hacking is a problem for all of us (Eric Lee Green)
Re: Is RC6 a more advanced design than CAST/IDEA...? (Eric Lee Green)
Re: Is RC6 a more advanced design than CAST/IDEA...? (Bob Silverman)
Hill Climbing ("Michael Darling")
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Fri, 04 Feb 2000 14:42:42 GMT
Eric Lee Green wrote:
> ... I own this book. I do not own the words within this book, ...
> You are saying that different standards should apply to DVD disks?
You own that copy (instance) of the DVD, but as with the book
you may not make copies of it (at least, none that would
otherwise have had to be purchases). The idea is to not
cheat the creators out of their reward for their efforts.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 26-Dimensional cipher - is it secure (or even possible)?
Date: Fri, 04 Feb 2000 14:51:52 GMT
[EMAIL PROTECTED] wrote:
> The only multi-dimensional algorithm I am
> personally aware of is a Monte Carlo
> algorithm. What kinds of algorithms do you
> mean? Also, is it possible to base
> cryptography on higher dimensional automata?
Perhaps you should define more precisely what it is
that you're asking about. "Higher dimensions" are
an utter commonplace in cryptographic algorithms,
many of which can be expressed in terms of vectors
of considerable length. There's nothing mysterious
or even especially difficult about such concepts.
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: free C crypto API
Date: Fri, 04 Feb 2000 16:13:08 +0100
Tom St Denis schrieb:
> In article <862jhk$ohd$[EMAIL PROTECTED]>,
> Greg <[EMAIL PROTECTED]> wrote:
> > > Well I decided to release CB a bit early. I am looking for
> > > comments/suggestions/improvements.
> > > Basically CB is a complete crypto API. It can make/use RSA crypto,
> > > symmetric crypto, has data compression, a RNG, base64 routines and
> > > more. [...]
> > > All of this is free!!!
> >
> > I downloaded a copy of your stuff and noticed that you did not
> > ask me anything. Where is the server located?
>
> I will not dignify that. I was hoping for real discussion about
> working on CB [i.e bugs or what have not]. This group has some of the
> smartest people in the world yet they can't stay on task.
> Did you have any troubles building CB on your computer?
No problems with VC++ 5.0 under Windows. Will check gcc/linux at
home. And I've seen worser cryptographical libaries before.
However, many of this stuff is from other people, plus, for
example, IDEA is patented and can't be used for free. But has
a twofish implementation, too. Very good, so I can drop IDEA
anyway :)
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix
Subject: Re: How to password protect files on distribution CD
Date: Fri, 04 Feb 2000 08:38:02 -0700
Vernon Schryver wrote:
> I checked the web page in your signature and discovered your employer is
> the source of BRU. I met BRU 12 or 13 years ago, and found it among the
> worst excuses for backup software that I've ever encountered. It was far
> worse than the obvious alternatives such as cpio or tar piped to
> `compress`. I tried BRU on an important operational system or two, and
> was amazed that it took many times longer to do the same work as tar and
> compress.
The issue, of course, is data verification. BRU checksums each block so that
you can verify at any time that the data on tape is good. On the processors
available 12 or 13 years ago, that took significant amounts of time. On
today's processors that's no longer an issue, the guy who tends our
error-detection code says he's benchmarked that part of the code at hundreds
of megabytes per second throughput on an AMD K6-2/300.
Another "secret" for BRU is that it pads everything to the nearest tape block,
so that if data goes wrong, it can skip the errant block and accurately find
the next file header, and if one tape block goes bad, you lose one file (max).
Again, something that 'tar' doesn't do. (Don't believe me? Load a 'tar' file
into XEmacs and see!).
In other words, it's doing something different from 'tar' and 'compress' (not
to mention having a better GUI :-), and some people seem to appreciate that.
It's not as critical now as it was back in 1984, when tape drives were much
less reliable than they are today, but it's still doing more than 'tar' does.
As for "snake oil sales stories", my boss showed me a few of those ads (from
before he put a stop to it five or six years ago), and I agree that they were
pretty embarassing :-}.
> Among the reasons that I so dislike BRU is that a manager bought the
> salescritter story and caused my UNIX vendor employer to make BRU the
> default and emergency backup system. Paying the fees to the BRU outfit
> irritated me, but what really grated was the disasters suffered by my
> employer's customers who were dumb enough to use the default. It took
> years to recover from that mess.
Ah. You must have been working for SGI :-). (Which we've been trying to get
them to remove that antique version of BRU off their system for ages now, but
their attitude is that they paid for it, and so what if it doesn't run right
under modern versions of IRIX?).
Please note, by the way, that I do *NOT* speak for Enhanced Software
Technologies. I am a software engineer, not a marketing person.
> >> What "normal" license manage does not not involve a hardware serial number
> >> or signature of some kind?
> >
> >Windows 98? Just about all PC software that I've ever encountered that's
> >licensed on a per-user vs. per-seat basis?
>
> That statement suggests a differnet notion of "license manager" than mine.
> Mine covers the commercial products sold to software vendors to ensure
> that their software can only be used by a fixed number of users in a
> network, on a single host in a network, and so forth.
I see. The ones I'm familiar with are for server-based products which regulate
the number of connections that they'll accept. For example, you can license
the Empress database server to support "x" amount of users, and that's all the
connections that it'll accept. You could hypothetically "clone" your Empress
installation to another machine, but that kind of defeats the whole purpose of
a database server, which is to maintain a centralized data store. I've also
experienced some "X" software for Windows, which uses broadcasts to see how
many other "X" servers by this company are running, and refuses to start up if
there's more than it's licensed for. You can install it on any machine on the
office, but if you try to start it up more times than you're licensed for,
nope, sorry.
Of course, you could partition your network into multiple broadcast domains
and bypass that, but again, that requires active involvement on the part of IT
-- it's not something that casual end-users are capable of doing. IT generally
won't do that sort of thing, because if they can be shown to actively aiding
and abetting, criminal charges against individual IT people can be filed as
well as the usual civil charges.
> What PC software that you have seen that is licensed per-seat, does not
> depend on the honor principle, and does not have a mechanism to make it
> a hassle for users duplicate C: drives and so accidentally get additional
> licenses?
What cars are you aware of that are shaped like a classic Beetle, contain an
engine made by Volkswagon, and have a VW logo on the front?
In other words, it appears that you're attaching conditions that restrict what
you're talking about to a (very) few instances (one, in my example :-). First,
I don't agree with the entire notion of per-seat licensing, especially for
server products. Concurrent licensing, in my opinion, is the "appropriate" way
to site-license software. All concurrent licensing schemes that I've seen
simply open a connection to the license server at startup time, at which point
the license server tells them whether they're authorized or not (using a
public key encryption scheme to head off spoofing the license server, though I
could reverse-engineer that if I were a 'cracker'). Program dies, connection
dies, license server decrements its use counter. Secondly, most programs DO
rely on a "honor principle" of sort rather than on expensive network-dependent
license manager schemes -- that is, they rely upon you not wishing your
license data to be replicated to multiple desktops.
> >2) If a firm can afford a $30,000 package, it's unlikely that they can afford
> >to be sued for running an illegal copy of said package. In my experience,
> >companies are quite paranoid about the expensive stuff.
>
> I don't see how anyone who has noticed the sizes of the outfits that the
> software license police have been busting could say that.
Most of the problems that I've seen are for "end user" software, where it
maybe came pre-installed on one computer, and workers in the department who
wanted the same software decided to copy it onto their own computer rather
than go through the hassle of contacting IT and getting authorization and a
valid license to run that program on their computer (if they even COULD get
authorization to do so -- e.g., if it's a MS Office shop and the user wants to
run WordPerfect, most IT departments would deny the user authorization to run
WordPerfect). This sort of software has to be written so that it will run in a
non-networked environment, thus centralized license management is not going to
work.
>
> BRU, which has a zillion free alternatives that some people think work
> far better. Anyone unwilling to pay and with half a brain will use the
> free alternatives without seriously considering BRU.
Agree there. 'tar' is faster, doesn't use as much tape (since it doesn't pad
things to tape-block boundaries), and most people's data isn't worth all that
much, frankly. While I last backed up my system at home using 'bru', it wasn't
because I was worried about losing my data -- anything worthwhile, like years
of songs and fiction (dating back to the mid 80's), has already been backed up
onto CD-RW. (Heck, I even have old projects like a device driver and a
structured graphics program backed up that way). Would I pay for BRU if I
didn't get it free as part of my employment (for testing purposes)? Probably
not. I just don't have anything to back up that's worth enough for me to care,
and anything that is worth backing up has already been burned to CD-R or CD-RW
and thus is safer than any magnetic tape will ever be. (On the other hand, the
development server/CVS archive here at the office definitely IS backed up with
BRU, with the appropriate
5-day-incremental-Saturday-full-and-keep-monthly-and-yearly-backups tape
rotation... our source code is our livelihood, after all).
I suspect that the same is true of other things. For example, I once
considered buying a copy of Visual C++ so I could write Windows 95 software.
But at the time (1995), Visual C++ was $500 and Linux was free and came with a
C++ compiler and "X" graphical window system with the OpenWindows libraries.
Yeah, it wasn't a very nice development environment compared to Visual C++,
and even today it's more difficult to develop an application than under
Windows (well, KDevelop helps, it looks suspiciously similar to VC++, but
let's face it, it still has a ways to go), but hey, it worked, it was free,
and thus there's no danger that I'm ever going to be tempted to pirate Visual
C++ and install it on my Windows 98 machine at home. I think that may be the
biggest advantage to Microsoft of having free software like Linux around, it
doesn't threaten their core office products market, and largely eliminates the
desire to pirate their development software (and thus prevents the formation
of 'pirate' networks centered around their development software). Sort of the
same situation as 'tar' and 'bru' :-).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to Annoy the NSA
Date: 4 Feb 2000 15:52:19 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] says...
> :> You are wrong again. According to Science
> :> Magazine (vol. 275, page 1570, March 14,
> :> 1997) "hard" problems, or NP-Complete
> :> problems "underlie nearly all cryptography and
> :> computer security codes".
> : You're getting things backwards: when Science Magazine publishes an
> : article the contradicts Doug Gwyn (among others) about cryptography
> It seems that the (quoted section of the) article does not contradict
> anything Doug Gwyn wrote on this thread (irrespective of how true the
> quote is for symmetric encryption systems).
I don't think Science Magazine *or* Doug Gwyn have to be wrong. I
think it's just nermal_83's interpretation that's wrong. Look how
he/she writes this: The "or NP-Complete" part is not in quotes. If I
had to bet, I'd bet that Science Magazine said something like "hard
problems underlie nearly all cryptography and computer security
codes". Certainly nothing wrong with that statement. And then
nermal_83 adds the "or NP-Complete" since in several postings he seems
to think that "hard problems" and NP-complete are the same thing.
So for nermal_83: yes, hard problems undlerly most cryptogrphy, and in
particular one-way functions are important (things easy to compute one
way, but hard the other way). However, these do *not* have to be
NP-complete. In particular, the most common public-key schemes rely
on the difficulty of taking discrete logs and of factoring, both of
which seem "hard", but neither of which is thought to be NP-hard (or
NP-complete if you recast to decision problems).
And on another comment you made: No, Shor's result does *not*
generalize to all NP problems. I have seen a reference stating that
if you extend the quantum model even more (to non-linear operations)
that you can solve NP-complete problems, but I haven't seen the paper
that was referenced (it was in a physics journal, not a C.S. journal),
so I don't really know what's being referred to there.
--
Steve Tate --- srt[At]cs.unt.edu | Gratuitously stolen quote:
Dept. of Computer Sciences | "The box said 'Requires Windows 95, NT,
University of North Texas | or better,' so I installed Linux."
Denton, TX 76201 |
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.unix
Subject: Re: How to password protect files on distribution CD
Date: Fri, 04 Feb 2000 09:04:25 -0700
Roger Gammans wrote:
> In article <87dhke$6ok$[EMAIL PROTECTED]>, Vernon Schryver wrote:
> >In article <[EMAIL PROTECTED]>,
> >Eric Lee Green <[EMAIL PROTECTED]> wrote:
> >> ...
> >>Regarding leaving old cards in machine, I don't know of a reliable way to get
> >>the MAC address of a second card under Linux or SCO Unix. For that matter,
> >>there's "magic" involved in getting the MAC address of the FIRST card.
> >
> >That sounds unlikely to me. I'm too lazy to check my copies of
> >Linux and can't conveniently check SCO Unix, but as I recall from
> >porting the relevant bits, no such magic is required for a system
> >compatible with 4.4BSD-Lite.
>
> Indeed, I've just done:-
>
> knuth:~$ ifconfig -a | grep HWaddr
> eth0 Link encap:Ethernet HWaddr 00:20:18:8B:14:E3
> vmnet1 Link encap:Ethernet HWaddr 00:50:56:8A:00:00
> vmnet0 Link encap:Ethernet HWaddr 00:50:56:80:00:00
Here's my machine at home:
[eric@ehome eric]$ ifconfig -a | grep HWaddr
cipcb0 Link encap:IPIP Tunnel HWaddr
eth0 Link encap:Ethernet HWaddr 00:40:33:D2:00:03
eth1 Link encap:Ethernet HWaddr 00:00:C0:AB:D1:E8
Do note that the low-level sysctl calls being made by 'ifconfig' are dependent
upon the kernel version being used. That's why the 'nettools' package has to
be updated for each release of the Linux kernel. For that matter, Linus has
mentioned doing away with 'sysctl' altogether and relying upon '/proc' to
report all such data. And the 'nettools' package itself contains no guarantee
that it will not at some point change the order in which data is reported.
Meanwhile, I just logged into HP/UX and typed:
# ifconfig -a
ifconfig: no such interface
Whoops! More magic required! Hmm, netstat -i will return a list of interfaces,
but no MAC address is mentioned! (I can't see how to get the MAC address from
the command line on HP/UX, though since I'm no HP/UX expert that's not
surprising).
Not nice!
Now on to SCO:
ifconfig -a | grep HWaddr
WHoops, doesn't report anything at all there, so let's just do an ifconfig -a:
net1: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.3 netmask ffffff00 broadcast 192.168.0.255
perf. params: recv size: 24576; send size: 24576; full-size frames: 1
ether 00:40:c7:79:1b:c9
lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask 7f000000
perf. params: recv size: 57344; send size: 57344; full-size frames: 1
atl0: flags=404a<BROADCAST,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 0.0.0.0 netmask 7f000000
perf. params: recv size: 4096; send size: 8192; full-size frames: 1
Looks like we have to look for 'ether' here, sigh.
Are you starting to get the drift of where I'm going when I say there's no
STANDARD way of getting a hardware MAC address on Unix?
Now granted, the HP/UX box has a hardware ID that is readable from "C". If I
dug around I could undoubtedly find a sysctl call that'll similarly return the
MAC addresses of its interfaces (it has two, a 10mbit AUI connector and a
100BaseT connector). But this all varies widely from Unix to Unix, and even on
Linux it's not guaranteed to continue working next year (when Linus might
decide to change the sysctl structs for networks yet again, since only system
tools are supposed to use sysctl).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Fri, 04 Feb 2000 09:11:01 -0700
Ian Hay wrote:
> Xcott Craver wrote:
>
> > o DVD encryption is not there to prevent illegal copying.
> > It does not prevent illegal copying. A pirate will copy
> > the whole DVD without breaking the encryption, and the copy
> > will play in a DVD player. Encryption doesn't even slow him down.
>
> Sorry to butt in, but this seems to be a point of contention. Isn't the
> above statement (while widely believed) specifically untrue? My
> understanding of the description of the technology involved is that the
> encrypted key, read by the software or hardware DVD player, is on a
> specific area of the distributed DVD that is otherwise pre-embossed on
> writeable DVDs.
In addition, writable DVD's currently do not have the capacity to hold the
data on a (read-only) DVD. Thus it is impossible on the face of it to pirate a
DVD using writeable-DVD media.
However, pirates do not use writable DVD's in order to manufacture their
product. Rather, they use the same equipment that the OEM's use -- a DVD
stamping machine. They set up shop in Malaysia or Thailand or some other such
place with easily-bribed law enforcement, and turn out hundreds of thousands
of copies of popular movies, which are then sold for much less than the
originals. Heck, some of these "pirate" shops are the same folks making the
media for the studios in the first place! (You didn't think that DVD's were
being manufactured in the United States, did you? It's amazing how crony
capitalism manages to "leak" product from legit sources onto the black
market).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Is RC6 a more advanced design than CAST/IDEA...?
Date: Fri, 04 Feb 2000 09:14:50 -0700
Volker Hetzer wrote:
>
> James wrote:
> >
> > RC6 is a very simple and compact on implementation. It uses no s-box and runs very
>fast.
> > So I'm curious if RC6 is more advanced than CAST/IDEA from the cryptographical
>view.
> Depends on what you mean by "advanced". It certainly is newer.
> However, if I had to choose a symmetric cipher I'd wait a few more weeks until
> the AES process has finished. Then I'd choose the winner. RC6 is in the finals,
> but IMVHO unlikely to win.
James: RC6 is a very nice cipher, but relies on having hardware multiplication
operations that run fast. On "smart cards" and such it would be slower than
other alternatives. Thus the reason Volker says it's unlikely to win.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Is RC6 a more advanced design than CAST/IDEA...?
Date: Fri, 04 Feb 2000 16:06:20 GMT
In article <87dhpu$rup$[EMAIL PROTECTED]>,
"James" <[EMAIL PROTECTED]> wrote:
> RC6 is a very simple and compact on implementation. It uses no s-box
and runs very fast.
> So I'm curious if RC6 is more advanced than CAST/IDEA from the
cryptographical view.
The question is meaningless without a metric to measure what makes
one algorithm "more advanced" than another.
Please tell us your basis for measuring algorithms. Then we can
answer the question.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Darling" <[EMAIL PROTECTED]>
Subject: Hill Climbing
Date: Fri, 4 Feb 2000 16:29:43 -0000
I'm hearing a lot about hill climbing algorithms - can anyone tell me of any
links or books which would
tell me more about them.
Regards,
Mike.
--
/**********************************************************\
| Mr. Michael Darling [EMAIL PROTECTED] |
| Noral Micrologics Ltd. Tel: 44+(0)1254 295810 |
| Logic House, Gate St. Fax: 44+(0)1254 295801 |
| Blackburn, Lancs. WEB: http://www.noral.com |
| BB1 3AQ. UK. |
\**********************************************************/
------------------------------
** 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
******************************
