Cryptography-Digest Digest #560, Volume #13      Fri, 26 Jan 01 16:13:01 EST

Contents:
  Re: Dynamic Transposition Revisited (long) (AllanW)
  Re: What do you do with broken crypto hardware? (David Schwartz)
  Re: What do you do with broken crypto hardware? (David Schwartz)
  Re: Dynamic Transposition Revisited (long) (AllanW)
  Re: Paranoia (William Hugh Murray)
  Re: Encryption Program (Richard Heathfield)
  Re: Q: File Extension .$#! - Which Encryption Program?!? (Jim Gillogly)
  Re: History Question: signatures in nuclear test ban verification? (Doug Stell)
  Re: Dynamic Transposition Revisited (long) (Richard Heathfield)
  Re: Encryption Program ("Joseph Ashwood")
  Re: Steak Stream Cipher ([EMAIL PROTECTED])
  Re: Dynamic Transposition Revisited (long) (John Savard)
  Re: Dynamic Transposition Revisited (long) (John Savard)
  Re: Dynamic Transposition Revisited (long) (John Savard)
  Re: Dynamic Transposition Revisited (long) (John Savard)
  Re: Random stream testing. (long) ("Paul Pires")
  Re: Q: File Extension .$#! - Which Encryption Program?!? (Thomas Propst)

----------------------------------------------------------------------------

From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:04:24 GMT

"Matt Timmermans" <[EMAIL PROTECTED]> wrote:
> In all likelyhood, that would be a very practical generator for OTP
keys,
> and it would be reasonably easy to purposely underestimate the amount
of
> entropy you're getting.  If you want proof, though, you should do
something
> different.  For instance:
>
> Generate a photon, and polarize it vertically.  Then measure its
> polarization at 45 degrees from the vertical.  Repeat.
>
> By measuring the transparency of your optics, the sensitivity of your
> photomultipliers, and the orientation of your polarizers, you can
place a
> very confident lower bound on the rate of real randomness.

I think I missed one of my classes when I learned programming.
Could you please show me the code corresponding to "generate a
photon?" Use any well-known computer language -- ADA, APL,
BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
comfortable with. I just need to see the basic algorithm for
"generate a photon."

Wait, I think I see a photon now -- no, it's gone. I probably
just imagined it.


--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com
http://www.deja.com/

------------------------------

From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 12:19:48 -0800


Nicol So wrote:

> I'm not familiar with your application, but it sounds dangerous if the
> application host is completely insecure. Besides preventing someone from
> extracting secrets from the security module, don't you want to control
> how the module's functions are exercised, and who can exercise it? I
> suspect that you need to provide some level of security to the host
> anyway.

        I think you're missing the entire point of having a secure module. The
point of the module is to isolate failures. That is, with a secure
module, the worst case scenario for a compromised host is supposed to be
that they can perform encryptions and decryptions for as long as the
host is compromised. If the keys themselves are accessible through a
compromised host, then a compromised host equals a compromised key. That
defeats the purpose of having the module.

> Let's assume that the encrypted keys are fairly well protected so that
> there's a low but non-zero probability that an adversary can get to it,
> but without physical access it is impossible to extract the secrets from
> the security module. For adversaries coming in from a network, their
> lives are not made easier. For insiders such as bad admins, their
> attacks are not made harder, but not easier either. For the module
> manufacturer as an adversary, who's best positioned to defeat/bypass the
> module's physical security, they now have an additional barrier to
> overcome. That may be an improvement.

        That's a big step down in security from what the module is supposed to
provide.

        DS

------------------------------

From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 12:17:11 -0800


Paul Rubin wrote:

> This doesn't make sense--the whole point of the tamper resistant
> module is to securely store keys internally.  Any keys stored outside
> the module are vulnerable to copying and therefore must be encrypted;
> but then in order to load them into the module, the decryption key
> must be stored inside the module.  So if the module is sent back to
> the manufacturer, all the keys are potentially compromised.

        Yes, you can't have it both ways. If the module can decrypt the keys,
then you're not safe from anyone who has both the module and the
encrypted keys. If you are assuming that you can store the encrypted
keys anywhere because they're encrypted, you can't give the module to
the manufacturer. If you're treating the encrypted keys as keys
themselves, and they're stored outside the module, how does the module
help you stay secure?

        DS

------------------------------

From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:22:00 GMT

