Cryptography-Digest Digest #797, Volume #8 Thu, 24 Dec 98 22:13:02 EST
Contents:
Re: Enhancement of EBC mode? (Terry Ritter)
Re: Rules of the game (wtshaw)
Session keys in Elliptic Curve (Anonymous)
Re: ZIP encryption safe? (Jim Dunnett)
Re: Encryption Basics (Jim Dunnett)
Re: Stego in jpeg files (Jim Dunnett)
VPN Network -- South Pacific ("MH")
Re: Cryptography FAQ (01/10: Overview) (Karl-Friedrich Lenz)
Re: Hashing for randomness (Logi Ragnarsson)
Re: coNP=NP Made Easier? (rosi)
Re: Q: Is there security in unusual RSA key lengths? (Matthew Skala)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Enhancement of EBC mode?
Date: Thu, 24 Dec 1998 19:28:31 GMT
On Thu, 24 Dec 1998 17:08:44 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>
>>Let me point out that it can be a serious mistake to build a system
>>which uses a file position in encryption. For example, if the file is
>>any form of database, it could not then be re-organized, nor could new
>>blocks be "inserted" in the middle. So while this solution may be
>>fine for reading static files or ciphering absolute storage, that same
>>approach may be inappropriate in a dynamic database.
>
>>One alternative is to store a "block number" value along with each
>>block so that it travels with the block. But it would be easier to
>>just save an IV for each block.
>
>For the application discussed, altering the data to obscure patterns
>by XORing each block with its absolute address need not create a
>problem;
>
>data is decrypted whenever it is read, and it is encrypted whenever it
>is written.
>
>If an application *not authorized to read the data* were, nontheless,
>permitted to re-organize the data, then there would be a problem. This
>situation, though, does not occur in many applications: in some, for
>example, without the decryption key, not only does one have no idea
>where record boundaries are, one also does not know which blocks
>belong to a file.
>
>Just as in networks there is a difference between end-to-end
>encryption and link-to-link encryption, whole-disk and whole-file
>encryption can do certain things, and record encryption can do others.
>
>So one could use CBC mode within a record, and one could use the XOR
>of an address relative to the start of the file for file encryption,
>and one could use the XOR of a track and sector address for disk
>encryption without a problem.
>
>Someone with the disk encryption password only could still copy the
>file to another disk without destroying it;
>
>someone with the disk encryption password and the file encryption
>password could move records within the file;
>
>and someone with all three keys could modify and read data within a
>record.
>
>So it depends on the level where encryption is used what measures are
>available to mask against codebook attacks without preventing random
>access.
Yes, an encryption sensitivity to physical storage location can be
hidden by deciphering on every read, then enciphering on every write,
but this can have both significant costs and unexpected risks.
Consider, for example, the case of disk encryption, where the
plaintext is randomized by a track / sector hash. Inevitably there
will come a time when we wish to upgrade storage with a new drive.
Now, upgrading can be tedious even when we do just a straight copy
from drive to drive. But when the encryption depends upon the track /
sector position, we have to read each "block," decipher it, decide
where to put it, then re-encipher the block on the new drive. This is
a significant overhead at a bad time, and incidentally implies the
transient exposure of the data as plaintext.
Worse, the inability to simply copy sector contents to new store is a
mortgage on the future and a risk of failure to intervene, since
automatic upgrade utilities will only copy sectors and change file
pointers. So if there comes a day when the encrypted data is
forgotten and the storage upgraded (which can be as simple as being
away on a trip), the data will simply become usable. This is not a
risk of losing a record or two; this is the risk of losing an entire
database, with everything inside, and all the effort it took to
construct.
But these costs need not be paid and the risks need not be taken if we
don't first design a system which depends upon physical storage values
which may change in the future. And there are similar overhead and
transient exposure problems with respect to the reorganization of
database storage within files, when encryption depends upon file
position.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Rules of the game
Date: Thu, 24 Dec 1998 12:42:19 -0600
In article <75pklh$[EMAIL PROTECTED]>, Karl-Friedrich Lenz
<[EMAIL PROTECTED]> wrote:
>
> ...the analyst wins with any result
> breaking the design with less work than the designer thought necessary,
even if
> that is still impossible in the real world.
>
Who says the designer cared to think about that sort of problem in the
first place? The problem of forcing people to be winners or losers is
really a restatement of all-or-nothing thinking, which can miss the
circumstances altogether. The same goes for guilty or innocent, right or
wrong, good or bad, or intelligent vs. non-intelligent. Things are
usually more complex.
A designer can win by learning through mistakes, and lose by not finding
out about mistakes a cracker missed. Productive cracking efforts cause no
losses if all benefit by the efforts of any who design and any who break
algorithms if the state of the art is improved. It is important to
convince those who make blunders that much learning is based on tragic
errors; it matters more what comes after them.
--
What goes around, comes around.
You reap what you sow.
Do unto others as you would have them do unto you.
The wheels of the gods grind most slowly, but exceedingly fine.
People in glass houses should not cast stones.
Let those who are without sin cast the first stone.
Judge not that ye be judged.
------------------------------
From: Anonymous <[EMAIL PROTECTED]>
Subject: Session keys in Elliptic Curve
Date: 24 Dec 1998 20:37:46 +0100
=====BEGIN PGP SIGNED MESSAGE=====
RSA, DH and ElGamal act as enveloping mechanisms in the
transport of the session key for a bulk cipher in most
PK-cryptosystems. But what about Elliptic Curve? In a
cryptosystem using Elliptic Curve as the key exchange
algorithm, does it merely act as an enveloping mechanism
for the session key, or does it play part in the generation
of the session key and thus achieve the exhange of the key?
If it doesn't, the conventional way to generate session
keys is to take output of PRNG and run it through a message
digest algorithm, correct? But is there any way to generate
256 bit session keys? Are there any secure hash algorithms
that give 256 bit values as output?
- --EO
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.0.2
iQEVAwUBNoJwEcgXRmWyooNRAQEXmQf/ci3XLmXzKXDnQGehRm/F36XsA3THU8yY
dw13e2iSKIxobsX+oB51GyzNKoF2uGvSeN4M0n1CNAFP5PnfKM3ijbK12ium2l7A
wfe7mG6I5KRw5UHeY2agvcMtKhxptjbL7KuGPSPOYmxSZnbQdaYV964lXqLZZ0HN
bQeWCxCCUSPWBOisANr21VUbvgVlV+1GOMVDQfPXyT4j22JOPVWOFR90fDG6EHQg
w+fumNIKFVq/fXQV5/5eIzX3Ah47EihoF7MwBmAv9w/upKnOzSoliXL2/UZ0sP+V
mFekgsqocfmUMK6ROYGnjpRdMZI5U/W/Q5BZNd66hvtED6qbu81gdw==
=RhGT
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: ZIP encryption safe?
Date: Thu, 24 Dec 1998 21:16:39 GMT
Reply-To: Jim Dunnett
On Wed, 23 Dec 1998 10:26:27 GMT, r.fellner_AT_bigfoot.com
(http://come.to/Delphi-Box) wrote:
>Hello,
>
>sorry for asking a question which might have been asked already 100s
>of times before, but I'm not too familiar with crypto topics and just
>asked me the following:
>
>since I've read that especially using long ZIP passwords (15 chars and
>more, including non-alphanumeric chars) takes enourmously long to
>decrypt and just brute-force decryption helps.
>
>How safe is that, compared to, let's say, 128bit Blowfish encryption ?
>I just want to get a feeling, I don't need exact factors.
Go for Blowfish. Use ZIP for archiving and compression,
not for crypto.
--
Merry Xmas from Jim. | The best advice I could give to Hague is to
olympus%jimdee.prestel.co.uk | resign and let some other poor sod try to
dynastic%cwcom.net | square the circle. Only someone as mad as
nordland%aol.com | Redwood is fit for this unhappy role.
marula%zdnetmail.com | - Ken Livingstone.
Pgp key: wwwkeys.uk.pgp.net:11371
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Encryption Basics
Date: Thu, 24 Dec 1998 21:16:40 GMT
Reply-To: Jim Dunnett
On 23 Dec 1998 19:11:01 -0600, [EMAIL PROTECTED] (Aman) wrote:
>On Tue, 22 Dec 1998 20:53:15 GMT, A C Wilshere <[EMAIL PROTECTED]>
>wrote:
>
>>
>>FREE, sounds good already, especially to a Yorkshireman, (no, its not
>>true that Yorkshiremen are tight) ;-)
>>
>
>It may interest you to know, that the author of the current Scramdisk
>system (AMAN) is also a Yorkshireman (me) living but a few miles
>from Sheffield. I know how tight we are so I thought I really ought to
>make it available for free!
>
Glad you did.
>Best wishes for Christmas and a happy new year to all.
>Extra special wishes to all Scramdisk users around the world.
And the season's best from me as well, Aman.
--
Merry Xmas from Jim. | The best advice I could give to Hague is to
olympus%jimdee.prestel.co.uk | resign and let some other poor sod try to
dynastic%cwcom.net | square the circle. Only someone as mad as
nordland%aol.com | Redwood is fit for this unhappy role.
marula%zdnetmail.com | - Ken Livingstone.
Pgp key: wwwkeys.uk.pgp.net:11371
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Stego in jpeg files
Date: Thu, 24 Dec 1998 21:16:40 GMT
Reply-To: Jim Dunnett
On Wed, 23 Dec 1998 11:33:59 GMT, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>>
>> The first public version of a DOS program to hide a file in a jpeg
>> file using techniques that obscure the hidden file from statistical
>> analysis is available for anyone who wants to try it.
>>
>> http:\\pweb.uunet.de/flexsys.mtk/jphs01.zip
>>
>> please try and let me have your comments.
>>
>> Allan Latham <|alatham| at |flexsys-group.com|>
>>
>
> My browser cannot find this URL. Please check it.
The file doesn't exist on the server. Download the only
other .zip file in the directory, that APPEARS to be the
correct one. JPHD01.ZIP ISTR.
--
Merry Xmas from Jim. | The best advice I could give to Hague is to
olympus%jimdee.prestel.co.uk | resign and let some other poor sod try to
dynastic%cwcom.net | square the circle. Only someone as mad as
nordland%aol.com | Redwood is fit for this unhappy role.
marula%zdnetmail.com | - Ken Livingstone.
Pgp key: wwwkeys.uk.pgp.net:11371
------------------------------
From: "MH" <[EMAIL PROTECTED]>
Subject: VPN Network -- South Pacific
Date: Thu, 24 Dec 1998 15:20:08 -0800
Pitcairn Website:
http://students.washington.edu/mikehack/ptt.htm
http://students.washington.edu/mikehack/pitcairn.htm
-- Proposal to be presented to islanders in the new year, drafted by Can
Xpat... network is expected to have some kind of VPN.
And other related telecomm info:
http://students.washington.edu/mikehack/chaff.htm
http://students.washington.edu/mikehack/inmarsat.htm
http://students.washington.edu/mikehack/home.htm
------------------------------
From: Karl-Friedrich Lenz <[EMAIL PROTECTED]>
Subject: Re: Cryptography FAQ (01/10: Overview)
Date: 24 Dec 1998 15:55:37 -0800
In article , [EMAIL PROTECTED] says...
>
>
>I'd be willing to try to maintain it, if the copyright holders are
>willing.
For a start, it would be nice if you or someone else who knows about crypto
would post a "FAQ 1999 update". That would be one extra part of the FAQ with all
the new info since 1994. You probably don't need copyright holders permission
for that.
Have you tried contacting the editors of the old FAQ?
Karl-Friedrich Lenz
www.toptext.com/crypto
------------------------------
From: [EMAIL PROTECTED] (Logi Ragnarsson)
Subject: Re: Hashing for randomness
Date: 25 Dec 1998 02:16:43 GMT
[EMAIL PROTECTED] (STL137) writes:
>Why does everyone like MD5 when it is on its last legs.... ?
Yes, I suppose I should be using SHA-1 or RIPE-MD, but that wasn't really
the point. What I'm not quite certain of is the idea of continuously
hashing a slightly changing seed.
--
Logi Ragnarsson - [EMAIL PROTECTED] - Math and CS student at Univ. of Iceland
Some day we all shall be out of scope. (Beware the garbage collector.)
------------------------------
From: rosi <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: coNP=NP Made Easier?
Date: Thu, 24 Dec 1998 16:01:00 -0800
[EMAIL PROTECTED] wrote:
[only important part selected, hope there is no problem]
> >
> > From yours I understand you agree to the following:
> > 21. The SS problem CAN be answered positively in finite time. To
> > be specific, there exists a TM that answers (i.e. halts and
> > prints YES# on its output tape) within finite time when
> > given i' which IS a subset sum of S (we use the same SS
> > problem given in the previous post).
> > NOTE: you actually answered my first two questions in one.
>
> Sure; and likewise for NO#. That is, SS is recursive (computable). ^^^^
Thank you very much for the commitment. Glad to have the flavor of
Kleene and Church, though I have very limited math training. It seems so
wasteful that we have to go such a round-about way to try to achieve
something so simple (at least to me). But I belive that we WILL get there.
> "Finite time" says no more and no less than that.
>
> > 22. We will use M as the TM referred to in 1.
> > NOTE: this is in response to my third question in the previous
> > post.
> > 23. It is not possible for the solution time (i.e. time needed to
> > solve the SS problem) to be bounded by n^1 for all natural
> > numbers n.
> > NOTE: this is in response to my fourth question in the
> > previous post.
> > 24. In addition, if I understand correctly, that you mean M is
> > NOT to be run more than once for it to provide the answer.
> > NOTE: again here providing the answer is: to halt and to
> > print YES# on M's output tape when i' (and S) are input to
> > M.
>
> There is no sense in running a det. M "more than once"; it does
> the same thing every time.
>
> There is no point in "running" a N.D. M _at all_... not even once --
> unless if you use the "guessing" version of NP's definition.
Actually, running a det. M multiple times should never bother us. We are
interested, for so far the questions asked and answered, in: there IS such an
M (don't care det. M or magic rock). If a det. M can (ALWAYS) answer in one
run in finite time, the question is answered positively (i.e. there is such
a mechanism). If no det. M can answer, no matter how many times it is run,
the question is answered negatively (only for det. M of course). I can see
that you are worried about my not distinguishing N.D. M and det. M. In this
discussion (and for the questions so far) they make no difference. If you can
give one det. M for the task or a N.D. M (or a piece of magic rock), I will
accept if you commit to a pecific, well-describe mechanism (as you have agreed
to 26 being your version of the M), one that 'answers' in _finite time_. As
to 'in finite time', a det. M will do, right? No need to make a distinction.
>
> The problem is, you are not making a distinction between N.D. and
> D. machines... or so it seems!
You are right. Not for the questions asked so far.
>
> > In addition,
> > 25. You asked me to be more specific about my assumption (think my
> > guess is correct that's what you want). If you really want a
> > repetition of the definitions and the assumption, I can include
> > in the next post. Please let me know.
> > Actually, all I want is that you allow an assumption to be made,
> > be it true or false. We will concentrate on the derivation, i.e.
> > we first try to establish that there is no problem with the steps
> > going from the assumption to coNP=NP (even though the assumption
> > might be in error). We will finally deal with the validity of the
> > assumption. Is this fine?
>
> Yes, I asked exactly what the assumption is.
I should not be picky and I am not picking. I have posted the assumption
and you are asking for it. I wonder if you have read carefully mine which
has the assumption as an important point. It is not really so important at
this junction and we can do for now without it. But as I promised, I give it
again here:
Assumption: Output equivalent automata are equivalent in
comupting power (or are computationally
equivalent).
>
> > Please accept my apologies and let me know if any of the above
> > of my understanding is incorrect or not accurate. I am, in fact,
> > particularly concerned with my interpretation of 24. From your previous
> > posts I seem to see that you may have adopted a specific notion of
> > NDTM's. That is fine, as long as one does not give trouble. As I have
>
> It _is_ the notion of NDTM generally accepted; there is no variability
> ^^^^^^^^^^^^^^^^^^
Be it so (am referring to _generally_).
No, not really acceptable if that generally accepted one is 26, the one
(you said below) just as the "K" you described! I will make the point later;
and it will be made very soon, I promise. For now, let us not be distracted.
We do a few questions at a time.
> there. If you have a different one in mind, please do explain!
>
> > been kind of explicity, there are the 'correct guess', the 'by magic',
> > and the 'massive, unlimited parallelism' etc. etc. I believe there had
> > been considerations, but by the time Brassard's was published, people
> > had settled somewhat. I now see that I am wrong. Adopting whichever is
> > likely a personal taste kind of thing. However, there may be more to it
> > than just that. But I do not think we need to go into it.
> >
> > Since I sensed something, I think I'd better make it explicit and
> > clear so that I do not misunderstand you. To be concrete, I give two
> > notions and would like you to pick one that you really mean:
> > 26. M will always halt. If YES# is printed on the output tape on
> > halt, we know for sure that the integer input to M IS a subset
> > sum. However, it may print things (trivial included) other than
> > YES#, and we know nothing. In such a case, the input could very
> > well be a subset sum, but for the particular run (know you
> > do not quite like the word 'run', you may give it a verb to
> > denote the execution/processing), no definite answer is provided.
> > NOTE: since you seemed to have mentioned 'no multiple run',
> > I should not have given this. But I have to make sure.
>
> In fact I described just such a machine... "K". I don't dislike the term
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
Wonderful! Beautiful! Fabulous!
> "run"; I pointed out that K, as well as other N.D. machines, have many
> feasible "runs" on one and the same input.
As I said I seem to have been wrong all the time! The choice of a NDTM
(I am specific here) has never been settled among the candidates, which
include 26 and 27!
>
> > 27. M will halt and print YES# iff the input IS a subset sum of S.
> > Otherwise, M's execution is UNDEFINED. UNDEFINE is not specific
> > enough. Some people prefer this to be non-halting. For our
> > discussion, we can, but not necessarily have to, say that M
> > halts (in such cases) only after 'exponential time' to avoid
> > later embarrassment.
>
> Again, this is unclear. What do you mean by "M"?? Is it D, or ND?
> If it is to be ND, then saying "IFF" above is pointless.
>
Do not really care as long as it works. If you or anyone can give even
a D (believe you mean det. M) that works this way, I will be happy. I at
least at this point will not ask you to show me one.
We can dwell on 27 later. But for now, as you have picked 26, we will use
it and forget about 27 for a while. (It appears to be a personal taste thing.
Yet it is one aspect of the core issue!)
Now I am going to ask the FIRST crucial question. I suggest that you
think about the question very carefully before answering. You should think
about my other questions very carefully too, and especially about your
commitment of picking 26 as your NDTM for answering the SS problem
(positively). If you have any questions about anything (including the
assumption), please make them clear before I evaluate the answers you
provided. Please, be extremely careful.
I want to add. I will go strictly by and with 26, i.e. including taking
into consideration the fact that the M of 26 (or your "K") may halt and
print other things (or even nothing) when i' --- a subset sum of S --- is
the input. But it will always halt within finite time.
Now _"THE"_ question:
Does there exist a mechanism MM (any mechanism) that
1. HALTS within a polynomial bound (or in other words: whose complexity
is bounded by some polynomial function f(n) where n is the input/
problem size) and
2. ANSWERS POSITIVELY (or our version to be specific: prints YES# on
its output tape on halt)
when i', a subset sum of S, is given as input? (S as input as well of
course. No need perhaps to go to such details to make this explicit)
To further avoid misunderstanding, I add the following:
1. To answer is to ALWAYS answer. If it sometimes does and sometimes does
not. or sometimes does wrongly, it is not the M we are looking for.
2. NDTM is fine. Any mechanism is fine as long as it behaves as describe
in 26.
3. Such an MM need not be my mechanism or your "K". The questions is asking
if there is ANY such mechanism. If your "K" works, great. If your "K"
does not work, just as great. That way we can be free from bondage in
pursuit of such a mechanism.
If we can find such a mechanism, we have 'achieved a lot' (a what
victory?) at great cost. :)
If we can not find such a mechanism, somebody is in real trouble! :)
4. Lastly a question, which you are not obliged to answer: Do you believe
in Turing's Thesis?
You believe in Church's that is very good. I believe you do in Turing's
as well. I hope that you see the relevance, or will soon.
Sorry that you seem not used to cold weather. Your irregular response will
be no problem. As for me, I will be hardly working for a few and then working
hard.
Merry Xmas and best regards.
--- (My Signature)
P.S.
I am real but just do not want to reveal my real name. Address me as ROSi
is fine.
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: Q: Is there security in unusual RSA key lengths?
Date: 24 Dec 1998 17:49:48 -0800
In article <753c70$lfe$[EMAIL PROTECTED]>,
Richard Herring <[EMAIL PROTECTED]> wrote:
>Bad assumption. Testing all keys <= 2048 bits will only take twice
>as long as testing just keys = 2048 bits, or less.
Actually, because prime numbers become less plentiful as they get longer,
there should be more RSA keys less than 2048 bits long than exactly 2048
bits long - RSA keys are not like the pure binary words we use for
symmetric crypto, where there are exactly 2^n n-bit keys and (2^n)-1 keys
less than n bits. So it would take more than twice as long to test all
<=2048-bit keys as it takes to test all exactly 2048-bit keys. Short keys
will test faster, counteracting that effect, but probably not enough to
make it less than twice as long. I'd expect the factor to be a small
constant, but more than two.
It should be easy to actually calculate a close estimate on this question
instead of just guessing, but why bother? Brute-force examination of all
possible RSA keys falls into the "bogosort" category of algorithm design;
doing trial division on every key you actually encounter would be faster.
--
The third girl had an upside-down penguin on Matthew Skala
her stomach, so the doctor told her, "I'll Ansuz BBS
examine you for free, if you and your (250) 472-3169
boyfriend will debug my Web server." http://www.islandnet.com/~mskala/
------------------------------
** 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
******************************
