Cryptography-Digest Digest #261, Volume #14 Sun, 29 Apr 01 01:13:00 EDT
Contents:
Re: Censorship Threat at Information Hiding Workshop (Darren New)
Re: Censorship Threat at Information Hiding Workshop (Darren New)
Re: Censorship Threat at Information Hiding Workshop (Bill Unruh)
Re: Secure Digital Music Initiative cracked? ("Roger Schlafly")
Re: LFSR Security (Benjamin Goldberg)
Re: "I do not feel secure using your program any more." (Benjamin Goldberg)
Re: LFSR Security (David Wagner)
Re: Can this be done? (David Hopwood)
Re: Prime generation (David Hopwood)
Re: MS OSs "swap" file: total breach of computer security. (David Hopwood)
----------------------------------------------------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Sun, 29 Apr 2001 00:14:50 GMT
Xcott Craver wrote:
> Simply, the copyright holder does not have the power to
> require such things.
In part, that's because the things you describe are contractual issues,
which are state law, and copyright is federal law, which overrules state law
in the case of conflicts.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
schedule.c:7: warning: assignment makes calendar_week
from programmer_week without a cast.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Sun, 29 Apr 2001 00:16:54 GMT
Jonathan Edwards wrote:
> So I could lend you my CD and you could play it on your player.
Yeah, OK, thinking on it, it doesn't make sense to make unique CDs. I was
thinking from the POV of online music purchase, like via Liquid Audio or
some such, whever everyone gets a key-locked different version of the file.
I thought SMDI was supposed to support this as well, but I might be wrong.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
schedule.c:7: warning: assignment makes calendar_week
from programmer_week without a cast.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: 29 Apr 2001 01:05:43 GMT
In <4VIG6.4709$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Xcott Craver)
writes:
]Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
]>
]> It's really very simple. The original creative work belongs to the
]> person who creates it. He agrees to let use use it for certain purposes
]> under certain conditions, which may or may not involve payment.
]> If you agree to those terms, you are given access to the work.
]> If you then do not follow the terms, you have broken a (possibly implied)
]> contract.
No, It does not "belong" to him, except in the sense that he has control
of and owns that first copy and can refuse to let anyone else see it. Thereafter,
a completely artificial mechanism, of copyright law, sets in.
The state grants him a monopoly on control of copying that item. This
monopoly is as artificial as any other monopoly granted by the state. In
this case the reason for this grant of monopoly is to encourage
production. There is no natural right to a monopoly.
A creative work is not a thing. An embodiement can be, but it is not
embodyments copyight law controls, it is the act of copying. That act
deprives noone of anything. He has as much of the item afterwards as he
did befor. It is a public good to allow copying, just as it is believed
that the free market is also a public good. It may be that there is a
greater good in destroying both the free market and the copying, but it
should surely be tested as to whether that greater good really is
greater.
] [The DMCA cuts this off by making it a violation of a separate
] law to perform that fair use copying, if you must circumvent
] something that prevents the fair use copying.]
The DMCA is similar to the types of law passed in the soviet union
preventing anyone but the state sanctioned companies from creating
tractors, TV sets, or coffee. It is a monopolistic law passed to place
state sanctions behind restrictive, anti-competitive practices. As
usual, when one nation defeats another, they promptly proceed to adopt
many of the worst practices of their foes.
] Simply, the copyright holder does not have the power to
] require such things.
Copyright controls ONLY copying. Not use.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Secure Digital Music Initiative cracked?
Date: Sun, 29 Apr 2001 00:23:41 GMT
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9ceu8n$3nn$[EMAIL PROTECTED]...
> Douglas A. Gwyn wrote:
> >Actually the paper you're thinking of was the subject of personal
> >attention by an NSA employee working outside the proper scope of
> >his duties, and the Agency didn't back him up.
> But nonetheless there were still proposals (from the NSA)
> that researchers should voluntarily submit their papers to
> the NSA before publication for approval, weren't there?
Yes, there were. And the academic community screamed bloody
murder. The journals did not comply AFAIK, no academic crypto
paper was suppressed.
But now a music cartel has succeeded in going farther than the NSA
ever did -- it intimidated legitimate scholars into withdrawing their
work from publication.
And for what? At least the NSA had a national security argument.
The RIAA is only trying to protect hypothetical commercial
interests. And RIAA's legal position regarding those interests is
one that most music lovers don't agree with, if Napster use is any
indication.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 28 Apr 2001 21:58:31 -0400
David Wagner wrote:
>
> Douglas A. Gwyn wrote:
> >David Wagner wrote:
> >> No, that wasn't the question I meant to ask. Suppose that you have
> >> some known bits of keystream, and you know what positions they come
> >> from, but the positions are not regularly-spaced. Can you break
> >> it?
> >
> >It obviously depends on how (un)lucky you are in your sampling.
> >For example, if some of the samples are in the same phase in
> >different periods, you'd need more than the amount that works
> >for the contiguous case.
>
> I must admit I don't understand yet. Could you elaborate?
> Suppose for simplicity that the period is large enough that
> all of your samples are in the same period, but they are not
> regularly-spaced. How can we proceed?
If all our samples are from the same period, then we have fewer samples
than there are bits in the state, and thus we cannot fully determine the
state.
A better way of avoiding worring about phase might be to say that all of
our samples are from prime-number positions of the output. So we know
the 2nd, 3rd, 5th, 7th, 11th, 13th, 17th, 19th, etc bit.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,alt.hacker
Subject: Re: "I do not feel secure using your program any more."
Date: Sun, 29 Apr 2001 03:39:05 GMT
Anthony Stephen Szopa wrote:
>
> "I do not feel secure using your program any more."
Amazing! Someone once actually felt secure about one of your programs?!
>
> You sure jumped to a hasty conclusion.
Yes, he should never have felt that it was secure in the first place.
It was very hasty of him to put any trust in it long enough to be able
to use a phrase like "any more."
>
> I certainly appreciate your effort in arriving at this noteworthy
> observation.
In security, a non-naive person always starts off assuming that any
method is insecure, and only after sufficient analysis and evidince of
the algorithms change one's mind. Therefor, much effort is needed to
feel secure, but no effort is needed to feel insecure.
It's like a reversed legal system -- guilty until proven innocent.
--
Sometimes the journey *is* its own reward--but not when you're trying to
get to the bathroom in time.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 29 Apr 2001 04:37:51 GMT
Benjamin Goldberg wrote:
>If all our samples are from the same period, then we have fewer samples
>than there are bits in the state, and thus we cannot fully determine the
>state.
What? If you have a n-bit LFSR with primitive feedback taps,
the period is 2^n - 1. Are we using the same terminology?
------------------------------
Date: Sun, 29 Apr 2001 05:45:23 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Can this be done?
=====BEGIN PGP SIGNED MESSAGE=====
Mark Lomas wrote:
> "John Wasser" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > In article <3ae12b5e$0$15023$[EMAIL PROTECTED]>, Mark Lomas
> > <[EMAIL PROTECTED]> wrote:
> >
> > > If Bob receives two messages, one from Alice and one from Eve, each
> > > containing a different public key, followed by similar messages from
> > > both Alice and Eve all of which are signed as you suggest, how can he
> > > tell whether Eve is duplicating Alice's messages or Alice duplicating
> > > Eve's?
> >
> > He can't. That was not a requirement. The only requirement was that
> > Bob be able to determine that a set of mesages all came from a source
> > that knew some unspecified secret.
>
> It may not have been stated explicitly, but it is requirement
> implied by use of the word 'source'.
>
> Alice was the source of the messages.
> Eve duplicated those messages, but substituting a new key.
>
> Let us assume that Eve sends one extra signed message.
> This did not come from the same source as the original messages.
> How can Bob tell?
The messages were being sent anonymously, so there is no immediate
source for any of them that can be relied on by Bob, other than by
checking the signatures. For example, if the messages are sent over
a mix-net, the identity of the last node does not say anything about
who the sender is, but that does not matter for the problem as stated.
If it is necessary to check that messages were not delayed for more
than a given time, Alice can include the time of transmission in the
message. This does not prevent Mallory from causing messages to be dropped.
However, that could be detected in some situations by having each message
include a hash of all the previous messages.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOutU4DkCAxeYt5gVAQGPmwf+O0fYa9SqfsOzox+J6IHdj+ziofGCp9vO
fdymME1dKNQsNeQZWNxDkUJhB3nVLzcmr6WXFph+oy96UmwucNNOYsghweYZWcKW
vaiRzEatk2n6TPObLslk0JB89M8HwnJOlLAeIXnuJN4AI4WcJUohFT1WDKEXsL/O
lxb2AhSKDvVUbsPYXlph9tE0z3FjdzXEs3mn/pA2fWlKeDemVvgrBbygU7xAzACg
hDVlHZfJnOhqEaJ6Qb5s6KSUoCeoQ6eCoyn1vxhLVi0bIcWFVgM3BEFG87H9yZrl
EhCPy+LIXDdPbZWFdShKaQoVK0P20Gcy/96PX1PfJtK3B2o5NJhlVg==
=iJKy
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 29 Apr 2001 05:45:38 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Prime generation
=====BEGIN PGP SIGNED MESSAGE=====
Benjamin Johnston wrote:
> Schneier's book suggests one approach to generating a prime, where you
> start with a random number and begin searching from that point until a
> prime is found.
>
> I assume that because there might be a long run of composites in some
> ranges, that some primes would be more likely than others with this
> approach, and others (eg. the second prime in a pair) might be highly
> unlikely.
See the post in this newsgroup entitled "Re: Current best complexity
for factoring?", posted by [EMAIL PROTECTED] (Terry Boon) on
18 April, and follow-ups.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOutvnDkCAxeYt5gVAQGmPAf/YRYV7NQXXNFflA+vRzkMNMvPmSYNRqqf
BYPMkbx1RiAwVD6xrOq7zx1zsNvpm0rdGLz0ffuzukiFBnYTt9wxySupJ55nQz0t
Hn4tIKBwoCesFGtoKmFT+i2M8H145xVqcNgylLVxc/BV5g4z9KFTOHV4MwvQjLJD
TM2DaJ43AZmMhU4oOmn+byMvB4sgUMZl3Sbt30UMjjLC3awopSMtzGnsWUzE0FvL
p5vGCZBk3eQ7RnhzYM7uKwQb+8Il5Wt946VtNpLGB/xNwtyyxUQknMkSpl1R7VrA
g2YROpFFaFXz3F30wQ5vcPgUPzo2+CreIHIsYQb9FKfKiCwKsryPKw==
=6AxI
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 29 Apr 2001 05:46:55 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
=====BEGIN PGP SIGNED MESSAGE=====
Tom St Denis wrote:
> <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > And, recognizing this, your reason for continuing to use Win98
> > would be ......??????
>
> What's your point? It's possible to secure memory in Win98, ASS is
> just too stupid to figure out how.
It is possible, just about, but what is far from obvious from the
Microsoft documentation is that it can *only* be done via a ring 0
device driver, not directly from an application. In fact even with
the co-operation of a device driver, it's decidedly non-trivial to
access locked memory from a Windows application.
Note that the Win32 API function VirtualLock, which is documented to
"lock" virtual memory, does not do what you would think. For example,
Knowledge Base article Q108449 says:
# VirtualLock()
# To lock a particular page into memory so that it cannot be swapped
# out to disk, use VirtualLock().
However, that is not what VirtualLock actually does. Read this MSDN
article (* is my emphasis):
Managing Virtual Memory in Win32
Randy Kath
Microsoft Developer Network Technology Group
January 20, 1993
# Processes in Windows NT are granted subtle influence into [virtual
# memory paging] behavior with the VirtualLock and VirtualUnlock
# functions. Essentially, a process can establish specific pages to
# lock into its working set. However, this does not give the process
# free reign over its working set. It cannot affect the number of pages
# that make up its working set (the system adjusts the working set for
# each process routinely), and *it cannot control when the working set
# is in memory and when it is not*. The maximum number of pages that
# can be locked into a process's working set at one time is limited to
# 32. An application could do more harm than good by locking pages of
# committed memory into the working set because doing so may force other
# critical pages in the process to become replaced. In that case, the
# pages could become paged to disk, causing page faults to occur whenever
# they were accessed. Then the process would spend much of its CPU
# allotment just paging critical pages in and out of memory.
#
# *Bear in mind that locking a page of memory in Win32 does not mean
# that the page will not be paged to disk.* On the contrary, it means
# that, while the process is running, the locked page of memory will be
# present in physical memory. *It is not only possible, but likely,
# that the entire working set of pages for a process will be paged to
# disk when the process is idle.* When the process wakes up, its working
# set of pages is immediately paged back into memory, including the
# VirtualLocked pages.
This article was written about Windows NT 3.51, but it also applies
to NT 4.0, and I believe also to Windows 2000. For Windows 95, "the
VirtualLock function is implemented as a stub that has no effect and
always returns a nonzero value" (i.e. it fails silently: nonzero
means success). I don't know whether this is also the case for Win98,
but I suspect it is. In any case, VirtualLock is clearly not sufficient
to lock memory for cryptographic security purposes.
Another possibility that you might think would help, is the MEM_RESET
flag to VirtualAlloc[Ex], which is documented as follows:
# MEM_RESET Windows NT: Specifies that memory pages within the
# range specified by lpAddress and dwSize will not be
# written to or read from the paging file.
Don't be misled: this is just yet more badly written documentation.
MEM_RESET actually indicates that an app has finished with a range of
pages (but doesn't want to decommit them immediately for efficiency
reasons).
To allocate locked memory from a device driver, you have to use the
_ProcessAlloc function with the PAGEFIXED flag, and it will return the
ring 0 linear address of the block in EAX (yes, it really is that low
level). However, note that this is memory allocated for use directly
by the device driver; making it accessible to an application requires
(considerable) extra work.
If you only need to lock memory used by keys, then it would be possible
to have the application reference each key using an abstract handle,
so that they are never mapped directly to the application's address
space, and then provide an API for encryption, decryption, etc. To make
this secure in Windows NT, you would have to segregate keys owned by
different processes (in Win9x it doesn't matter, because processes
can read each other's memory, and system memory, anyway). It would be
an interesting project to implement this, but it is certainly much more
effort than just locking a range of application memory. Also, it isn't
clear (to me, at least), how you would protect data other than keys,
short of running significant portions of the application in ring 0 -
which obviously introduces its own security problems.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOuubGDkCAxeYt5gVAQHrSAf+OhMs5oPTatYRoKd4XW5oztx2ZLP3orWr
1UOgivKMxeLEvRA6O61w8IgEHH+tZ1LZu6B9+Pr3WG4QqpaSNGKfI50AbQYsOTT1
frSSrn4TCY9V/3CM3fqsdq5KyV1D385EpfsyUzrMymi9b1fl/tVQkritvwHc4RMl
tMn6W9g2ZqpHPT/rly0RZqCv0Myjwy7QCwI8HCg1a3vtS2mY1OJwGT/dv+GVchbK
12KydnWoL049rBbYa+0gLedqpzg75OV6bO343+zyyHaHlSS1drM9rRgfN0wks4Cs
Rxm02sQ9iolCkHBFHleX3e6iotrq3EjV8uVWbWXUufaUSuAvSeDE3w==
=OZUp
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
