Cryptography-Digest Digest #249, Volume #12 Wed, 19 Jul 00 23:13:01 EDT
Contents:
Re: VCR+ (Bill Unruh)
Re: PGP US Versions Broken,no good?? (John Myre)
Re: how strong is my own encryption? ("Martin")
VCR+ code generator ([EMAIL PROTECTED])
Re: VCR+ code generator ("Joseph Ashwood")
Re: VCR+ code generator (Kile Mornay)
Re: Bit Shuffling ("Paul Pires")
Re: On intermixing as encryption processing (Jayant Shukla)
Re: New Idea - Cipher on a Disk ([EMAIL PROTECTED])
Re: New Idea - Cipher on a Disk ([EMAIL PROTECTED])
Re: New Idea - Cipher on a Disk (Thor Arne Johansen)
Re: TAGGED INFORMATION ("Fred Renner")
Re: quantum cryptography ("David Sowinski")
Re: VCR+ code generator ("Brash")
Re: telephone encryption. (Doug Stell)
Re: TAGGED INFORMATION ("Mikal 606")
Help with getting started. (Chris)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: alt.video.vcr,alt.2600
Subject: Re: VCR+
Date: 19 Jul 2000 20:43:16 GMT
In <OAdrYra8$GA.399@cpmsnbbsa08> "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
>> Is there any publicly available software tool that can generate the
>> VCR+ code?
>Yes.
The stuff I saw a few years ago was only for something like 7 digit VCR+.
Ie, they had not figured out the complete encoding.
>From the README of one implimentation
1. They only work for the usual kinds of tv shows,
a. Must start on an even half-hour or hour
b. Must end on an even half-hour or hour
2. They only handle VCRPLUS code values that are 1-6 digits
long (these are the ones that start and end on
half-hour or hour boundaries)
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: PGP US Versions Broken,no good??
Date: Wed, 19 Jul 2000 14:48:23 -0600
Bill Unruh wrote:
>
> In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Mark Wooding) writes:
<snip>
> >DSA signatures are randomized. It's not possible to be sure, just by
> >looking at a signature, that it doesn't contain a subliminal channel
> >which (say) leaks bits of your secret key. You must audit your PGP
> >source.
>
> Uh, no, otherwise it cannot be a signature-- it must be checkable. Ie,
> the signature may vary, but it will vary in a deterministic way.
No, Mark is correct.
<snip>
> Any source of public randomness in any part of the algorithm is
> source of leakage ( since the random number could be generated by
> encoding some information you want to leak with some encryption, which
> only the outside leak user knows.) You do not want to use an algorithm
> with random output without having the source.
Which is exactly Mark's point: DSA is such an algorithm. There
are many correct signatures for any given message and private
key, since a (supposedly) random value is part of the algorithm.
JM
------------------------------
From: "Martin" <[EMAIL PROTECTED]>
Subject: Re: how strong is my own encryption?
Date: Wed, 19 Jul 2000 21:53:02 +0100
Eric Hambuch <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote:
> >
> > Hi everybody!
> >
> > I may sound like an idiot, looking at all the algorithms here and
> > there, I'm sure my algorithm isn't something, anyway here's the
> > question:
> >
> > How long would it take to crack down this type of encryption
> > (suppose you have the source code of the encryption software):
>
> With a computer and some KB of ciphertext: some seconds. This can be
> done by a simple statistical analysis of the ciphertext.
>
> > and here's another question, what if I increase the password from
> > 5 to 8 chars to let's say 20 chars, will it help or not?
>
> No, not really.
>
> Eric
I'm quite new to this crytology thing and I was wondering how you would do
the statistical analysis?
Martin
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.2600,alt.video.vcr
Subject: VCR+ code generator
Date: Wed, 19 Jul 2000 21:01:04 GMT
Is there any publicly available program that can generate VCR+ codes?
Thanks. Bon.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: VCR+ code generator
Date: Wed, 19 Jul 2000 14:42:35 -0700
Crossposted-To: alt.2600,alt.video.vcr
Benji,
Just quick note. Sci.crypt is not the place to ask about this stuff. I doubt
alt.video.vcr is correct either. I don't usually deal with alt.2600 so I
don't know about them.
Joe
<[EMAIL PROTECTED]> wrote in message news:8l54u2$ae7$[EMAIL PROTECTED]...
> Is there any publicly available program that can generate VCR+ codes?
> Thanks. Bon.
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kile Mornay)
Crossposted-To: alt.2600,alt.video.vcr
Subject: Re: VCR+ code generator
Date: Wed, 19 Jul 2000 22:06:03 GMT
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>Benji,
>Just quick note. Sci.crypt is not the place to ask about this stuff.
Actually, sci.crypt is the perfect place to ask. The VCR+ scheme is very
much a cryptography issue.
--
"Kile Mornay" is actually 4103 789256 <[EMAIL PROTECTED]>.
0123 456789 <- Use this key to decode my email address and name.
Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Bit Shuffling
Date: Wed, 19 Jul 2000 15:30:59 -0700
John Myre <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Pires wrote:
> >
> > The "Bandwidth" of the US PTO is putrid. If it was filed in mid 98, I
> > wouldn't expect to see anything until late 2000 IF it flew perfectly
with no
> > pesky office actions to deal with.
>
> I'd call that "response time" rather than "bandwidth".
Opinions vary :-)
>
> :)
> JM
------------------------------
From: [EMAIL PROTECTED] (Jayant Shukla)
Subject: Re: On intermixing as encryption processing
Date: 19 Jul 2000 22:18:43 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
>Let two ciphertext bit sequences c1_i and c2_i be given,
>e.g. being outputs from some block ciphers. With a
>real-valued uniformly distributed pseudo-random variable
>r() in [0,1), we can do multiplexing to produce one combined
>bit stream u_i as follows:
> i=j=k=0;
> do
> i=i+1;
> if r() < 0.5 then j=j+1; u_i = c1_j
> else k=k+1; u_i = c2_k fi;
> od
>That is, we intermix the bits of the two given streams in
>such a manner that the resulting bits have equal chance of
>being originated from the one stream or the other.
so now you have a scheme and another key that
will do this mixing. I am assuming that the
scheme can be made public.
>Obviously this materially enhances the difficulty of the
>opponent, since he has to identify (guess) which bits of
>u_i belong to the first stream and which to the second.
>For example, if the given bit streams are outputs from a 64
>bit block cipher which the opponent happens to have some
>effective method of attack, a failure by 1 bit in collecting
>together the 64 bits that belong to a ciphertext block is
>sufficient to render his efforts futile.
it does enhance the difficulty in building an attack on the
cipher. The increase in difficulty comes from the extra key
that is used for mixing. Practically speaking, this is just
a new cipher with bigger block and key size. See the
explanation below:
Your original operations are:
c1 = cipher1(p1,k1) --- first stream
c2 = cipher2(p2,k2) --- second stream
c3 = mix(c1, c2, k3) --- combined stream
now view this as:
c3 = cipher3(p1p2, k1,k2,k3)
The new cipher (cipher3) takes an input that is twice
as big as cipher1 or cipher2. The new plain text (p1p2)
is simply the old plain texts, p1 and p2, concatenated
together. The key is three times as big as the ones
used in cipher1 or cipher2. When you build an attack
on this cipher you will use plain-text and cipher-text
pairs that are twice the size (assuming cipher1
and cipher2 use same size blocks) of the original
ciphers.
Similarly, all other variants of the mixing scheme
can be can be shown to be equivalent to a new cipher
with a larger block size.
regards,
Jayant
------------------------------
Subject: Re: New Idea - Cipher on a Disk
From: [EMAIL PROTECTED]
Date: 19 Jul 2000 17:14:06 -0600
[EMAIL PROTECTED] (Mack) writes:
> >Is this not best achieved by having a user generated key and
> >encryption process on a smart card (user may have as many cards as
> >they wish), which requires biometrics to operate. All PCs and
> >appliances have a slot for the card, all operating systems compluy
> >with open standards for the inciorporation of the card based processes
> >in their security model.
>
> Smart cards aren't the best answer by themselves. What happens if
> the card is lost or stolen? If it can be easily duplicated then
> stolen cards are a problem. If they are impossible to duplicate
> then lost cards are a problem.
Cards are easy to duplicate if you have the necessary secrets and hard
otherwise.
> Building readers and an OS interface should not be a major problem.
> Microsoft has the power to bully everyone into accepting some kind
> of standard. I believe there is already a standard for smart card
> hardware interfaces already. I don't know about a software
> interface though.
I'm not sure what you mean by software and hardware interfaces here.
The state of the industry is:
1. There is a single, well-accepted standard for the physical and
electrical interfaces to contact-type smart cards (defined in ISO
7816, sections 1 through 3).
2. There are multiple standard protocols for communications between
cards and readers, and two of them are widely implemented (T=0 and
T=1).
3. There are no good standards for the semantics of communications
between cards and readers. Every card vendor defines their own
command set.
4. There are no standard hardware interfaces for attaching a smart
card reader to a host (although RS-232 and USB are common
choices).
5. There is a standard software interface for connecting smart card
readers to hosts, called PC/SC. Windows 98 and Windows 2000
provide this interface, it can be added to Windows 95, and I
believe Macintosh and Linux implementations exist. Every reader
vendor must provide PC/SC drivers for each platform. Just like
printer drivers, etc.
Shawn.
------------------------------
Subject: Re: New Idea - Cipher on a Disk
From: [EMAIL PROTECTED]
Date: 19 Jul 2000 17:32:45 -0600
[EMAIL PROTECTED] writes:
> On 16 Jul 2000 05:47:48 GMT, [EMAIL PROTECTED] (Mack) wrote:
> It is quite feasible to construct the card so that it is
> tamper proof.
Nope. Not only is this hard, it's so hard that no one knows how to do
it, and moreover it's almost certainly impossible.
However, cards can be made to be tamper resistant, and they can be
difficult enough to penetrate that very expensive people and equipment
are required. If your enemy is a government, and they really, really
want to get you, don't rely on a smart card keeping secrets from them.
> Embedding a standard method into the OS security model is the critical
> development. I have suggested it to Microsoft. I'll be surprised if
> they dont produce something like this. Mind you the Linux crowd could
> do it pretty quick, although someone would have to produce the
> smartcard. That would put the heat on the proprietary OS mob to catch
> up or lose market share.
A standard method for what? Windows 2000 already includes a standard
method for smart card-based login. AFAIK nothing like this has been
done for Linux, but it could be done very quickly, as you say.
> >The best security would require a passphrase, a fingerprint and
> >a token. After all if your opponent is an oppresive police force
> >they may not have any compunction about cutting off a finger to
> >get a good fingerprint.
>
> I believe the biomechanics used for fingerprint recognition will not
> recognise the finger if the person is dead or the finger is detached.
> But this doesn't stop someone (eg a mugger) forcing you to use the
> card.
Some biometric devices attempt to detect whether or not the finger (or
retina, or hand, or face, or ...) is alive, via body heat, pulse, etc.
Any system one engineer can build another can fool, however.
Also, biometric authentication is trivially vulnerable to replay
attacks. The data must be digitized to be passed to the card, which
means that all an attacker needs to do is to get you to stick your
finger (or whatever) in some device that they've managed to subvert.
Once they have the data they can reuse it at will (a significant
problem with biometrics, IMO -- you can always make up a new password,
but you only have 10 fingers, two eyes, two hands, one face, etc.).
There do exist card-embeddable fingerprint readers, so the biometric
data never needs to leave the card, but card-embeddable readers must
be simple, low-power devices, making them easier to fool.
> I suspect finger print recognition on a card is the easiest, but one
> could use a 4 number pin, and simply code the card so that it locks up
> after 4-5 failed attempts.
And one could use more than four digits, as well. Card locking
introduces its own issues, but this is the standard approach.
Shawn.
------------------------------
From: Thor Arne Johansen <[EMAIL PROTECTED]>
Subject: Re: New Idea - Cipher on a Disk
Date: Thu, 20 Jul 2000 03:04:48 +0200
Greg wrote:
>
> > Greg wrote:
> >
> > > I was looking over a thread on the question of adding hardware
> > > support to a CPU. The problem there is that the CPU must be
> > > flexible enough to support various types of ciphers if you go
> > > that route.
> > >
> > > What if a disk drive came with a cipher on the disk, and supported
> > > a new ATA instruction set that took advantage of these ciphers?
> > >
[snip]
Most disk drives (ATA4+) already has a built in security mode. The
"security" comes from refusing to execute ATA commands unless the drive
is unlocked. It sounds to me that one could extend this feature set to
also include encyption in addition to just refusing the user the data.
That way, no new ATA commands would have to be added.
BR,
Thor A. Johansen
------------------------------
From: "Fred Renner" <[EMAIL PROTECTED]>
Subject: Re: TAGGED INFORMATION
Date: Thu, 20 Jul 2000 01:02:49 GMT
This has been observed, studied, used, and also figured prominently in one
of the Clancy novels as the "smoking word processor".
------------------------------
From: "David Sowinski" <[EMAIL PROTECTED]>
Subject: Re: quantum cryptography
Date: Wed, 19 Jul 2000 20:21:53 -0500
<[EMAIL PROTECTED]> wrote in message
news:8l2d2g$8kl$[EMAIL PROTECTED]...
> Anyone that's interested, here's a decent book on quantum cryptography.
> Go to chapter 8. "The Code Book: The Evolution of Secrecy From Mary
> Queen of Scots to Quantum Cryptography", by Simon Singh.
> public key at idap://certserver.pgp.com ([EMAIL PROTECTED])
A few other really good books (listed from more technical to less technical)
are:
The Physics of Quantum Information, D. Bouwmeester, A. Ekert, and A.
Zeilinger, Springer, 2000
Exploration in Quantum Computing, C. Williams and S. Clearwater, Springer,
1997
Feynman Lectures on Computation, A. Hey and R. Allen Eds., Perseus Books,
1996
Feynman and Computation, A. Hey Ed., Perseus Books, 1999
The Feynman Processor, G. Milburn, Perseus Books, 1998
See also http://xxx.lanl.gov/archive/quant-ph for many up-to-date preprints.
-dave
====== 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: "Brash" <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.video.vcr
Subject: Re: VCR+ code generator
Date: Wed, 19 Jul 2000 22:31:01 -0400
"Kile Mornay" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>
> >Benji,
> >Just quick note. Sci.crypt is not the place to ask about this stuff.
>
> Actually, sci.crypt is the perfect place to ask. The VCR+ scheme is very
> much a cryptography issue.
And seeing as how every topic ever imaginable somehow seems to get
crossposted to alt.2600, it's perfectly fine to post here.
Hope you are willing to weed through all the sarcastic replies, though. ;-)
Brash
--
0h y0rdshch!
> --
> "Kile Mornay" is actually 4103 789256 <[EMAIL PROTECTED]>.
> 0123 456789 <- Use this key to decode my email address and name.
> Play Five by Five Poker at http://www.5X5poker.com.
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: telephone encryption.
Date: Wed, 19 Jul 2000 23:09:42 GMT
On Wed, 19 Jul 2000 09:22:30 -0400, "George Gordon"
<[EMAIL PROTECTED]> wrote:
>I saw a telephone encryption device in the August North American edition of
>Popular Science. Page 24. The device called Privatel is made by L-3
>Communications. It says it uses 168-bit encryption. I am in no way
>associated with this company. My question is: 3DES? Key-Escrow??
The web site on the product is the following.
http://www.l-3com.com/cs-east/programs/infosec/privatel.htm
> 3DES?
The product description says that it does use 3 DES. For a commercial
product, a broadly familiar algorithm would be the logical choice
> Key escrow?
The product description says that it uses 1024 bit Diffie-Hellman with
a 245 bit exponent. The FAQ states; "The keys are never stored, and
there is no key escrow or other means of accessing the encryption
algorithm."
I can probably guess at what protocol the phones use, since there was
a joint effort among several companies for the US government. The
protocol could also be used for commercial purposes.
------------------------------
From: "Mikal 606" <[EMAIL PROTECTED]>
Subject: Re: TAGGED INFORMATION
Date: Wed, 19 Jul 2000 22:50:28 -0700
What if the recipient knows but doesnt give it away?
Or you find the information removed, what are your thought processes at that
point?
MiKal
3,3,3,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:eN9ubra8$GA.462@cpmsnbbsa08...
> It's called steganography. What you're doing is a fairly novel use of it
> (using it to track the spread of something), but it's the same idea. One
of
> the currently used examples is the low order bit of WAV files, you can
> change it without significantly effecting the quality of the recording.
> Joe
>
> "+wuff" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I use "tagged information" to track connections at times, and it never
> > fails to work. I weave additional info into something I like to see if
> > it makes its way around... and this additional info can not be removed
> > if the recipient does not know about that.
> >
> > Does anyone have systematic information about that ? Was anything
> > written up in a book about it ?
> >
> > +swiss+wuff+ http://www.swisswuff.ch
> >
>
>
------------------------------
From: Chris <[EMAIL PROTECTED]>
Subject: Help with getting started.
Date: 20 Jul 2000 02:53:37 GMT
Could someone with more experience on the subject point me in the right
direction on how to go about deciphering text encrypted with the following
algorithm?
Start with an arbitrary length password and 32 arrays of 256 random bits
each (call them array0 to array31) and the text to be encrypted (call it
text). array0 may be entered with the password, the other 31 arrays are
preset.
xor the password across the length of array0 (i.e. after the last
character of the password use the first one again etc) and call it array0
separate array0 into 32 8bit segments (seg0 to seg32)
if seg0 is even, xor array0 across the length of the text to be encrypted
and call the result text
if seg0 is odd flip every two characters around (e.g. 012345 will become
103254) and then xor array0 across text to get text
if seg1 is even xor array1 across text (the result from above)
if seg1 is odd xor array2 across text from the previous function.
If seg2 is even, reverse the password (e.g. 01234 will become 43210) and
xor it across array 3. Xor array3 across text.
If seg2 is odd reverse the bits (e.g. 010011 to 110010 )in array3. xor
array4 across text.
If seg3 is even copy the first half of array3 to the second half of
array5
If seg3 is odd copy the 2nd half of aray3 to the second half of array5
If seg4 is even xor array5 across text.
If seg4 is odd reverse the bits (e.g. 010011 to 110010 )in array5. xor
array5 across text.
Well anyway, you get the picture. This goes on until seg31 doing some
useless and perhaps time consuming combination of xors and rotation of
characters depending on whether each segment is odd or even. I came up
with all these crap before I had any idea about actual useful encryption
algorithms back when I was a freshman.
Now that I have a little more free time I decided to look further into
breaking codes rather than creating them. Other than trying one password
after the other and array0 i.e. brute force what would be the best way to
go about it? Would enciphering a null string with passwords that only
differ one bit help?
I only have this program compiled for HP-UX that I no longer have access
to and I need to modify it before I get it to run on my PC.
Any ideas or directions to resources on the subject will be appreciated.
Chris
------------------------------
** 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
******************************