In article <[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (John Savard) wrote:
> On Tue, 23 Jan 2001 20:19:18 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
> in part:
>
> >I think you should first plainly describe what you see as the
> >weakness, before rushing on to try to fix it.
>
> I will do so. In fact, however, I already did so, I thought, in
> another post to which you have just replied, but it looks as though my
> point didn't get across.
>
> The "weakness" is:
>
> The set of permutations of n bits
>
> considered as a subset of the set of one-to-one and onto mappings from
> the set of bit-balanced blocks of n bits to itself
>
> is a subgroup of those mappings, and therefore is not a generator of
> the entire set of mappings.
>
> My "fix", therefore, is to propose another operation that can be
> applied to a bit-balanced block to yield a bit-balanced block, so as
> to allow a cipher acting on these blocks to produce a wider assortment
> of mappings.
>
> Essentially, I quite agree that transposition as applied to
> bit-balanced blocks is *better* than XOR. But since there already are
> substitutions that are considerably better than XOR, the fact that DT
> is a fixed amount better than XOR is not terribly attractive,
> considering that substitutions can be made as complex as desired.
>
> Essentially, therefore, I see DT as similar to, say, DES with subkeys
> that are generated by a stream cipher. Yes, DES, even with arbitrary
> subkeys, can't produce all (2^64)! mappings of blocks to blocks; but
> transposing bits can't produce all mappings of the entire set of
> bit-balanced blocks to itself _either_.

I don't know about Terry Ritter. I for one now understand what
your point is.

But how do you come to this conclusion? The very definition of a
shuffle is that all permutations of the input are possible as
output, right? So is there some combination of bit-balanced
input and bit-balanced output of the same size, that can't be
created by a shuffle with some input from a PRNG?

To take an extremly small example: a 16-bit block could contain
any of 1170 different values, starting with 0000000011111111
and ending up with 1111111100000000. Any bit-shuffle would also
produce one of these 1170 values. Is one of the 1170 possible
values impossible to reach by shuffling?

> So my point is: DT is not as bad as XOR, but it is not as good as what
> people can, and do, do with substitution. Although perhaps saying they
> really do make such use of substitution is perhaps an exaggeration;
> except for some of your advanced designs, there isn't that much out
> there which approaches my "large-key brainstorm" - which, I think, in
> the substitution world, strongly resembles what Dynamic Transposition
> achieves.

--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com
http://www.deja.com/

------------------------------

From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Paranoia
Date: Fri, 26 Jan 2001 20:28:00 GMT

JCA wrote:

> Simon Jenkins wrote:
>
> > I have just read Stven Levy's book 'Crypto' and was again struck by the
> > description of the meeting between Whitfield Diffie and James Ellis.
> > Ellis' parting comment has him saying to Diffie, "You did more with it
> > than we did."

I have not read the book either, however the context would indicate that they
were not talking about RSA but about public key cryptography which GCHQ and NSA
now both claim to have invented.

As I have suggested elsewhere, if you do not publish contemporaneouly, all such
claims ring hollow.  If you have your hands on a significant invention and you
do not exploit, then the implication is that you did not appreciate its
significance.  Given their missions, one can believe that GCHQ and NSA might
have invented public key cryptography and elected to keep it a secret.  It is
much tougher to believe that they invented it and never ever used it a way that
left evidence of such use.

Even if they invented it, their invention did not make a difference.  Diffie
and Hellman's invention of asymmetric key cryptography changed the world
forever.

>
> >
> > As an Englishman, this is an interesting phrase - it implies that GCHQ
> > don't bother with RSA any more. If they were still using it, Ellis would
> > have said, "You've done more with it than we have."

If you take the context of the quote to be public cryptography, then it makes
sense....

>
> >
>
>     Not having read the book I am somewhat in the dark here - I thought
> that Whitfield Diffie had nothing whatsoever to do with RSA.

Except of course to start the process that led to it.

> > Paranoia now sets in. If GCHQ aren't interested any more, it means they
> > can break it. If they can break it, they've cracked fast factoring.

One might so infer but I do not think that the quote implies it.  They did not
do anything with public key; if that was the context it would imply nothing
about RSA.  The ability to crack RSA does not imply fast factoring.  We know
that fast factoring lowers the cost of attack against RSA.  We do not know that
there is no other process for doing that.

>     I, for one, don't believe it. On the other hand, I would easily believe
> that
> it would be in the interests of such an organization to spread rumours and
> innuendo about what it can or can't do.

Ah, well.  That is the problem of being in the disinformation business isn't
it?  Even when one tells the truth one cannot expect to be believed.  It is
even inherent in being in the eavesdropping business.  We will know that GCHQ
really invented public key only after we know whether or not John Wilkes Booth
had collaborators, who killed JFK, and who won Florida.  Some things are simply
not within the realm of the knowable.

William Hugh Murray, CISSP



------------------------------

Date: Fri, 26 Jan 2001 20:31:39 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Encryption Program

Benjamin wrote:
> 
> Hello,
> 
>      My name is Benjamin and currently our company is looking for a
> command line based encryption program that we can automate.  I
> understand that certain tools exist under various *nix operating
> systems.  Unfortuantly, under the circumstances that we are in we are
> only able use this program in a Windows based environment.  Does such a
> tool exist in the windows environment?  If so, where might i find this
> program?  I have done various searches on the internet and on security
> sites and have had no such luck.  Any information that may be passed
> along is greatly appreciated.  Again, many thanks in advance!


Why not check out Twofish? http://www.counterpane.com/twofish.html last
time I checked. Full source code, patent-free. AES finalist. No known
breaks. Lost out to Rijndael (the winner) in AES because it was slightly
slower, not for any security reason as far as I know.

If I recall correctly, it's in ISO C (or at least a reasonable
approximation thereto!), and therefore should compile just fine under
Windows, using any reasonable compiler. Also, when you eventually get
fed up of spending money on operating systems, you'll be able to port
Twofish relatively easily to Linux. :-D

