Cryptography-Digest Digest #841, Volume #9 Wed, 7 Jul 99 16:13:03 EDT
Contents:
Re: I don't trust my sysadmin (Rob Warnock)
Re: Keeping File Formats Safe (Jerry Coffin)
Re: I don't trust my sysadmin (Jerry Coffin)
Re: optimizations (for feedback PRNGs...) (Medical Electronics Lab)
Re: MP3 Security Requirements? (Thierry Moreau)
optimizations (for feedback PRNGs...) ([EMAIL PROTECTED])
Is it possible to combine brute-force and ciphertext-only in an attack? ("Morgan")
Re: US Laws on DES Crypto Distribution? (Mok-Kong Shen)
Re: Summary of 2 threads on legal ways of exporting strong crypto (Mok-Kong Shen)
Re: Keeping File Formats Safe (William Tanksley)
Re: Moores Law (a bit off topic) (fungus)
Re: Windows PWL Files (fungus)
Re: Moores Law (a bit off topic) (smoke_em)
Re: optimizations (for feedback PRNGs...) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: I don't trust my sysadmin
Date: 7 Jul 1999 09:28:27 GMT
Tramm Hudson <[EMAIL PROTECTED]> wrote:
+---------------
| The Intel Paragon and Teraflops (ASCI Red) both have the ability to switch
| between classified and unclassified operations...
| On the Teraflops there is a physicall disconnect between the compute
| and disk cabinets. The machine is structured with two "heads" of
| IO nodes and a collection of diskless compute nodes in between. One
| side contains classified disks, the other unclassified. In order to
| change between operational modes the IO cabinets from the other protection
| domain must have an air gap from the current one.
+---------------
Oh *really*??!? Are you saying there are *NO* EPROMs or EEROMs or
battery-backed SRAMs in *any* of the electronics of the "diskless"
nodes? In most classified sites, you can't "switch modes" on any
boards that have EPROMs on them (*including* boot ROMs!!). In fact,
if a board breaks, you either have to physically remove all of the
EPROMs/EEROMs from it, or it that's not eaily possible, then "shred"
the whole board -- you're not *allowed* to swap the failed board for
a spare. [The reason being, of course, that if the board contains
*any* non-volatile memory on it, it could be used as a covert channel
to smuggle information out...]
This is a *really* big problem for recent high-performance CPUs
(and I/O boards with embedded micros on them), since for maintainability
reasons the boot ROMs on them are usually intentionally designed to be
electrically-alterable (e.g., EAROM or word-writable EEROM or "flash" EEROM).
How do the Intel Paragon and Teraflops handle *that*??!?
-Rob
=====
Rob Warnock, 8L-855 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Keeping File Formats Safe
Date: Wed, 7 Jul 1999 11:11:50 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> I read somewhere that Autodesk's AutoCAD file format (*.dwg) has not been
> easy to reverse engineer. Did they encrypt the file or merely compress it?
No -- they just make it fairly complex, and add more complexity with
every release. I reverse-engineered a substantial part of it years
ago. At least at that time, it looked like it was probably a fairly
direct dump of the data structures to disk. The problem is that the
data structures are often deeply nested, and heavily cross-linked.
For example, IIRC, when you use a block, the block doesn't get
reproduced at each use -- instead, you just get links back to the
original block.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: I don't trust my sysadmin
Date: Wed, 7 Jul 1999 11:11:48 -0600
In article <7lvjh7$bed$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> You can buy more secure systems; I've never heard of an A1 system (the
> highest level),
I haven't checked in quite a while, but the last time I looked, there
was only one OS on the A1 evaluated products list.
> but B2 and B3 *are* available. They just don't run
> Unix. So you can get real, usable, security at the expense of an
> operating system that no one knows and that's incompatible with everything.
Actually, there is (or at least at one time was) one UNIX-based system
that was on the B2 evaluated products list. As I understand it, they
had to do quite a bit of work on the kernel to achieve that though --
to the point that it's open to argument whether it was really UNIX
anymore or not.
There's one more point that hasn't been mentioned: according to the
Orange book, an OS (or other product) is NOT rated for a particular
security level -- only a particular installation can be rated for a
security level. They do maintain a list of products that have been
used in installations that have been rated for particular levels of
security; if you want a secure installation, it's generally much
easier to do if you start with products already on the list, but it's
no guarantee by itself.
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: optimizations (for feedback PRNGs...)
Date: Wed, 07 Jul 1999 12:31:50 -0500
[EMAIL PROTECTED] wrote:
>
> I was thinking about ways to optimize feedback Prngs such as parallel
> LFSRS or additive generators.. Basically the slow part is updating the
> counters (which must wrap at arbitrary points such as 55 and 52...).[....]
> Does anybody know more efficient means? Maybe unroll two PRNGs into
> the same code (chance for pairing)? But if they are not the same
> length the last outputs would slow down. It would have to be faster on
> average (i.e for large arrays). Another problem if they are not the
> same size is that if you run out of one PRNG first what todo? Discard
> values from the longer one?
I think you should get a few parts from Radio Shack or DigiKey and
build it in hardware. You don't need to solder anything, wire wrap
or a "breadboard" will work fine. You need a power supply, some
shift registers and some XOR gates. LFSR's were meant for hardware
implementations, building one in hardware will show you why.
It's really lots of fun because digital electronics is much simpler
than analog (although, you'll still blow things up when you plug
them in backwards :-)
Combining different length LFSR's each built in hardware will give
you a great perspective on how things are supposed to work. Then
translating it into software will be easier, you'll see what the
right answer is from the "real world" device.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: MP3 Security Requirements?
Date: Wed, 07 Jul 1999 13:51:25 -0400
Francois Grieu wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Watermarking of MP3 recorded music is kind of useless.
>
> Can you explain why you think this ?
Basically, it's the difference between what cryptography/IT security
might do in textbook versus real-life imperatives like common sense and
money (the cost of suing someone).
> I feel it could be usefull
> to watermark the music with the ID of the rightfull owner(s)
> of rights and the person the song was sold to, so that
> - it's harder for producer X to illegaly resell a song owned by
> producer Y, ...
If producer Y is small, he doesn't have money for a lawyer. If producer
X is small, it's not worth suing him. Otherwise, the evidence of a
counterfeit sale can be achieved with means less expensive than
technical evidence (e.g. ordinary witnesses of the producer X's offer is
cheaper than expert witness of watermark facts and theory ...).
> ... and the customer has a way to detect this.
The customer has no incentive in doing anything *after* he got his
rocording. Have you ever wasted a full day as a witness for an
infraction that you naively reported to a regulatory authority?
> - customer A runs a risk of identification if he/she illegaly
> shares the music file he/she bought with friends/customers.
Suppose customer A is a teenager but an adult B paid her MP3 download
with my credit card (A doesn't have a credit card and B doesn't want A
to train himself in e-shop lifting by necessity). Who is ever going to
sue who? There is no authentication for the purpose of copyright
enforcement. If there was an economic incentive for this MP3 client
account authentication, it would be a great business opportunity, so
please tell me if I'm wrong.
Stated otherwise, the watermarking technique appears on surface as a
security mechanism devoid of cryptographic key management. Without
sensible key management, what can you really achieve with cryptography?
Perhaps not much!
- Thierry Moreau
------------------------------
From: [EMAIL PROTECTED]
Subject: optimizations (for feedback PRNGs...)
Date: Wed, 07 Jul 1999 16:36:59 GMT
I was thinking about ways to optimize feedback Prngs such as parallel
LFSRS or additive generators.. Basically the slow part is updating the
counters (which must wrap at arbitrary points such as 55 and 52...).
What I thought of was unrolling the PRNG completely so it will produce
55 or 52 (whatever the length is) outputs per call. This will unroll
the loop and use immediate indexing instead of using counters. It
would need instructions like
; ES:DI points to the buf to hold the PRNG output...
; state[y1]
mov al,[BX + OFFSET state + 54]
; state[x1] +=
add [BX + OFFSET state + 18],AL
; get result
MOV AL,[BX + OFFSET state + 18]
STOSB
; repeat 54 more times (i.e use a macro for this :)
Some problems is that although this only requires four instructions
(fairly efficient when compared to the index mode) it doesn't pair at
all. It will require about 5 cycles per clocking (486/586 type
computer). This is better when compared to about 15 cycles (using
index mode), it also doesn't require branching. In my code (the C++
code I posted) I used
x = x < (N-1) ? ++x : 0;
Where N is the length of the register. This is really efficient on
microcontrollers compared to
x = (x + 1) % N
Because it does not require a modulus operation. It is not too super
on superscalar cpus as it requires a branch...
Does anybody know more efficient means? Maybe unroll two PRNGs into
the same code (chance for pairing)? But if they are not the same
length the last outputs would slow down. It would have to be faster on
average (i.e for large arrays). Another problem if they are not the
same size is that if you run out of one PRNG first what todo? Discard
values from the longer one?
Any help?
Thanks,
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Morgan" <[EMAIL PROTECTED]>
Subject: Is it possible to combine brute-force and ciphertext-only in an attack?
Date: Wed, 7 Jul 1999 11:42:48 -0700
I've consulted Schneier's Applied Cryptography & found no answer.
Suppose you have a DES 56-bit key encrypted stream that contains
something like music or video. Is it possible to discover the key
by searching the entire keyspace?
In reality, .wav files, MPEG-2 video, etc. will have headers, so you have
a small crib (some plaintext to work with), so the attack *is* possible,
but the known-plaintext is very small compared with the ciphertext.
I'm imagining that most systems won't do a lot of rearrangement of
the data, so the plaintext snippets (well, the pieces of the header
that are constant at leat) may even be somewhat periodic.
In theory, though, if you have a totally random stream, how do you
know when you've come up with the correct key?
Still thinking....
-Morgan
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: US Laws on DES Crypto Distribution?
Date: Wed, 07 Jul 1999 20:10:28 +0200
David Kessner wrote:
>
> Once upon a time, I thought that I understood the laws
> on distributing crypto hardware/software. But with all
> the talk on capital hill this past year, I have lost track of
> it all.
As an aside, there is an interesting story of exporting some hardware:
http://www.crypto.com/papers/export.txt
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Summary of 2 threads on legal ways of exporting strong crypto
Date: Wed, 07 Jul 1999 19:43:17 +0200
[EMAIL PROTECTED] wrote:
>
> I think there is a case to be made for translated source code. By
> translated I'm distinguishing encodings in pixels, capitalization, etc.,
> i.e., syntactic mangling, from semantic transforms. The Bernstein case
> is interesting because he claimed the source code itself was a form of
> protected speech. We can come at it from a different direction and
> reach the same haven: protected speech.
>
> Clearly it is possible to sanitize a module of source code into
> specifications so that another writer, with no access to the original
> code, can create new software (as opposed to *re*creating the original
> software) with the same capabilities.
>
> Somewhere between sanitization as used in BIOS development and simple
> encodings lie semantic translations. The fact that a semantic
> translation of "C" can be mechanized should not weaken the fact that
> translated source code is english text, and thus protected speech.
Certainly you are VERY safe if you take the pain to describe your
algorithm in plain English sentences. But our goal is to get as
much convenience as possible for the author AND the readers who have
to do the implementation.
Very detailed descriptions which one could translate one-to-one
to codes have already been done. If I don't err, RSA has recently
published a RFC on BSAFE just in that way. Someone conjectured
that there RSA has a mechanism for automatically converting that to
C and reciprocally.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: Keeping File Formats Safe
Reply-To: [EMAIL PROTECTED]
Date: Wed, 07 Jul 1999 19:07:26 GMT
On Wed, 07 Jul 1999 10:11:33 +0200, Ronald Klazar wrote:
>William Tanksley wrote:
>> So, are you fighting cheaters or bandits?
>The case would be bandits.
Whew. That makes it very, very hard. Cheaters undermine the fabric of a
game, but bandits undermine a social system.
>My system consists of an editor and a reader. The editor produces a script
>that the reader will follow in order to perform certain functions. I do not
>want people to uncover the format of the data files from the editor too
>easily, thereby providing their own readers and undermining the whole system.
So the editor-person is trusted, but never the reader-person. Okay, that
eliminates one possible secure channel.
>I read somewhere that Autodesk's AutoCAD file format (*.dwg) has not been
>easy to reverse engineer. Did they encrypt the file or merely compress it?
Encryption is merely obfusication in this case, because there's no secure
channel for the key. It's not always a bad idea, but neither is it as
useful as it would be otherwise.
If you've got ANY secure channel you can accomplish a lot more. Even if
it's as trivial as stenatography (which is not really secure, simply
reasonably hidden).
>Ronald..
--
-William "Billy" Tanksley
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Moores Law (a bit off topic)
Date: Fri, 02 Jul 1999 03:07:54 +0200
[EMAIL PROTECTED] wrote:
>
>
> Really well I will teleport us 200 years into the future. RSA-128 bit
> challenges are on the block. I have my 250Ghz program running 2^64 keys
> a second... blah blah blah. Now how strong is a 256 bit key? It will
> only be another 100 years before it falls.
250GHz?
Let's see now.
At 250 GHz an electron could only travel about a millimeter, max.
Your entore CPU and memory will have to fit inside something a
millimeter in diameter.
250Ghz is about 2^37Hz. If you can check one key per clock cycle
(where go you get your figure of 2^64 from???) then you've still
got 219 bits of key to crack....you're not going to see a result
before the sun burns out.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Windows PWL Files
Date: Fri, 02 Jul 1999 14:09:38 +0200
[EMAIL PROTECTED] wrote:
>
> In article <7lfral$9ij$[EMAIL PROTECTED]>,
> "Andrew Whalan" <[EMAIL PROTECTED]> wrote:
> > Oh, this might target my required audience.
> >
> > Anyone know about the method used to generate PWL files, thus, the
> method
> > that could be used to crack PWL files.
>
> They proably use their MD4 hash code (which goes with their RC4 code)
> to hash the password.
>
Nope.
The files can be decoded in seconds so it isn't a hash.
Try a web search for "pwl cracker"
> If you want to cheat a passwd protected screen saver just delete
> the .PWL files...
>
And how do you do that if the machine is askign you for a password?
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: smoke_em <[EMAIL PROTECTED]>
Subject: Re: Moores Law (a bit off topic)
Date: Wed, 07 Jul 1999 14:51:15 +0200
[EMAIL PROTECTED] wrote:
> Currently in RC5/DES we can
> search about 2^20 keys per second (give or take) on a MII 300
> (233mhz). That would be quite a bit faster at 2^111...
> If you take rough calcs' at
> 2^20 the DES cracker program (distributed) does 233000000/2^20 or 223
> cycles per key (which is pretty amazing).
So you're talking about DES, not RC5(32/12/8). In which case the figures
are not all too impressive (no offense).
Short facts for comparison:
Pentium II 233MHz, rc5des client 2.71* (MMX DES core)
DES ~1.8 to 1.9 million keys per second. (~123-129 clocks/keys).
RC5 ~660 to ~665 thousand keys per second (~350-353 clocks/key).
(just for the 40bit -dead and buried- discussion)
At a rate of 1.85 million keys per second, it would take ~6.88 days to
completely exhaustively search 2^40 keys.
Worth the wait?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: optimizations (for feedback PRNGs...)
Date: Wed, 07 Jul 1999 19:11:00 GMT
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> wrote:
> I think you should get a few parts from Radio Shack or DigiKey and
> build it in hardware. You don't need to solder anything, wire wrap
> or a "breadboard" will work fine. You need a power supply, some
> shift registers and some XOR gates. LFSR's were meant for hardware
> implementations, building one in hardware will show you why.
> It's really lots of fun because digital electronics is much simpler
> than analog (although, you'll still blow things up when you plug
> them in backwards :-)
>
I might try that. Although parallel LFSRs are designed for software :).
I am not big into hardware (although I program MCUs from time to
time...).
BTW aren't additive PRNGS harder into hardware then software?
> Combining different length LFSR's each built in hardware will give
> you a great perspective on how things are supposed to work. Then
> translating it into software will be easier, you'll see what the
> right answer is from the "real world" device.
Well different lengths are just used as simple ways to complicate the
PRNG and maximize the period. (i.e if the lenths are relatively
prime...)
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
