Cryptography-Digest Digest #113, Volume #12 Mon, 26 Jun 00 23:13:01 EDT
Contents:
Re: Surrendering Keys, I think not. ("Harvey Rook")
Re: Surrendering Keys, I think not. (zapzing)
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (zapzing)
Re: How Uncertain? (Mok-Kong Shen)
Re: Idea or 3DES (Chem-R-Us)
Re: Encryption on missing hard-drives (Mike Andrews)
Re: Weight of Digital Signatures (Rex Stewart)
Re: Weight of Digital Signatures ("Lyalc")
Re: How Uncertain? ("ben handley")
Re: How Uncertain? (wtshaw)
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (wtshaw)
Re: Surrendering Keys, I think not. (wtshaw)
unable to use HIGH ENCRYPTION on IIS 5.0 (1024 bit key) ("Phil")
Re: Idea or 3DES (Steve)
----------------------------------------------------------------------------
From: "Harvey Rook" <[EMAIL PROTECTED]>
Subject: Re: Surrendering Keys, I think not.
Date: Mon, 26 Jun 2000 15:21:54 -0700
How do you convince the opponent that you are using an OTP? Because you told
him, and you provided a sample OTP+plain text? This is security though
obscurity. In the long run it doesn't work.
Harvey Rook
[EMAIL PROTECTED]
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...> The problem with all
these suggestions, is that all these OTP or
> equivlent keys take an equal space to the message.
>
> What i'm suggesting is more subtle:
>
> I'm saying that since the output of a cipher is
> indistinguishable from random data, that it could be used to
> masquerade as a OTP.
>
> U'd take another document, XOR it with the cipher-text, this
> would give you a dummy key. U then surrender this key, instead
> of the proper key used with the algorithm.
>
> I think this is a good idea, because the legatimate owner of the
> encrypted file only has to enter their encryption key to decrypt
> the file. It take nearly no extra effort to make the false key,
> and doesn't affect normal use of the file atall.
>
> There is no way they could prove that it isn't a OTP, unless
> they brute-forced the underlying algorithm.
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Surrendering Keys, I think not.
Date: Mon, 26 Jun 2000 22:15:18 GMT
In article <8j8ac4$pvc$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Simon Johnson wrote:
> > > I was wondering how they would ever be able to *prove* that this
> > > key is correct. Since one of the requirements for the AES is
> > > that the output of data encryption produces cipher-text that
> > > cannot be told apart from random data. If some person said the
> > > cipher-text was a message encrypted using an OTP, then the
> > > police must brute-force the underlying algorithm to prove
> > > otherwise.
> >
> > The decryption key (which is what must be provided) would produce
> > putative plaintext that could readily be validated. With nearly
> > any decent cryptosystem, using the wrong decryption key produces
> > "random" noise, not a coherent plaintext, so it would be obvious.
>
> U're missing my point entirely......
>
> To point this out:
>
> Prerequisties:
>
> A 'Good' encryption algorithm and a key, E_k().
> A Real piece of plain-text, T_0
> A Piece of non-incriminating plain-text, T_1
>
> Method:
> C=E_k(T_0)
> Dummy-Key = C XOR T_1
>
> The officials can't prove it isn't a one time pad, so they are forced
> to recover using the plain-text using the dummy key provided:
> T_1 = C XOR Dummy-Key.
The police may want to see that the recipient also has a copy
of the OTP. The recipient, however, cannot have a message
he has not recieved yet. Dummy_Key, you will observe, depends
on the message sent. What happens if the police intercept the
message, preventing the intended recipient from recieving it,
and then demand of the recipient that he produce the OTP ?
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: zapzing <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Date: Mon, 26 Jun 2000 22:20:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> zapzing wrote:
> > If you still disagree, I challenge you to
> > present a "compression" algorithm that will
> > compress *all* files without loss of
> > information.
>
> Actually, it's theoretically impossible, assuming the input alphabet
is the
> same as the output alphabet. Otherwise, one could keep feeding the
output
> back into the input until you reached a minimum size (1 byte or
whatever).
>
Oh, you gave it away!
> --
> Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
> San Diego, CA, USA (PST). Cryptokeys on demand.
> "You know Lewis and Clark?" "You mean Superman?"
>
--
If you know about a retail source of
inexpensive DES chips, please let
me know, thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Date: Tue, 27 Jun 2000 00:46:38 +0200
Future Beacon wrote:
> I am writing also to inquire about this new (to me) use of the word
> "entropy." Is it just a metaphor for uncertainty, or does it have
> a precise quantitative definition in cryptography that is different
> from older statistical terms?
Schneier's AC has some explaination of entropy. I don't know exactly
how the figure there about entropy in printed English (1.3 bits per byte
of ASCII) was obtained. Menezes' HAC gives 1.5 bits. So something
around that should be right in average cases.
M. K. Shen
------------------------------
Date: Mon, 26 Jun 2000 15:43:08 -0700
From: Chem-R-Us <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: Idea or 3DES
jungle wrote:
>
> Lucks from Fast Software Encryption in 1998 explained that :
>
> - about 2^108 steps are sufficient to break triple DES ...
> - when one concentrates on the number of single DES operations & assumes the
> other operations to be much faster, 2^90 steps are sufficient ...
>
> IDEA on the other hand needs 2^128 steps ...
>
> therefore,
> - IDEA should be considered extremely more secure than triple DES ...
> - exactly, from 2^38 to 2^20 steps more secure ...
DES has been much more extensively cryptanalyzed than IDEA. On that
basis alone, it is the more conservative choice (e.g., speed not
withstanding).
--
Chem-R-Us
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: Encryption on missing hard-drives
Date: Mon, 26 Jun 2000 23:22:32 GMT
Scripsit Douglas A. Gwyn <[EMAIL PROTECTED]>:
: Mike Andrews wrote:
:> Absolutely true. It's a page-turner. I'm surprised the military
:> didn't suppress it and turn it into a page-burner.
: That's not the business we're in.
There are other parts of .mil than the ARL. Some of them have
classified people's PhD dissertations right out from under
them; one of my faculty friends told me about one of his PhD
candidates that that happened to. He was head of her committee.
Her dissertation had to do with recognizing content in natural
language texts. IIRC,it was Daddy DIRNSA who came in and took
all her notes and drafts of her dissertation away. She got to
pick a new topic, and the Graduate College let her start her
5-year period over again, but it cost her something like 2
years.
I'd bet money she's not the only one, by a noticeable coefficient.
And then there were the sessions at a conference on optics, where
the presenters had to announce that these presentations were not
open to nationals from foreign countries - or that's what I can
remember of the sytory, anyway. They were UNCLAS, but the
announcements still were required.
I may be naive from time to time, but I'm not blind.
--
A doctor can bury his mistakes but an architect can only advise his
clients to plant vines. -- Frank Lloyd Wright
------------------------------
From: Rex Stewart <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Mon, 26 Jun 2000 23:18:19 GMT
I don't worry so much about someone breaking into
someone's home to steal their key for their digital
signature, (as John Savard's first post in this
thread mentions) but rather, I worry that breaking
into their house might not be nessassary.
I run into three things that makes me scared of what
kind of problems digital signatures might cause for
the current crop of computer users.
1. I had one user tell me "I use the best Antivirus
on the market MSAV" They don't have a clue about
the quality of the security tools they are using.
2. I used to work at a company where I and a couple
others had fancy scripted font signature blocks at
the bottom of our e-mails. Many of them employees
thought that was a "digital signature." And these
were above average in education.
3. I now work in an electronic security firm (not
computer security). I still run into people who
don't know what is at stake with their log on
password and who still run file attachments
promiscuously.
(No, I don't work at Los Alamos :-)
While forgery is an occational problem with hand
written signatures (a good forger can duplicate
most peoples signature close enough to be
indiscernible from the owner of the signature),
the main defense against forgery is to have the
signature witnessed. This could add a whole new
dimention in digital signatures.
Of course the signed under protest bit would
be a good addition too. And maybe a signed
in ignorance for the above problems :-)
I, for one, will just simply NOT "opt in."
I think cyberspace is a great medium for exchange
of ideas and information - but basically lousy
for e-commerce and e-voting. (IMHO)
--
Rex Stewart
PGP Print 9526288F3D0C292D 783D3AB640C2416A
==================================
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> Lyalc wrote:
>
> > I know we are close to discussing legal issues, but
> > the motive behind the signing is important (e.g. coercion
repudiates an
> > otherwise genuine signature). Electronically, we can't really
detect or
> > cater to these sorts of situations - yet.
>
> Are you supposing a signed-under-protest bit?
>
<<cut>>
> [EMAIL PROTECTED] (John Savard) wrote:
>> ...
>>A law that makes a digital signature "just as binding as one in ink",
>>when it is so much easier to break into someone's house and read their
>>hard drive than forge their signature perfectly makes ordinary people
>>much more vulnerable to forgery than before.
> ...
<<cut>>
> >
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Weight of Digital Signatures
Date: Tue, 27 Jun 2000 09:49:40 +1000
A 'signed-under-protest bit' might be meaningless in practical terms.
The intent is, I believe, to allow the system to respond to the user as if
the the signature was entirely normal, but to not effect the requested
action.
This only works if the relying party never provides any feedback to third
parties; consider:
- a bank funds transfer means a third party account is increased
- a sniffer on the line may allow the transmitted data to be verified by the
attacker/coercer, under some electronic signature schemes
- A system logon will have to allow read and write access
Any attacker who doesn't check these actions are valid by using a second,
independent source (perhaps by wireless data, phone, etc) is a bit stupid.
If any of the simple tests above fails, the attacker/coercer knows the
victim is attempting to fool them, with increased potential for consequences
to the victim.
In the end, it seems there may be almost no worthwhile benefits from a
'signed-under-protest bit'
Comments?
Lyal
Trevor L. Jackson, III wrote in message <[EMAIL PROTECTED]>...
>Lyalc wrote:
>
>> I know we are close to discussing legal issues, but
>> the motive behind the signing is important (e.g. coercion repudiates an
>> otherwise genuine signature). Electronically, we can't really detect or
>> cater to these sorts of situations - yet.
>
>Are you supposing a signed-under-protest bit?
>
>>
>> One day, the rule makers will decide how to handle these ambiguous
>> situations.
>> In the meantime, we all play elelctronic signatures "by ear"
>> Lyal
>>
>> Robert Stonehouse wrote in message
>> <[EMAIL PROTECTED]>...
>> >Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> >>Robert Stonehouse wrote:
>> >>> [EMAIL PROTECTED] (John Savard) wrote:
>> >>> ...
>> >>> >A law that makes a digital signature "just as binding as one in
ink",
>> >>> >when it is so much easier to break into someone's house and read
their
>> >>> >hard drive than forge their signature perfectly makes ordinary
people
>> >>> >much more vulnerable to forgery than before.
>> >>> ...
>> >>> The thing that makes an ink signature binding is the fact that it
>> >>> was written by the right person. If your bank pays out on a forged
>> >>> cheque, saying 'Well, it was a perfect forgery' won't help the bank
>> >>> at all. The bank has to make it good to you.
>> >>>
>> >>> It is hard to imagine how any law authorising digital signatures can
>> >>> preserve that protection for bank customers and others who sign
>> >>> documents.
>> >>
>> >>But a cheque forgery has to be ascertained by experts who have to
>> >>use judgements and, I believe, don't always have 'absolute' certainty.
>> >>So I guess that some parallel mechanism could function.
>> >
>> >Not necessarily. There can be other ways of showing you didn't sign
>> >the document apart from an examination of the document. What matters
>> >is whether you signed it or not.
>> >
>> >The terms of electronic transactions mostly say that, if the bank
>> >gets a transaction that satisfies the conditions, it can pay. That
>> >is, the electronic details are final.
>> >[EMAIL PROTECTED]
>
------------------------------
From: "ben handley" <[EMAIL PROTECTED]>
Subject: Re: How Uncertain?
Date: Tue, 27 Jun 2000 12:29:17 +1200
> I don't understand it. ASCII is a seven bit code communicated in bytes.
> About a quarter of the text characters end with each of 00,
> 01, 10, and 11. The bias due to which letter is likely to follow
> which other letter is somewhat diminished by ignoring all of the byte
> except the last two bits. The question is not whether file A or file B
> is perfectly random. Here is the most important of the two questions I
> asked:
I think that english text has 1.3 bits of entropy per byte. So you
shouldn't ever try to squeeze more than many bits of `random' data from a
message.
ben
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: How Uncertain?
Date: Mon, 26 Jun 2000 18:51:06 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Future Beacon wrote:
>
> > I am writing also to inquire about this new (to me) use of the word
> > "entropy." Is it just a metaphor for uncertainty, or does it have
> > a precise quantitative definition in cryptography that is different
> > from older statistical terms?
>
> Schneier's AC has some explaination of entropy. I don't know exactly
> how the figure there about entropy in printed English (1.3 bits per byte
> of ASCII) was obtained. Menezes' HAC gives 1.5 bits. So something
> around that should be right in average cases.
>
> M. K. Shen
Around and about are good enough. I always say 1 to 3 bits per character.
It is not necessary to be more specific. After all, getting even one
significant figure, much less more, cannot address the needs of anyone but
a compulsive neurotic.
--
TJ was a great cat....prrr.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Date: Mon, 26 Jun 2000 18:57:32 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> zapzing wrote:
> > If you still disagree, I challenge you to
> > present a "compression" algorithm that will
> > compress *all* files without loss of
> > information.
>
> Actually, it's theoretically impossible, assuming the input alphabet is the
> same as the output alphabet. Otherwise, one could keep feeding the output
> back into the input until you reached a minimum size (1 byte or whatever).
>
Size alphabet and length of passage are related. Desirable compression to
remove redundancies must effect a reduction in their product, or gains
lnothing if it does not add to keyspace.
--
TJ was a great cat....prrr.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Surrendering Keys, I think not.
Date: Mon, 26 Jun 2000 19:07:51 -0600
In article <[EMAIL PROTECTED]>, Simon Johnson
<[EMAIL PROTECTED]> wrote:
>
> I think this is a good idea, because the legatimate owner of the
> encrypted file only has to enter their encryption key to decrypt
> the file. It take nearly no extra effort to make the false key,
> and doesn't affect normal use of the file atall.
>
The answer is to cry that keys must be escrowed in advance, since
surrendering what you choose to call a key means that you can make the
decryption into anything you want it to be. But, those who want things in
advance tend to be manipulators, liars, cheats, and all other classes of
waywardnesses, usually common amongst politicians in power, or seeking
such status.
--
TJ was a great cat....prrr.
------------------------------
Reply-To: "Phil" <[EMAIL PROTECTED]>
From: "Phil" <[EMAIL PROTECTED]>
Subject: unable to use HIGH ENCRYPTION on IIS 5.0 (1024 bit key)
Date: Tue, 27 Jun 2000 04:21:19 +0200
I'm unable to install a 1024 bit server-key on my win2000 server.
Trying to process the pending request in IIS 5.0 (IIS Certificate Wizard) I
always get the error msg:
The pending certificate request ... was not found.
It works perfectly with a 512 bit key, but 1024 doesn't work.
I've got a Win2000 Adv.Server, English Version (from the International MSDN
Subscription),
I've recently installed the High Encryption Pack (English Version) and have
even checked the schannel.dll to make sure it is the US & Canada Version.
Any help is very welcome !
Thanks in advance,
Phil
------------------------------
From: [EMAIL PROTECTED] (Steve)
Crossposted-To: alt.security.scramdisk,comp.security.pgp.discuss
Subject: Re: Idea or 3DES
Date: Tue, 27 Jun 2000 03:03:20 GMT
On Mon, 26 Jun 2000 15:43:08 -0700, Chem-R-Us
<[EMAIL PROTECTED]> wrote:
<...>
>DES has been much more extensively cryptanalyzed than IDEA. On that
>basis alone, it is the more conservative choice (e.g., speed not
>withstanding).
Another consideration: Slowness can be a good thing. Assuming
that some major organizaton throws a huge amount of processing
power into brute forcing a cipher key, the inherently slower
cipher will cost more to crack, for the same key size. There are
many reasons to prefer a faster cipher, but fundamental security
isn't one of them.
On t'other hand, we are talking about Scramdisk, and I have
noticed a real performance hit on any but the fastest systems
when using 3DES for OTF encryption.
Either way (IDEA or 3DES), it is still going to be cheaper to
steal the pass phrase via any of a half dozen avenues, than to
beat the cipher in a "fair fight" on a bank of supercomputers.
As far as we know...
:o)
---Support privacy and freedom of speech with---
http://www.eff.org/ http://www.epic.org/
http://www.cdt.org/
PGP keys:
RSA - 0x4912D5E5
DH/DSS - 0xBFCE18A9
Both expire 5/15/01
------------------------------
** 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
******************************