-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

------------------------------

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Q: File Extension .$#! - Which Encryption Program?!?
Date: Fri, 26 Jan 2001 12:38:08 -0800

Thomas Propst wrote:
> 
> sorry to bother you, but does anybody know?

I don't, but in trying to find the answer I ran across a web page
of file extensions that answers lots of <other> questions like this,
and I just had to share it:

http://www.cknow.com/ckinfo/acronyms/fileextensions.htm

What are the first dozen bytes of the file's contents?  Sometimes that
will help.  On which platform did you find the file?

-- 
        Jim Gillogly
        Sterday, 5 Solmath S.R. 2001, 20:23
        12.19.7.16.11, 10 Chuen 14 Muan, Seventh Lord of Night

------------------------------

From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: History Question: signatures in nuclear test ban verification?
Date: Fri, 26 Jan 2001 20:23:00 GMT

On Fri, 26 Jan 2001 16:58:15 +0100, Gerard Tel <[EMAIL PROTECTED]>
wrote:

>Is it true that digital signatures were used in devices for the
>verification of nuclear test bans between the USA and the USSR,
>like SALT-1 etcetera?  This should have been around 1980.  I would
>like to have references about this.

I remember seeing some proposal to this effect in the early 80's. It
contained some requirements for a system of reporting seismic events
between mutually suspicious parties. Seismic devices were that could
be trusted by both parties would be planted on both partyies' soil.
Some of the requirements I remember seeing are the following.

1. It had to be suitably unclassified cryptogrphy, since it was given
to a potential enemy.

2. Either party could implement it. (It was expected that each country
would implement monitoring devices on its own soil and forbid the
other country from planting the devices on its soil.)

3. Each party could verify the implementation done by the other party
and, thus, have faith in the reporting devices.

4. Neither country could forge data that appeared to come from a
device in the other country.

5. Each country could trust the other country's device.

Obviously, some of the requirements were standard digital signature
stuff. I have no idea what, if any thing, was implemented. At the time
I saw the proposal, RSA was the only uable algorithm in the public
knowledge.


------------------------------

Date: Fri, 26 Jan 2001 20:36:22 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)

AllanW wrote:
> 
> "Matt Timmermans" <[EMAIL PROTECTED]> wrote:
<snip>
> >
> > Generate a photon, and polarize it vertically.  Then measure its
> > polarization at 45 degrees from the vertical.  Repeat.
> >
<snip>
> 
> I think I missed one of my classes when I learned programming.
> Could you please show me the code corresponding to "generate a
> photon?" Use any well-known computer language -- ADA, APL,
> BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
> comfortable with. I just need to see the basic algorithm for
> "generate a photon."

It's easy enough in C. Use a switch statement.

;-)

-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

------------------------------

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encryption Program
Date: Fri, 26 Jan 2001 12:36:25 -0800

Find a copy of PGP 2.6x it has a command line interface for windows. I
believe there is also a command line interface on newer versions, but I'm
not completely sure.
                    Joe

"Benjamin" <[EMAIL PROTECTED]> wrote in message
news:94sjm4$933$[EMAIL PROTECTED]...
> Hello,
>
>      My name is Benjamin and currently our company is looking for a
> command line based encryption program that we can automate.  I
> understand that certain tools exist under various *nix operating
> systems.  Unfortuantly, under the circumstances that we are in we are
> only able use this program in a Windows based environment.  Does such a
> tool exist in the windows environment?  If so, where might i find this
> program?  I have done various searches on the internet and on security
> sites and have had no such luck.  Any information that may be passed
> along is greatly appreciated.  Again, many thanks in advance!
>
>
> Benjamin Branch
>
>
> Sent via Deja.com
> http://www.deja.com/



