Cryptography-Digest Digest #98, Volume #11 Fri, 11 Feb 00 15:13:01 EST
Contents:
Re: BASIC Crypto Question (Eric Lee Green)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
Re: RFC: Reconstruction of XORd data (Mok-Kong Shen)
Re: Newbie Encrypt question (Ralph Hilton)
Re: I'm returning the Dr Dobbs CDROM ("Bruno Liénard")
Re: I'm returning the Dr Dobbs CDROM ("abe kohen")
Re: Newbie Encrypt question ([EMAIL PROTECTED])
Re: I'm returning the Dr Dobbs CDROM (Ralph Hilton)
Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
PIII Random Number Generator ("Nick Shaffner")
Re: RFC: Reconstruction of XORd data (Jerry Coffin)
Re: I'm returning the Dr Dobbs CDROM (Paul Koning)
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: BASIC Crypto Question
Date: Fri, 11 Feb 2000 12:23:44 -0700
[EMAIL PROTECTED] wrote:
> Am I right to assume that Ciphers (Block and Stream Ciphers) work at the
> bit level , regardless of what the data structure/format is of the
> document file.
They operate upon a stream of data (whether that stream be composed of bits,
8-bit bytes, or multi-byte blocks depends upon the particular algorithm). The
actual content being encrypted is not a concern at the cipher level.
> This would imply that with the same cipher (DES, IDEA, Blowfish), I can
> encrypt documents, images ( .jpeg, .jif, .bmp ) , .wav files, email
> attachments, word documents, .xls documents, .pdf, .ps,
> .tar, .gz, .zip...whatever... is that right? The cipher only sees
> bits...
Correct.
> So for an email text with an attachment,
You are not talking about encryption here. You are talking about MIME
encapsulation of multi-part messages. If the parts of the message happen to be
encrypted files, so be it, MIME doesn't care what the contents are, it merely
hands it off to the appropriate decoder for that particular MIME type.
> Are there some ciphers more suited to say image and formated documents
> encryption, whereas others more suited to text...Or is it all bits and
> bits...nothing else to consider?
Bits are bits. About the only thing to consider is that stream ciphers
(whether implemented via a block cipher and CFB, or not) are easier if you're
talking about network streams, whereas block ciphers tend to be more secure
due to the keys issue. If you're talking files, though, a data length word at
the beginning and then chopping off the result at that # of bytes will take
care of that for block ciphers.
--
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] (Michael Wojcik)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: 11 Feb 2000 18:35:35 GMT
Reply-To: [EMAIL PROTECTED]
In article <87ohue$jt9$[EMAIL PROTECTED]>, "r.e.s." <[EMAIL PROTECTED]>
writes:
> "Michael Wojcik" <[EMAIL PROTECTED]> wrote ...
> : [re generating Latin Squares with three permutations P (one
> : column), R (an ordering of rotations of P), and T (a final
> : permutation of rows)]
> : Question: Is the inverse of a PRT-form square always itself a PRT-
> : form square? More generally, are all Latin Squares in PRT-form?
> "No" to the 2nd question -- we can see that not all
> Lsquares are of your PRT form, by simply comparing
> with the known number of Latin Squares of given order.
> Since each Lsquare created by your PRT method is the
> product of three permutations of 1..N, that method
> produces N!^3 distinct Lsquares. E.g. for N=10,
> that's ~10^20; but there are in fact ~10^25 order-10
> Lsquares. The discrepancy grows rapidly -- there're
> "only" ~10^36 PRT Lsquares of order 15, compared to
> an estimated ~10^86 total.
>
> Source:
> McKay, B. D. and Rogoyski, E. ``Latin Squares of Order 10.''
> Electronic J. Combinatorics 2, N3 1-4, 1995.
> http://www.combinatorics.org/Volume_2/volume2.html#N3
Thanks - just what I was looking for. Dan Oetting has already
supplied the construction principle for fast generation of the
inverse of a PRT square, but these questions remain interesting for
other reasons.
The relatively small number of order-256 squares that are PRT squares
(the "PRT penalty", so to speak) may not be an issue in practice,
since there are still around 10^1520 or 2^5051 PRT squares of order
256. Other weaknesses may certainly exist, but at least that's a
large enough space to make searching prohibitive. (Determining some
elements does narrow down the search, but quite a few would have to
be leaked to make the search space reasonable. Even for a PR-form
square, if we determine an entire column we have 256! possibilities
to check; if we know which column it is, 255!. That's around 10^507
or 2^1683. The T permutation certainly looks like it should make
the search effort harder, and I don't see any way it would make it
easier.)
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Against all odds, over a noisy telephone line, tapped by the tax authorities
and the secret police, Alice will happily attempt, with someone she doesn't
trust, whom she can't hear clearly, and who is probably someone else, to
fiddle her tax return and to organise a cout d'etat, while at the same time
minimising the cost of the phone call. -- John Gordon
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: 11 Feb 2000 18:41:39 GMT
Reply-To: [EMAIL PROTECTED]
In article <87q8f5$qdo$[EMAIL PROTECTED]>, "r.e.s." <[EMAIL PROTECTED]>
writes:
> "Tony T. Warnock" <[EMAIL PROTECTED]> wrote ...
> : All combiners will have to be Latin squares.
> The Latin Square combiners appear to be a subset of all
> possible combiners, corresponding to "balanced" rows &
> columns in the table; so a combiner that's an Lsquare
> might be *better* than one that's not, in some context,
> but not all combiners need be Lsquares, as far as I can
> see in common usage of the term. (But it does seem that
> to be a combiner it must allow for later recovery of the
> message -- resulting in N!^N possible NxN combiners.)
> [example snipped]
> yields a combiner -- but not a good one, since a given message
> symbol will result in an output independent of enciphering
> symbol. Whether less-extreme non-balanced (i.e. non-Lsquare)
> combiners are ever desirable -- that would seem to be another
> question.
It's an interesting idea, since a non-balanced combiner (as you or
someone else pointed out in an earlier post, which unfortunately I've
misplaced) lets you retrieve the message but not (completely) the
key. There are potential advantages to a scheme which prevented
retrieval of the key even with plaintext-cyphertext pairs - it would
keep that particular key secret even if some messages were exposed.
It would mean that more than one key could be used to decode a
message, but given a sufficiently large keyspace relative to the
amount of key equivalency, that might not be a problem.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
This is a "rubbering action game," a 2D platformer where you control a
girl equipped with an elastic rope with a fishing hook at the end.
-- review of _Umihara Kawase Shun_ for the Sony Playstation
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 20:40:29 +0100
Mok-Kong Shen wrote:
>
> Ian Clarke wrote:
> >
>
> > The algorithm is simple, I take the initial data, and XOR each byte with
> > the previous byte (the first byte is left unchanged). This moves
> > forward through the string compounding the XOR at each stage (ie. each
> > byte is actually XORd with all previous bytes).
> >
> > The following piece of java does this: (Data is in char[] strC):
> >
> > for (int x=1; x<strC.length; x++)
> > {
> > strC[x] ^= strC[x-1];
> > }
>
> This is a form of what is in classical terminology termed auto-key
> encryption. One can simply try all possible values of the first byte
> to decrypt.
Addendum: In the present special form, the 'key' is known, namely
the first byte.
M. K. Shen
------------------------------
From: Ralph Hilton <[EMAIL PROTECTED]>
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 20:27:37 +0100
Reply-To: [EMAIL PROTECTED]
On Fri, 11 Feb 2000 14:05:45 GMT, [EMAIL PROTECTED] wrote:
>I've been looking into data encryption lately. I want to write my own
>simple encrypt program (C/C++). From what I understand one way to
>encrypt is to shift the underlying binary data and then Xor it with a
>password. Question I have is where the heck to you store the
>password???
You send it in your message encoded with a pre-establised paired key.
>Example, say I encrypt a paragraph and the password I use is "mypass".
>This would be used for the xor part. Now when I send it to my friend
>and he brings up the program to de-crypt it he has to use "mypass". But
>in order for my program to verify the password is correct it would have
>to be stored in the file. That doesn't seem very safe. Any ideas?
>
>Thanks in advance
You have asked the question that was the hardest before 1976.
I would suggest experimenting with pgp then downloading the pdpsdk.
That many toys will keep you busy for ages as it has done me.
------------------------------
From: "Bruno Liénard" <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Fri, 11 Feb 2000 19:46:43 GMT
Strange ! I have the first edition of the cd-rom. The text is not in PDF
format, but (I think) in SGML. The good news are that you can very easily
export the text, the bad news are that the text is NOT formatted and the
book are almost unreadable. I even thought to buy another copy of the second
edition.
Bruno Lienard
Victor Zandy <[EMAIL PROTECTED]> a écrit dans le message :
[EMAIL PROTECTED]
>
> A couple weeks ago I asked for opinions of the Dr Dobbs CDROM
> collection of cryptography books. Overwhelmingly the response was
> positive, so I bought it. (Thanks again to those of you who replied.)
>
> I am returning the CDROM because it is not suitable for printing.
> For example, to print chapter 1 of the Stinson book (44 pages) Adobe
> acroread (x86/Solaris 2.6) creates a 500MB postscript file. I cannot
> print this file directly, probably because it is too big. Although I
> might be able to find a way to print the file, at 500MB it would take
> too much time.
>
> I don't know how the PDF files on the CDROM were prepared, but
> they look like they were scanned from physical book pages. For recent
> titles, like Stinson, they should have been generated from the
> computer originals to make a smaller file, with better image quality.
>
> Several people who responded to me said they appreciate being able
> to search and cut-and-paste the text on the CDROM. For those
> features, and for anyone who doesn't mind reading books from computer
> displays, the CDROM is a great deal. But it is useless for printing
> paper copies of its contents, even a tiny amount.
>
> Vic Zandy
>
>
>
>
>
>
------------------------------
From: "abe kohen" <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Fri, 11 Feb 2000 14:34:01 -0500
I apologize for posting this to sci.crypt, but since some of you expert PDF
people are reading this, I wonder if you can help me.
Too often when trying to print a PDF (Acrobat Reader 4.0) file under Win98
to a HP LaserJet 4ML printer (with Postscript Level 2 selected), the file
(typically 400 KB) spools to the printer, but never prints.
By selecting Print As Image, I get a 3MB file that prints.
Is it my 4ML postscript driver? Or has Adobe made changes in PDF that are
not backwards compatible?
Thanks (with mega apologies),
Abe Kohen
"Paul Crowley" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jerry Coffin <[EMAIL PROTECTED]> writes:
> > You wouldn't find it in any case, at least not without doing some
> > decoding. The reason PS files are around double the size of PDF files
> > as a rule is that PDF files are normally compressed using LZW.
>
> A minor nit: PDF uses Flate, which is pretty much the same as gzip.
> And it's individual objects that are compressed rather than the whole
file.
> --
> __
> \/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
> /\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Newbie Encrypt question
Date: Fri, 11 Feb 2000 19:36:15 GMT
So the general response from my question is that the crypt I was
planning on using is very very weak. I thought that the standard 56bit
key encryption (which was cracked) was based on this theory though?
Even though it is no longer considered good anymore, it was at one point
and I thought it would be good enough for me.
So am I wrong in assuming that the 56bit key encription standard was
based on shifting/xoring?
And last but not least, what do you guys suggest using instead. Keep in
mind I want to code it myself as opposed to using/buying an ocx.
Thanks again for all the help
> I'll note, however, that anytime you store ANYTHING that verifies
> entry of the correct password, you're giving information away to an
> attacker, making it easier to break your encryption. OTOH, the form
> of encryption you're suggesting is so weak that this doesn't really
> matter in any case -- it can be broken in a fraction of a second on a
> modern computer. In fact, with my old 386/20, it still only took a
> second or two to break as a general rule.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Ralph Hilton <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Fri, 11 Feb 2000 20:46:07 +0100
Reply-To: [EMAIL PROTECTED]
On 11 Feb 2000 16:02:18 GMT, [EMAIL PROTECTED] wrote:
>Vernon Schryver <[EMAIL PROTECTED]> wrote:
>
>> Is there any evidence for the theory that the CDROMs contain only scanned
>> images besides the size and poor quality of the printed images and the
>> difficulty of printing individual pages? Has anyone used something like
>> `strings` or even `emacs` to look for ASCII text? Has anyone asked DDJ?
The original problem was printing the pages from the CDROM.
When I load a file into acrobat and print it gives an option of which and
how many pages to print.
So one prints as many pages as one's computater can handle. What's the
problem?
Who gives a flying monkey's goulies about the format.
Just click on the little picture at the top of the screen of a printer and
when the dialogue comes up try 10 pages. If that is ok then next time try
20. If it don't work then try 5.
Shit do I have to send my pal Bill Gates over to edumucate you!!!
------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: 11 Feb 2000 18:51:36 GMT
Reply-To: [EMAIL PROTECTED]
In article <87sjl9$uc2$[EMAIL PROTECTED]>, zapzing <[EMAIL PROTECTED]> writes:
> OK, I posted about this before but apparently
> I just did not make myself clear, or something,
> so I will try again (assuming that the
> moderators will be patient with my lack of
> communication skills).
Sorry - I meant to respond to your post but lost it. I tend to run
a bit behind on news reading.
(sci.crypt is an unmoderated group. sci.crypt.research is
moderated.)
> You do *not* need a latin square,
> because what you refer to as the
> encyphering symbol never needs to be
> recovered. The only thing you ever really
> need to do is recover the message symbol
> from the combined symbol.
Yes, and this is an interesting idea - see my response to an
earlier post by r.e.s.
> This sort of combining function would
> be much easier to do than making a
> latin square, and there are more
> possibilities also, so why would you
> need a latin square? That was not
> a rhetorical question , I really
> do want to know why, if you would
> be so kind as to clue me in.
Well, I'm not convinced it's "much easier to do than making a latin
square", since we're discussing a fast construction procedure for a
subset of Latin Squares. I don't offhand see a significantly faster
way of producing nonbalanced combiners in this form (with the same
memory savings as the PRT method I proposed).
But to answer your question: I don't think anyone's made any very
strong arguments for using Latin Squares as combiners yet (in this
thread). Terry Ritter has made some suggestions in that direction,
but at the moment most of us are just playing with the idea.
Personally, I'm not persuaded we need new combiners at all, as far as
practical cryptography goes. Existing methods certainly look good
enough for *my* purposes; those with more stringent threat models may
be looking elsewhere, but the state of public crypto is such that
inventing new encypherment methods doesn't appear to be a priority.
This is just a mental exercise, as far as I'm concerned. Others may
feel different, of course.
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
If Mokona means for us to eat this, I, a gentle person, will become
angry! -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_
------------------------------
From: "Nick Shaffner" <[EMAIL PROTECTED]>
Subject: PIII Random Number Generator
Date: 11 Feb 2000 14:53:02 EST
So did the PIII ever ship with that cryptographic quality RNG that they
promised? If so, anyone know where I can find information on getting access
to it? www.intel.com doesn't seem to mention anything about it, and a
couple of web searches didn't turn up anything...
Nick
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: RFC: Reconstruction of XORd data
Date: Fri, 11 Feb 2000 13:01:00 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Hi,
>
> In an attempt to split data into several parts in such a way that each
> part would be useless without the others, I came up with a simple
> algorithm which I would like to expose to public scrutiny.
Unless I'm missing something, this doesn't really qualify as
encryption at all, but merely obfuscation. IOW, there's no key
involved -- there's only a deterministic algorithm, and the only way
you get any security at all is if the algorithm is secret. Generally
speaking, that's considered an untenable assumption.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: I'm returning the Dr Dobbs CDROM
Date: Fri, 11 Feb 2000 15:04:12 -0500
[EMAIL PROTECTED] wrote:
> ...
> On the other hand, I differ with your final conclusion. I'm very
> happy with this CD-ROM. I can't imagine buying this to print out
> whole chapters or whatever.... if you want good quality printouts,
> buy the books! For quick reference though it's great. In my
> briefcase I can carry the DDJ CD-ROM, the about 20 years of CRYPTO and
> EuroCrypt proceedings (CD-ROM available through Springer-Verlag),
How did you get that one? I tried to order it via their website, and
the order was redirected to some random company I'd never heard of
somewhere in the US, and I've never heard anything since.
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
******************************
