Cryptography-Digest Digest #389, Volume #12 Wed, 9 Aug 00 17:13:01 EDT
Contents:
Re: Crypto and CCTV (Jim)
Re: Crypto and CCTV (Jim)
Re: Empathic encryption? ("Trevor L. Jackson, III")
Re: Key in ASCII ?? ("Trevor L. Jackson, III")
Re: Cryptography Certifications ("Trevor L. Jackson, III")
Re: chap authentication scheme? (David A. Wagner)
Re: OTP using BBS generator? (Benjamin Goldberg)
Re: Empathic encryption? (Benjamin Goldberg)
Re: counter as IV? (Benjamin Goldberg)
Re: More Secret Conversations ([EMAIL PROTECTED])
Re: Empathic encryption? ("Paul Pires")
Re: Best AES candidates ?? Slow Skipjack might have advantage ("David C. Barber")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Crypto and CCTV
Date: Wed, 09 Aug 2000 17:26:28 GMT
Reply-To: Jim
On Wed, 9 Aug 2000 11:14:52 +0100, "Dave Foulger" <[EMAIL PROTECTED]>
wrote:
>With the rise (especially here in the UK) of public CCTV surveillance I have
>been thinking about how encryption systems could help with 2 of the worries
>I have.
>2) Tampering with evidence (Given the general poor quality of the video
>image and often static background I imagine that the average desktop PC
>could now fake video evidence such as pasting someone walking across the
>frame or changing the date/time info)
To my mind, only the police are likely to tamper with evidence.
>The idea I have in mind would involve encrypting the video as it is recorded
>(on digital video tape, recordable dvd or any other medium). I think that
>some form of public key system might work.
>The public key for encryption would be stored on the video recorder, on a
>smart card or something similar so it could be updated if the private key is
>compromised) . The private key (or keys if using secret sharing) to decrypt
>the video would be held by say one or more senior police officers).
Never heard of any system being available for TV. Perhaps you could
look into how the pay-TV companies do it.
>I would like the video recorder to sign and timestamp the video as it is
>recorded to prevent forgery.
They do this anyway, don't they?
--
Jim Dunnett
amadeus at netcomuk.co.uk
nordland at lineone.net
g4rga at thersgb.net
------------------------------
From: [EMAIL PROTECTED] (Jim)
Subject: Re: Crypto and CCTV
Date: Wed, 09 Aug 2000 17:26:29 GMT
Reply-To: Jim
On Wed, 9 Aug 2000 14:20:03 +0100, Tom Anderson <[EMAIL PROTECTED]>
wrote:
>On Wed, 9 Aug 2000, Dave Foulger wrote:
>
>> With the rise (especially here in the UK) of public CCTV surveillance
>
>i assume by this you mean CCTV surveillance of public places, eg streets,
>railway stations, shops, etc. places anyone can enter. this assumption
>underlies the rest of this post ...
>
>> I have been thinking about how encryption systems could help with 2 of
>> the worries I have.
>>
>> 1) Unauthorised use of CCTV material. (Blackmail, unauthorised release to
>> press etc.)
>
>this worry seems to imply that you think CCTV recordings should be private
>information - held only by the police, council, or some other hopefully
>trustworthy public body. now, given that these are recordings of things
>which happened in public, why do you think this?
>
>this comes from a suggestion i read of (in Wired, hence the rather dotty
>libertarian-style point of view) which addresses both your worries. this
>was that CCTV output should be broadcast on public TV (there are plenty of
>unused channels, and most transmissions could be very local).
Totally illegal in the UK. Local or not, the Radiocommunications
Agency would catch you in a day or two. Fines, imprisonment and
confiscation of equipment would follow.
But you probably already realise this!
--
Jim Dunnett
amadeus at netcomuk.co.uk
nordland at lineone.net
g4rga at thersgb.net
------------------------------
Date: Wed, 09 Aug 2000 14:41:42 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Empathic encryption?
The Karnak Attack is a fake. It was popularized by Johnny Carson on the Tonight
Show. The procedure is to hold the envelope up to your forehead and divine the
contents without disclosing the ineffable method.
Paul Pires wrote:
> Arghhhhh.... I wish I understood more than one in three posts.
>
> Paul
>
> Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Look, it's the Karnak Attack in sheep's clothing. He's not going to get
> *any*
> > benefit from it.
> >
> > Paul Pires wrote:
> >
> > > Terry Ritter <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > >
> > > > On Tue, 8 Aug 2000 10:37:28 -0700, in
> > > > <IBXj5.2696$[EMAIL PROTECTED]>, in sci.crypt "Paul
> > > > Pires" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >The countdown begins....... <[EMAIL PROTECTED]> wrote in message
> > > > >news:[EMAIL PROTECTED]...
> > > > >> May contain proprietary information. All rights reserved.
> > > > >
> > > > ><Snip>
> > > > >
> > > > >I must be in a grouchy mood... This is a joke, right? This disclaimer
> is
> > > > >silly! And in this group, you are waiving a red flag before bulls.
> > > >
> > > > I don't know why that would be a red flag: Cryptography has a long
> > > > history of intellectual property.
> > >
> > > Nice dodge.
> > > >
> > > >
> > > > >1, If it is patent rights you wish to protect by it, it don't work.
> You
> > > have
> > > > >publicly disclosed (well sort of). The law offers no exemptions for
> > > > >disclosure under a disclaimer.
> > > >
> > > > In the U.S., a patent application may be submitted up to a year after
> > > > full public disclosure. Even that assumes the original posting was
> > > > sufficiently precise as to say how the patented thing works.
> > >
> > > All true, but you miss my point. The disclaimer does not treat or modify
> any
> > > of the above. It has no purpose other than to sound legalistic.
> > >
> > > > >2, If it is copyright you wish to protect, well, you screwed the
> pooch
> > > there
> > > > >too since you did not supply the tiny (but required stock wording).
> > > >
> > > > Stock wording has not been required for copyright for years.
> > > > Copyright protection is now inherent in the production of an
> > > > individual work.
> > >
> > > I'll have to check but I think you still need to say who you are (Name)
> and
> > > date it. This posting qualifies as an anonymous public disclosure. I
> doubt
> > > that the PGP signature qualifies.
> > > >
> > > >
> > > > >3, All rights reserved for what it MAY contain? (coverin all bases
> aren't
> > > > >ya). Well the law (as I understand it) provides that recipients
> (after
> > > they
> > > > >have agreed to terms) only need to show the same level of diligence
> to
> > > > >proprietary information that the owner has shown. You posted it to a
> news
> > > > >group!
> > > >
> > > > Not all rights are destroyed simply by posting to a newsgroup:
> > > > Posting probably implies a license to distribute copies of the
> > > > posting, but it is not a license to put someone else's name on those
> > > > words.
> > >
> > > Sounds right.
> > >
> > > Once again, my point was that the disclaimer did not do anything to
> effect
> > > those rights. Upon re-reading my original post, I need to upgrade the
> > > earlier rating of grumpy to bitchy. My apologies. I do have a point
> though.
> > > Much confusion about IP and the practices used to regulate it is
> generated
> > > by miss-information. When I see bizzare stuff, I just gotta comment.
> > > >
> > > > ---
> > > > Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> > > > Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
> > > >
> >
------------------------------
Date: Wed, 09 Aug 2000 14:50:49 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Key in ASCII ??
Guy Macon wrote:
> Steve Rush wrote:
>
> >Since English ASCII text has a little more than one bit of entropy per
> >character, every serious cryptosystem that uses keyboard entry of the
> >key requires a passphrase at least eight times as long as the key,
> >and crunches the input with some kind of hash function.
>
> One bit per character seems low. That would imply that I could
> often guess an 8 character password in about 250 tries and a
> 16 character password in about 65,000 tries. I write custom
> dictionary-based password guessing programs on a regular basis,
> and I know that those numbers are way low.
>
> Could it be that you are using statistics for normal length and
> vocabulary english prose and assuming that the statistics apply
> to short passwords or passphrases?
You are using an inappropriate model by assuming that the characters are
independent. The actual estimate means you can successfully predict the next
character of a text stream about half the time.
The edge effects distort that. For example, the statistics are not helpful in
dealing with the first character. And they wildly overestimate the entropy in
the last character of "supercalifragilisticexpialadociou?"
------------------------------
Date: Wed, 09 Aug 2000 14:57:42 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Cryptography Certifications
Joseph Ashwood wrote:
> It basically means that to be good at crypto you have to
> have the right kink in your brain. So to make a long story
> short. How screwed up are your thoughts? I don't mean
> homocidal tendancies, I mean the ability to given the same
> starting point as everyone else, come to a completely
> different, probably quite foolish (although quite correct)
> conclusion. Oh and how good are you at getting people to
> believe that conculsion. In some ways you also have to be
> rather obsessive about practices. For example I had an
> instructor (I won't give him the honor of being called
> professor) who got rather irate at me when everytime he
> discussed an algorithm to do something and asked what the
> first thing we need to do, and I would respond "Prove it
> works." The step I came up with, was self-evident to me,
> before we bother to find out how fast/scalale/etc the
> algorithm is, we need to establish that it actually works.
Hmmm, correctness over performance? NIST doesn't seem to order their
priorities that way.
That's not a dig at NIST, it's an observation that applies to the crypto
field. Given your predilection for correctness, why did you pick a field in
which it is undetectable?
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: chap authentication scheme?
Date: 9 Aug 2000 11:58:22 -0700
Mark Wooding <[EMAIL PROTECTED]> wrote:
> David A. Wagner <[EMAIL PROTECTED]> wrote:
> > Bill Unruh <[EMAIL PROTECTED]> wrote:
> > > The authenticator has a modulus N (prime?) and a generator g. The stuff
> > > stored in the database is
> > > username, salt s, g, N, g^ps modN
> > > The challenge to theuser is
> > > s,N, g^x modN where x is a random number
> > > Response is
> > > (g^x modN)^ps modN
> > > which the authenticator can compare with (g^sp modN)^x modN
> >
> > There is a problem with active attacks. Any malicious party can
> > pretend to be the server, pick a random x, challenge the user, and
> > from the user's response learn the user's password. The user has no
> > way to know that this has happened, since the server is not
> > authenticated in any way.
>
> Can you explain this attack in more detail, please? I can't see how it
> works.
Sure. The fake server can send any g,N he likes, including ones for
which he can compute the discrete log. (I think you mentioned this.)
As a trivial instance, he can pick a small N. This one is detectable, but
there are other subtle ways to send `trapdoor-ed' and otherwise-insecure
choices of g,N. I think this deserves some attention; it looks a little
tricky, if you don't want the user to have to know g,N in advance.
If g,N are fixed and known in advance and hard-coded everywhere, then
this attack doesn't work. But the original post showed them sent on
the wire to the user, which is why I assumed there is an attack.
By the way, there's a second attack here, if you don't expand the password
using, e.g., OAEP. It _does_ apply even if g,N make the discrete log
hard. Suppose you use a truly-random 100-bit quantity as your password p.
You might expect that this would be secure. But it's not. There are
square-root attacks (e.g., Shank's attack) which can take advantage of the
fact that we know h, h^p mod N where p lies in relatively small interval.
This is easy to fix: use OAEP or an equivalent.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Wed, 09 Aug 2000 19:49:44 GMT
Bryan Olson wrote:
[snip]
> No, in that post David Hopwood got it right:
>
> | it has been proven that short cycles happen with negligible
> | probability, if the parameter sizes are such that factoring
> | is hard
>
> > There is a remarkable lack of desire to address this known weakness,
> > even though we know how to do that.
>
> I take a different view: I think showing the failure happens
> with negligible probability is a perfectly valid way to
> address the weakness.
Suppose we have a block cipher with big keys. Further suppose that a
small number of those keys give the identity transformation, and all
other keys are VERY secure. Also, suppose that there's no known way to
find those weak keys without doing a trial encryption, but a trial
encryption is trivial. Weak keys have low probability, but when they
occur, the system is wide open.
With BBS, short cycles occur with low probability, and the system is
very secure when we don't have a short cycle. There's no known way to
detect weather short cycles will occur without explicit testing, but
explicit testing is trivial. If a short cycle does occur, the system is
wide open.
Does anyone see a similarity? Would anyone use the described block
cipher without testing for the identity transformation? Assume that the
identity transformation occurs as often as short BBS cycles.
Personally, I think there exists some kind of futher restriction on the
parameters to BBS which will eliminate short cycles entirely, but we
haven't found it yet. That would be better than explicit testing for
short cycles.
[snip]
> [Klaus Pommerening]:
> > | >BTW the BBS generator outputs the LSB of its internal state
> > | >x_i for each step. (x_i = x_{i-1}^2 mod n)
> > | >Is there any known result that some choice of parameters in BBS
> > | >guarantees that the LSBs don't give short cycles?
> [Ritter:]
> > |Not that I know of. I never even thought of investigating such a
> > |thing on my small models. I guess I assumed that sort of thing
> > |was exactly what the proofs guaranteed.
>
> Yes, exactly the kind of thing I've pointed out both before
> and after that post: the long cycle filter doesn't imply
> there's no case in which particular parameters fail (though I
> don't know if this kind of failure is possible). But why,
> after reading the paper, citing the paper, and accusing
> everyone else of not reading the whole paper, were you still
> _assuming_ what the proofs guaranteed?
What it seems that Ritter is saying is that he's assuming that if there
are no short cycles in the state then there will be short cycles in the
LSB of the state.
You're response to that seems confused. Or else my understanding of
your response is confused.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Empathic encryption?
Date: Wed, 09 Aug 2000 19:49:54 GMT
I can think of one kind of [bizarre?] stenography for sending
information to a musician. Start with music which has been generated by
a computer following various rules of composition... so it will be a
good, well formed, though probably unimaginative piece of music. Then,
every nth note, change that note so that it is, to a professional
musician, obviously not right, and where, hopefully, the note that
*should* be there, is also obvious. The difference between the note
that *is*, and the note that *should be* is one nibble of data. Print
the data as sheet music, and send it in the mail. Or even send it by
email, as a midi... It would, after all, be a valid midi; Of course,
you'd have to be a musical genious to be able to decode it by just
listening to it.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: counter as IV?
Date: Wed, 09 Aug 2000 20:17:12 GMT
David A. Wagner wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Hmm, what about a modified CBC encryption, where instead of XORing
> > the first block of plaintext with the IV before encrypting, we
> > encrypt the IV, *then* XOR it with the first plaintext block. Then,
> > a counter as IV would probably be perfectly fine.
>
> If you ensure that the plaintext-encryption key is independent of the
> counter-encryption key, then sure, it's perfectly fine.
Why must we have two keys here? What kind of attack is there on this
scheme? The first block of ciphertext [where E_K is encipher with key
K], is E_K( pt[0] XOR E_K(IV) ).
> It is just one instance of a more general schema: apply any PRF to a
> counter, and use the result as your IV. Since any secure block cipher
> is also a secure PRF (as long as you don't try to use it for more than
> 2^32 blocks -- the birthday bound), this is safe.
Where do you get 2^32 from? If I have a 128 bit block cipher, it takes
*many* more blocks than that to get a ciphertext collision: 2^127, to
get probability >= 50% for a collision.
> I suspect you had done a premature optimization, and were thinking of
> using the same key for both text-encryption and counter-encryption.
> I would advise against that. It voids the security warranty; the
> proof of security is no longer valid.
Why do you advise against it? How does it 'void the security warranty'?
No cipher [other than TOTP] is PROVEN secure... how does using the same
key in both places make our scheme less secure?
> And it's not at all clear that it's safe to use the same key for both
> uses. I suspect that this optimization might introduce
> certificational weaknesses in some threat models. Maybe the attacks
> are exotic enough that they wouldn't be too much of a concern in
> practice, but you'd have to do an in-depth analysis of all the
> attacks. It seems more prudent to go with the mode that has a proof
> of security against even exotic attacks, i.e., independent keying.
Please explain this. I've heard *once* before someone claim that there
existed attacks on using the same key to encrypt the IV as the
plaintext, but I have not ever seen one.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: More Secret Conversations
Date: Wed, 09 Aug 2000 20:12:53 GMT
"teach" may be a bad word. Better use "prove to" or "convince".
Technical knowledge is also based on a series of assumptions. You can
show that something is wrong based on some axioms, but you can't prove
that something is right unless you are God. In other words, he maybe
wrong, but most likely, you are also wrong.
--Sisi
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> The Master is wrong, BTW - it is worthwhile to try to teach people
where
> they are making mistakes, and this does not necessarily involve
imposing
> your worldview on them. This is particularly true for technical
subjects,
> but it's also true in general.
>
> - --
> David Hopwood <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Empathic encryption?
Date: Wed, 9 Aug 2000 11:44:32 -0700
You got me! I am old enough to treasure all of those Carson gags.
Every time I think you are serious I find that you have the waders on again.
Keeps one humble.
Thanks
Paul
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The Karnak Attack is a fake. It was popularized by Johnny Carson on the
Tonight
> Show. The procedure is to hold the envelope up to your forehead and
divine the
> contents without disclosing the ineffable method.
>
> Paul Pires wrote:
>
> > Arghhhhh.... I wish I understood more than one in three posts.
> >
> > Paul
<Snip>
------------------------------
From: "David C. Barber" <[EMAIL PROTECTED]>
Subject: Re: Best AES candidates ?? Slow Skipjack might have advantage
Date: Wed, 9 Aug 2000 13:30:00 -0700
There are some advantages to slow algorithms. A slow algorithm can greatly
hamper a brute force attack. The original Unix crypt function listed that
as one of its security advantages. (Of course, fastCrypt was eventually
written, but I have yet to hear of fastSkipjack.) Did anyone else think of
that while complaining about it? :^)
*David Barber*
"Doug Stell" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >Mark Wooding wrote:
>
> > * Skipjack. (NSA design. Dog slow.)
>
> Of all the algorithms implemented on the Motorola Advanced INFOSEC
> Machine (AIM), Skipjack is by far the slowest. Even the most
> complicated of the high-grade legacy algorithms is considerably faster
> and a modern high-grade algorithm is an order of magnitude faster than
> Skipjack.
>
------------------------------
** 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
******************************