------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Steak Stream Cipher
Date: Fri, 26 Jan 2001 20:44:31 GMT

In article <OcFCq#8hAHA.327@cpmsnbbsa09>,
  "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> ... the code is at least semi-optimized.

The code is more or less as optimized as it can be with the 486-
processor code available in Borland Inline Assembler and is designed
with a time/memory trade off to fit server systems with many
simultaneously active connections. You are welcome to improve it, I
spent a week or so just substituting registers and instructions to see
how fast it would run on different Pentium and AMD processors. Surely,
I might have missed something.

>While optimized code is very useful, I too would
> like to see a very strictly done mathematically expressed
specification,
> with accompanying unoptimized code. We can all supply large
quantities of
> examples if you need us too (I'd suggest the AES finalist
specifications,
> and the cryptonessie specifications).

Thanks, I have read the TwoFish and Rijndael docs thoroughly already.
Hence, I have no valid excuse for not documenting the cipher properly.
I promise it will be in due time - right now I am working on the NIST
pseudo random test results and a demo app for that purpose. Meanwhile,
have a look at http://www.streamsec.com/salgo.asp for a fairly proper
specification of the _Encrypt procedure algorithm.


Sent via Deja.com
http://www.deja.com/

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:01:27 GMT

On Fri, 26 Jan 2001 09:07:03 -0800, "Paul Pires" <[EMAIL PROTECTED]>
wrote, in part:

>I'm confused. Wouldn't this produce alternately biased blocks in an
>alternating fasion?

Yes, and they would therefore add up to a balanced total.

>I also am not clear on the goal. Yes there needs to be bit balancing so that
>a bias in the input is not recognizable in the output but by doing this
>hiding,
>don't you sacrafice another valuable property? Seems like the output would
>fail a taylored randomness test. You are going to get data that has a
>prefect
>distribution of zero's and ones within a block and something else if the
>block
>reference is displaced. Right?

The property of bit-balancing is _essential_ if Dynamic Transposition
is to work; otherwise, some information about the plaintext *will not
be encrypted at all*.

Thus, the bits are not balanced in order to remove bias from the
input; except that, being a transposition, it doesn't change the
number of 1 and 0 bits, it is expected the cipher will be secure
enough to conceal bias in the input, just as ciphers like DES are
expected to do that.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:43:15 GMT

On Fri, 26 Jan 2001 20:22:00 GMT, AllanW <[EMAIL PROTECTED]> wrote,
in part:

>To take an extremly small example: a 16-bit block could contain
>any of 1170 different values, starting with 0000000011111111
>and ending up with 1111111100000000. Any bit-shuffle would also
>produce one of these 1170 values. Is one of the 1170 possible
>values impossible to reach by shuffling?

No. And not one of the 2^64 possible outputs is impossible to reach by
DES, either.

But Terry Ritter appears to be criticizing DES because some of the
(2^64)! possible overall substitutions are impossible to reach.

Well, by shuffling, I can't reach a total overall pairing of bit
balanced inputs to bit balanced outputs such that

0000000011111111 -> 1111111100000000

and

0000001010111111 -> 0000000011111111

so it's the 1170! possible overall correspondences of input to output
that can't all be reached.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:03:09 GMT

On Fri, 26 Jan 2001 20:15:55 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:

>Would you kindly explain what HIPPI is and why one needs
>balancing there? Thanks.

Many forms of modulating data for transmission, or for recording on
magnetic media, remove or minimize the DC component to allow the
circuitry required to be simpler, as DC components of electrical
signals present difficulties.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:40:00 GMT

On Fri, 26 Jan 2001 20:04:24 GMT, AllanW <[EMAIL PROTECTED]> wrote,
in part:

>I think I missed one of my classes when I learned programming.
>Could you please show me the code corresponding to "generate a
>photon?"

heh

I think we can safely assume that special hardware is required for
this particular method of producing randomness.

In fact, that's true of *any* physical means of generating random
numbers, even if you use what is built in to the support chips of the
Pentium III.

John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Fri, 26 Jan 2001 12:52:31 -0800


Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
news:upKb$q8hAHA.349@cpmsnbbsa09...

First off, thank you for the complete and thoughtfull reply. I
am getting much more out of this than I thought I would when
I posted. Mind if I ask a few more questions?

<Snip>
> Well RNG output has 1 bit of entropy per bit, (Deterministic)PRNG output
has
> a fixed k bits of entropy scattered throughout the infinite output
(although
> the entropy in a given bit is likely to diminish to true 0 near the end
> versus near the beginning).

