Cryptography-Digest Digest #539, Volume #12 Sat, 26 Aug 00 01:13:01 EDT
Contents:
Re: The DeCSS ruling and the big shots (Sundial Services)
Re: The DeCSS ruling (Sundial Services)
Re: blowfish problem ("Bruce G. Stewart")
Re: Serious PGP v5 & v6 bug! (Sundial Services)
Writers (Crossbox)
Re: The DeCSS ruling (Bill Unruh)
Re: My encryption algorithm (Rich Wales)
Re: Asymmetric Encryption Algorithms (DJohn37050)
Check this out! ("Big Boy Barry")
Re: Serious PGP v5 & v6 bug! (Ralf Muschall)
Re: On pseudo-random permutation (Benjamin Goldberg)
Re: An interesting cryptographic problem (Benjamin Goldberg)
Re: On pseudo-random permutation ([EMAIL PROTECTED])
Re: Bytes, octets, chars, and characters (Guy Macon)
Re: Steganography question (Guy Macon)
Re: Asymmetric Encryption Algorithms (Roger Schlafly)
----------------------------------------------------------------------------
Date: Fri, 25 Aug 2000 18:12:36 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The DeCSS ruling and the big shots
> > rot26 <[EMAIL PROTECTED]> wrote:
> > > I'd just like to know what the general attitude of sci.crypt readers are
> > > towards the DeCSS case... Isn't it about time the "big shots" use their
> > > influence to stop the bullying by the MPAA, educate the public and
> > > perhaps give 2600 their support? (It could be my ignorance and that they
> > > are doing it already... I stand to be corrected.)
The final analysis of the CSS flap may simply be that "you cannot
achieve security through obscurity." It may also be observed that "the
laws of any one country simply cannot prevent the instantaneous flow of
information through the Internet."
Having said all that, perhaps the judge in this case -did- have a
point. The objective of CSS was really to protect intellectual property
against the casual snooper who, "if the door were left completely
unlocked," would steal the customer blind, but who, "if the door is
locked at all," is likely to give up and watch Monday Night Football
instead. The fact that CSS turned out to be a cryptographically
ineffective system might -not- necessarily mean that it has no value to
its creators, or that its creators have no right to any of the
protection they might have (perhaps rightly, perhaps wrongly)
anticipated that they would enjoy by commissioning the creation of this
system.
Flawed it may be, but "human nature is what it is" (and let's be
brutally honest here folks ;-)). Can we honestly say that the backers
of CSS have -no- valid position to take? Does the fact that a lock can
be picked mean that they are not allowed to have -any- lock or object to
the free and wonton distribution of a lock-pick? That is, really, "a
two-sided and therefore tough question." (It doesn't have a
'mathematical' answer.)
------------------------------
Date: Fri, 25 Aug 2000 18:16:28 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The DeCSS ruling
Yet Doug's point cannot be dismissed out-of-hand, Joe. The fact that
there are legitimate purposes for reverse-engineering (wretched or non-
existent documentation being one of them) does not entirely invalidate
the point that reverse-engineering is sometimes also done for nefarious
purposes. I tend to feel that the recording industry vastly
over-estimates the number of times people steal copies of movies and
records ... but then again, maybe I'm just "blissfully unaware" of the
number of times my own copyrights are stolen. :-/
>Joseph Reuter wrote:
>
> "Douglas A. Gwyn" wrote:
> > Jim Steuert wrote:
> > > To presume that we are reverse-engineering software for the purpose
> > > of some "illegal" intent "before" we actually reverse-engineer it
> > > is a very serious presumption of guilt.
> >
> > I didn't say that.
> > However, the usual purpose of reverse-engineering is to benefit
> > from somebody else's work without compensating them for it.
>
> I do a lot of reverse-engineering to figure out the undocumented
> (or poorly-documented) interface to something so that I can
> communicate with it.
------------------------------
From: "Bruce G. Stewart" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 26 Aug 2000 01:21:48 GMT
Eric Smith wrote:
>
> Chris Torek <[EMAIL PROTECTED]> wrote:
> > The problem basically boils down to several things, some of which
> > are implied by the fact that memcpy() can be implemented in strictly
> > portable C code as:
> >
> > void *memcpy(void *dst0, const void *src0, size_t len) {
> > unsigned char *dst = dst0;
> > const unsigned char *src = src0;
> >
> > while (size--)
> > *dst++ = *src++;
> > return dst0;
> > }
>
> I asked:
> > Is that really true? I know that the void * has to be able to
> > store a value of any other pointer type. But is it really the case
> > that a char * also has to be able to store a value of any other
> > pointer type?
>
> [EMAIL PROTECTED] (Dan Pop) writes:
> > Yup. C89 says:
> >
> > A pointer to void shall have the same representation and alignment
> > requirements as a pointer to a character type. Other pointer types
> > need not have the same representation or alignment requirements.
>
> But pointers other than void * and char * can have different representation
> and alignment requirements? If so, then the memcpy above can't be
> guaranteed to work.
Not so. It implies that converting an pointer to some type into a void*
then into an unsigned char* may be more than a trivial copy from
location to another.
------------------------------
Date: Fri, 25 Aug 2000 18:31:38 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
You know, Sam, this may be "PGP's nightmare come-true" but ... then
again *in-practice* people DO lose keys sometimes, and people DO get
smooshed by bread-trucks sometimes and mission-critical messages DO
become unrecoverable (with, perhaps, millions of hard-dollars lost as a
result) and ... "what in the hell do you do?" :-/
The way I see it, there -does- come a time when you have to balance the
perfection of cryptographic security against the reality of the fact
that people ... are flesh-and-blood carbon units. "**** happens, and
does your real-world cryptographic system recognize this or does it
not?"
Yes, key-escrow and key-recovery and yada-yada-yada DOES introduce a
cryptographic risk and a cryptographic exposure into any system. But
can we truly say that "in no case at all should it be there?" Can we
say that "in no case at all is there a business need for such a thing?"
I'm just not-so-sure.
The true problem that I see that Ralf "uncovered" is that, with the
presence of a "hidden second key," there are now "two bits" and
therefore "three (11) not one (01) possibilities" in the overall trust
equation. Existing schemes for validating secure communication between
Bob and Alice are not adequate to handle the possibility that Matt
(Bob's manager) might be in the picture too, and therefore that Eve
might be able to impersonate either Bob *or* Matt and thereby gain entry
into the system.
The knee-jerk reaction (expressed so far) seems to be... "SHOOT MATT!"
Or, "MATT HAS NO RIGHT TO EXIST!!" ;-)
Or, "IT SCREWS UP MY SYSTEM ;-) ;-) IF MATT EXISTS!!" ;-)
{ hey, hasn't that -always- been true of management? } :->
But lurking under all of this is probably .. not a flaw, but a fine new
wrinkle on cryptology:
WHAT IF WE TRULY -NEED- MATT-THE-MANAGER?
"In the real world," most businesses -do.- (And instead of debating
that point until all the bits in the Internet turn blue, what if we take
the preceding statement as a logical premise and explore the
implications to existing cryptographic systems that exist if that
premise is simply assumed to be true?
Sam Simpson wrote:
> Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
> It's of scientific interest because it spectacularly confirms a
> prediction made by a number of us in the paper on `The Risks of Key
> Recovery, Key Escrow, and Trusted Third-Party Encryption'
> <http://www.cdt.org/crypto/risks98/> that key escrow would make it
> much more difficult than people thought to build secure systems.
>
> He's written a paper on his work and it's at
>
> http://senderek.de/security/key-experiments.html
>
> Since NAI joined the Key Recovery Alliance, PGP has supported
> "Additional Decryption Keys" which can be added to a public key. The
> sender will then encrypt the session key to these as well as to your
> main public key. The bug is that some versions of PGP respond to ADK
> subpackets in the non-signed part of the public key data structure.
> The effect is that GCHQ can create a tampered version of your PGP
> public key containing a public key whose corresponding private key is
> also known to themselves, and circulate it. People who encrypt
> traffic
> to you will encrypt it to them too.
------------------------------
From: Crossbox <[EMAIL PROTECTED]>
Subject: Writers
Date: Sat, 26 Aug 2000 01:47:16 GMT
To everyone out there, 'The Digital Lotus' is an electronic publication
that we're trying to bring up, at this point it's just a baby. We have
a lot of great ideas on fabricating a creatively different sort of
online pub, but we are lacking on writers.
They theme for the project's contents is anything technological...
already have one guy who wrote on ATM... could use things on Unix IPC,
Cellular encryption, anything...
Check out the site at least, if you're interested in getting a little
more writing exposure, think about publishing with us.
http://www.insomnia.org/~dalai
for more details.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: The DeCSS ruling
Date: 26 Aug 2000 02:04:24 GMT
In <[EMAIL PROTECTED]> Sundial Services <[EMAIL PROTECTED]>
writes:
]Yet Doug's point cannot be dismissed out-of-hand, Joe. The fact that
]there are legitimate purposes for reverse-engineering (wretched or non-
]existent documentation being one of them) does not entirely invalidate
]the point that reverse-engineering is sometimes also done for nefarious
]purposes. I tend to feel that the recording industry vastly
The fact that there are legitimate purposes for running water out of
your tap, does not mean that it is not sometimes done for nefarious
pruposes. Does this mean that anything which could be used for nefarious
purposes should be outlawed?
]over-estimates the number of times people steal copies of movies and
]records ... but then again, maybe I'm just "blissfully unaware" of the
]number of times my own copyrights are stolen. :-/
Of course they do. It is in their intersts to do so. The more money they
can claim to have lost the more political clout they have . Never mind
that copyright is monopoly (remember the soviet union?) given by society
(through the gov't). It is now an entitlement.
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Subject: Re: My encryption algorithm
Date: 25 Aug 2000 19:10:10 -0700
"Slava K." wrote:
> The funny part is that I have no idea what
> a Vinegere cipher is.
Vigenere (note the correct spelling) is a classical polyalphabetic
substitution cipher dating from the 16th century. References:
http://www.trincoll.edu/depts/cpsc/cryptography/vigenere.html
http://raphael.math.uic.edu/~jeremy/crypt/vignere.html
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Asymmetric Encryption Algorithms
Date: 26 Aug 2000 02:24:20 GMT
NIST in DSA-2 draft said that to protect an AES 256-bit key it was appropriate
to use a 15,360 bit p and 512-bit q in DSA-2.
Don Johnson
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Check this out!
Date: Sat, 26 Aug 2000 02:38:33 GMT
http://www.wired.com/news/technology/0,1282,38437,00.html
------------------------------
From: Ralf Muschall <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Serious PGP v5 & v6 bug!
Date: 25 Aug 2000 01:52:42 +0200
Ron B. <[EMAIL PROTECTED]> writes:
> as the perfect employee. If Jane is has a heart attack, has a fatal
> accident or for other reasons beyond her control is not available to
> decrypt important data, the company may have legitmate reasons to
Then it should be simple to ask the sender to resend the message,
encrypted with Jane's successor's (or chief's) public key. In this
situation, the sender has full power to decides who may read his
messages, not some third person not authorized by him.
Remember that pgp is not for ecrypting locally stored data, like
backups etc. (symmetric methods are better for this purpose), but only
for the safe *transport* of messages.
Ralf
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Sat, 26 Aug 2000 03:09:24 GMT
Tim Tyler wrote:
>
> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> : Mok-Kong Shen wrote:
> :> Tim Tyler wrote:
> :> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> :> > : Tim Tyler schrieb:
> :> > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> :> > :> I observe that you omit any form of detection of collisions
> :> > :> between the first components of B. Without such a check the
> :> > :> result does not form a truly unbiased random permutation [...]
> :> >
> :> > : That collision is to be resolved by the sorting process.
> :> > : One has to decide on a resolution rule, though.
> :> >
> :> > No resolution in the sort routine can possibly produce an
> :> > unbiased sequence.
> :> >
> :> > You can see this by a counting arument, after observing that n!
> :> > doesn't usually divide exactly into 2^(n * x) very well [x is the
> :> > width of the RNG output in bits].
> :>
> :> I am not yet convinced. You have to consider from a probabilistic
> :> point of view, i.e. consider a large number of occurences
> :> and the average effects [...]
>
> : If the collision resolution is chosen such that the first
> : element of the pair is always considered less than the
> : second, then indeed there is a bias. The effect is [usually small].
> : One can on the other hand use a random choice rule to resolve
> : collision, in which case no bias can occur.
>
> Yes. It was not correct for me to have written: "No resolution
> in the sort routine can possibly produce an unbiased sequence."
>
> As you say, use of a rule based on bits from the random stream
> would be likely to provide a possible way of removing the bias.
Here's a foolish question: What if you simply sorted your original array
using (random()%2 ? 1 : -1) as your comparison function? While I'm
certain that there has to be something wrong with this (because it
sounds so simple and noone seems to have suggested it), I don't know
what it is... especially if your sort routine tries to do the minimum
number of comparisons.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: An interesting cryptographic problem
Date: Sat, 26 Aug 2000 03:51:13 GMT
[EMAIL PROTECTED] wrote:
[snip]
> The alternative is to encrypt the user credentials {u,p} to create
> {u',p'} via a well-known encryption algorithm such as DES. In this
> case, an encryption key must be provided.
>
> If the encryption key is site-specific, then an attack by an ex-
> employee is more difficult since although the algorithm is known, the
> key is not. However, the application software must somehow retrieve
> the key in order to perform the transform.
>
> The problem is therefore to secure the key in such a way that the
> application software can retrieve it programmatically yet a
> knowledgeable outsider could not do so. This means that simply
> sprinkling the key around a large file and knowing the bit offsets
> won't do, if these offsets are stored in a program, you might as well
> have stored the key.
How about having the encryption key change on a regular basis, and the
application software must retrieve the key (from some kind of key
server) each time he wants to transform (u,p) to (u',p'). The
connection to the key server can be done with any kind of
authentification and encryption, perhaps using SSH or EKE or something
similar.
> While it is also obvious to think of public-key encryption as somehow
> offering an answer, this does not seem apparent. While PK systems
> solve the problem of key interchange between cooperating parties, they
> do not solve this problem, since encryption and decryption must be
> essentially automated.
>
> Does anyone know of any research that has been done in this area?. For
> example, might it be possible to use an infrastructure such as
> Kerberos in order to grant a ticket which would allow access to an
> RDBMS?
Yes, that should work as well, though I don't know of any databases that
use such. You would probably have to add kerberos yourself.
> Since most RDBMS products don't integrate directly with authentication
> services such as Kerberos, there has to be some secure way to
> transform a ticket into a set of logon credentials.
>
> Essentially any solution, however it is implemented must
>
> 1. Work with RDBMS products for which the only authentication
> mechanism is to supply a login and password
>
> 2. Prevent a user from determining the actual login and password used
> to connect to the RDBMS, even though the user knows their own login
> credentials.
>
> 3. Prevent a knowledgeable outsider from penetrating the system by
> avoiding a fixed algorithm.
>
> I should be most interested if anyone can offer any assistance in this
> area. Because all good security systems are absolutely open in their
> implementation, I would much prefer to discuss these issues openly in
> this forum rather than via email.
My last idea for doing this, is to use SSH. It probably can do
everything needed, and encrypt the communication channel as well.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: Sat, 26 Aug 2000 04:01:13 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Tim Tyler wrote:
> >
> > In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > : Mok-Kong Shen wrote:
> > :> Tim Tyler wrote:
> > :> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > :> > : Tim Tyler schrieb:
> > :> > :> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > :> > :> I observe that you omit any form of detection of collisions
> > :> > :> between the first components of B. Without such a check the
> > :> > :> result does not form a truly unbiased random permutation
[...]
> > :> >
> > :> > : That collision is to be resolved by the sorting process.
> > :> > : One has to decide on a resolution rule, though.
> > :> >
> > :> > No resolution in the sort routine can possibly produce an
> > :> > unbiased sequence.
> > :> >
> > :> > You can see this by a counting arument, after observing that n!
> > :> > doesn't usually divide exactly into 2^(n * x) very well [x is
the
> > :> > width of the RNG output in bits].
> > :>
> > :> I am not yet convinced. You have to consider from a probabilistic
> > :> point of view, i.e. consider a large number of occurences
> > :> and the average effects [...]
> >
> > : If the collision resolution is chosen such that the first
> > : element of the pair is always considered less than the
> > : second, then indeed there is a bias. The effect is [usually
small].
> > : One can on the other hand use a random choice rule to resolve
> > : collision, in which case no bias can occur.
> >
> > Yes. It was not correct for me to have written: "No resolution
> > in the sort routine can possibly produce an unbiased sequence."
> >
> > As you say, use of a rule based on bits from the random stream
> > would be likely to provide a possible way of removing the bias.
>
> Here's a foolish question: What if you simply sorted your original
array
> using (random()%2 ? 1 : -1) as your comparison function? While I'm
> certain that there has to be something wrong with this (because it
> sounds so simple and noone seems to have suggested it), I don't know
> what it is... especially if your sort routine tries to do the minimum
> number of comparisons.
Use your idea with a base-2 radix sort where instead of sorting
normally the 1 and 0 bits into the different tables, use the prng to
select where each goes.
The radix sort is a nlog2(n) algorithm so it touches each element the
same number of times.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: 26 Aug 2000 04:33:07 GMT
Scott Fluhrer wrote:
>(This is a big IIRC, because it's been a while) The JAM instruction would
>also cycle the address bus as fast as possible. I believe it was used as an
>initial sanity check during manufacture -- just after fabbing the chip, they
>would forcefeed it a JAM instruction, and if it did anything other than
>cycling the address lines, they knew not to bother with a full test of that
>chip.
IIRC, you are describing the 6800 JAM (AKA CFR, or Catch Fire and Run),
not the 6510 JAM.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Steganography question
Date: 26 Aug 2000 04:37:04 GMT
zapzing wrote:
>And, if your message is encrypted it will be
>indistinguishable from random numbers. So
>hiding random numbers in random numbers should
>not be all that difficult.
There is no requirement that encrypted messages
look like random numbers. It's a common practice,
but often not done (especially in the header part).
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Asymmetric Encryption Algorithms
Date: Fri, 25 Aug 2000 21:53:50 -0700
DJohn37050 wrote:
> NIST in DSA-2 draft said that to protect an AES 256-bit key it was appropriate
> to use a 15,360 bit p and 512-bit q in DSA-2.
Is this online? Why would a signature standard care about protecting
a cipher key?
------------------------------
** 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
******************************