Is there any test that detects this difference in blind data? I believe that
you
said no but I just wanted to verify.

> >
> > There is also a need for a qualitative measure for all tests. There
> > are no universal units for discussing performance. Right now
> > someone can say "I did not fail Diehard or NIST suite or ent" but
> > one cannot say that they passed or by what margin.
>
> How do you pass a test that you MUST fail a certain percentage of the time
> to actually pass it?

Good way to look at it.

>
> > Perhaps
> > there is a way where an analog result rather than the digital
> > Pass/Fail can be constructed. If this where done, apples to apples
> > evaluation of different sources could be evaluated where their
> > relative strengths and weaknesses could be compared in detail.
>
> Not really, I actually went through this a few months ago to attempt to
get
> a good handle on the requirements for a specification. Several of us
> considered a massive number of variables, and we simply could not reach a
> conclusion that did not require infinite resources of one kind or another.
> We gave up and said 1000 DIEHARD tests of 100MB series all consequetively
> done with keying controlled by the testers, and they must fail each test
at
> least 3 times, and no more than 80 times. You know what we found, we
> couldn't find any PRNGs that passed our criteris consistently, because we
> naturally scaled it up for actual testing (I think we went with 5 of 9 or
> something equally pointless). When we spec'd it we didn't think the bar
was
> raised too far.

Did you folks run any data collected from some true random source as a
control? Did it perform similarly to PRNG's as far as "passing your
criteria"
goes?  I have found that it is real hard to raise the bar just high enough
so
that there is a distinction between otherwise "Good" generators. Maybe it
is not possible but I still have some subborn pig-headed bumbling about to
do before I stop looking.

>
> > this information would help in correlating certain structures and
> > actions to behaviors.  It could also serve as a basis for and monitor
> > of confidence. Rate the methods that have been hacked based on
> > the PRNG. Rating these PRNG's against the field should yield
> > fascinating results regardless of how they turn out. A web page
> > where every known PRNG or RNG gathering scheme could be
> > listed with it's performance to various tests, at different
sensitivities
> > would be pretty neeto.
>
> But how do you judge it's performance, like I said a true random source
MUST
> fail the test a certain percentage of the time.

I had in mind a pyramid scheme. Forget pass-fail. You are right, it is not
relevent passed a certain point.

The idea was to find a "third order" test to do on the "second order data"
that might show something telling. The Idea came about from my mechanical
engineering experience. I saw some folks trying to figure out why a
transmission failed by looking at graphs of velocity. It all became clear
when
these data sets were post processed by finite difference to graph
acceleration
and jerk. look for "goodness of fit of the whole result set" regardless of
the
actual result values.

Besides, doing this examination has led me to spot what I think are 3 flaws
in some of the tests that are recomended often. Usefull or not, it seems to
be a good dicipline.

>
> > Don't wake me up, It is such a lovely dream.
>
> The sad part is, many of us have tried to get close to that dream, we just
> haven't made it, and it might not be possible.
>                                 Joe

Well, misery loves company. I'm not having fun yet but I keep poking.

Paul




====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

------------------------------

From: Thomas Propst <[EMAIL PROTECTED]>
Subject: Re: Q: File Extension .$#! - Which Encryption Program?!?
Date: Fri, 26 Jan 2001 21:52:52 +0100
Reply-To: [EMAIL PROTECTED]

the file is a win9x file, starting with the following bytes:

16 73 16 4e 1d bb 24 ca 7e 0b 87 f8 94 4d 42 3b 9f 42 68 b3 fe aa 43
52 f0 22 6e b9 cb e4 ff b5 ...

the full extension is .doc.$#!, so i guess it's a somhow encrypted
winword document.

i have another file of this type, but there are no identical bytes at
the beginning, so i guess it's not some kind of bit-shifting or that
easy kind of encryption, since word-files (of the same version) are
always starting with the same byte-sequence (i think so).

tom.


On Fri, 26 Jan 2001 12:38:08 -0800, Jim Gillogly <[EMAIL PROTECTED]> wrote:

>Thomas Propst wrote:
>> 
>> sorry to bother you, but does anybody know?
>
>I don't, but in trying to find the answer I ran across a web page
>of file extensions that answers lots of <other> questions like this,
>and I just had to share it:
>
>http://www.cknow.com/ckinfo/acronyms/fileextensions.htm
>
>What are the first dozen bytes of the file's contents?  Sometimes that
>will help.  On which platform did you find the file?


------------------------------


** 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
******************************

Reply via email to