Cryptography-Digest Digest #320, Volume #10 Mon, 27 Sep 99 21:13:03 EDT
Contents:
Re: SNAKE Web Page (Paul Onions)
hidden channel in Peekboo (Tom St Denis)
Re: All 15 chapters of Handbook of Applied Cryptography available for free download
(Kurt Wismer)
Web IP-based restrictions for Crypto export? (jcb)
Re: Please review proposed rebuttal... ("karl malbrain")
Re: Electronic envelopes (Mok-Kong Shen)
Re: Securing Executables (Tom St Denis)
Re: Schrodinger's Cat and *really* good compression ("Tony T. Warnock")
Please review proposed rebuttal... ("me")
Re: Please review proposed rebuttal... (Anton Stiglic)
Re: Meeting BXA req. for online dist? (wtshaw)
Archive (sha99y00000)
Re: SNAKE Web Page (Peter Gunn)
Re: Increasing password security dramatically without making it harder to
remember ("Gary")
Re: Please review proposed rebuttal... (JPeschel)
Re: Schrodinger's Cat and *really* good compression (John Savard)
Re: Electronic envelopes (Art Dardia)
Re: Electronic envelopes ("Richard Parker")
Re: Proving cipher strength ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: SNAKE Web Page
Date: Mon, 27 Sep 1999 20:25:04 +0000
Peter Gunn wrote:
>
> Im wondering if this can be fixed by simply not allowing { 0,1,g }
> for g^Y1 mod f(1,P,R) ??
Looks like it to me. But disallow those values for both A and B.
> Perhaps not allow any values J such that g^J < Z ??
> (Z being the minimum f(1,P,R))
I'd just go for something simple like:-
1 < w < p, w != g
where w is the value that either A or B receives in the field
reserved for g^X1 mod f(1,P,R), g^Y1 mod f(1,P,R), etc, and p
is the relevant prime modulus.
>
[...]
>
> Here, Im thinking that perhaps if I used...
>
> K=H(U,R,P,
> (g^Y1)^X1 mod f(1,P,R),(g^Y2)^X2 mod f(2,P,R),...,
> g^X1 mod f(1,P,R),g^X2 mod f(2,P,R),...,
> g^Y1 mod f(1,P,R),g^Y2 mod f(2,P,R),...)
>
> (basically throw in the public values for A and B which we have anyway)
>
> ...then that might be effective in stopping tampering with the values
> supplied??
Yes, that looks good. So tampering will at least mean they don't authenticate.
So now it's a question of either:-
i) what can be done by an adversary who doesn't tamper with other people's
messages, or
ii) what information can be gained by an adversary that does tamper with
their messages but who never sees a successful authentication as a
result of his tamperings.
where (i) seems to imply either a passive adversary or one who tries to
impersonate either A or B, and (ii) seems limited to what info can be
obtained from E[K](S) sent by A before B presumably aborts (without sending
E[K](R)).
Of course I could also be missing some scenarios here.
Still, plenty to look at then :-)
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: hidden channel in Peekboo
Date: Mon, 27 Sep 1999 20:29:17 GMT
Hehehe playing with the source today, I noticed there is a hidden channel in
the SALT calculation that can be used to send 64-bits of info to the
receiving end. I don't know what you would do with it but it's there.
Basically the salts are done like this
SALT1 = h1 xor h2 xor h3 xor time()
SALT2 = h4 xor h5 xor GetTickCount()
Where time() is the num of seconds since 1970 ... and GetTickCount() is the
number of ticks (msecs) since bootup. These counters are there to ensure
each message has a good prob of a having a unique salt. h1 to h5 are the
SHA-1 output of the message (hash)
However you could replace them and put 64-bits of info only the person with
the session key could decrypt.
Any ideas of what this could be used for?
Tom
Peekboo binaries and source are available from
http://www.cell2000.net/security/peekboo/index.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kurt Wismer)
Subject: Re: All 15 chapters of Handbook of Applied Cryptography available for free
download
Date: Mon, 27 Sep 1999 20:49:07 GMT
dlk ([EMAIL PROTECTED]) wrote:
: A (belated) thank you as well. I have the book, but an electronic version
: is very handy for us "road wariors" - dragging one's tech library around
: gets rather old quickly. Not to mention that expensive books seem to have
: the ablility to grow legs and walk off. I wish more authors/publishers
: would do this.
i'll second the sentiment about more authors/publishers doing this... and
for those who feel it might negatively affect their sales, how about a
voucher included with the printed book entitling one to the electronic
version...
--
Making sure everyone gets Internet access whether they can afford it or not.
The Toronto Free-Net needs your support to help pay for continued operation.
Donors (personal or corporate) of $25+ can receive charitable tax receipts.
Please see http://www.torfree.net for office contact details.
------------------------------
From: [EMAIL PROTECTED] (jcb)
Subject: Web IP-based restrictions for Crypto export?
Date: Mon, 27 Sep 1999 13:52:14 -0700
I'm looking for appropriate information and/or algorithm to determine,
based on *IP address* of an HTTP request, whether that request is coming
from a country to which export of strong encryption is required.
I'm helping implement a perlscript for a web site that will distribute
software that must be restricted due to encryption, but I cannot find this
information...
Any pointers???
-JCB
P.S. Please email [EMAIL PROTECTED] as well as post, since my
news feed isn't entirely reliable. Thanks for any tips...
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Please review proposed rebuttal...
Date: Mon, 27 Sep 1999 15:11:19 -0700
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
(...)
> A team of researchers, numbering in the hundreds, combined with over 300
> awesome
Can the superlatives, e.g. awesome.....
> computers working over a seven-month period demonstrated that using
> their combined resources the capability
No, capability is not the correct word for something that's already
occurred. You MUST state that the TEAM accomplished what they set out for
in SPECIFIC. Demonstrated??? No, they broke ONE instance of an RSA key.
It's a complete PROOF as far as we're concerned.
> exists to "crack" the 512-bit RSA
> key. This 512-bit key is currently used largely by E-Commerce sites that
> want to be able to do business internationally. Most of the U.S. based
> financial institutions have already made the upgrade to the 1024-bit RSA
> key.
(... to the bit bucket). Karl M
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Mon, 27 Sep 1999 21:20:49 +0200
DJohn37050 wrote:
>
> There is a crypto time capsule, as follows: Create an ECC public key of a
> certain size without ANYONE knowing the private key, then use the public key to
> encrypt the message. To recover the data means breaking the public key to
> recover the private key, which is known to take an expected number of
> operations. This is not super fine tuned as to time.
With new processors steadily appearing, there is in my opinion
barely any reliable timing possible with that. A reasonably conceivable
application could require, for example, the disclosure of the secrect
at 00:00:00 of 2020.
M. K. Shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Securing Executables
Date: Mon, 27 Sep 1999 21:18:28 GMT
In article <7sn15q$oon$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (xwang) wrote:
> Has anyone looked at the technolgy of Self-Protecting Documents at
> www.contentguard.com
>
> Any comments?
Do you mean like auto-file encrypt?
Try getting PGPDisk or ScramDisk or something. If you want secure
executables you have to ensure that all of the memory and swapfile is cleared
after the program exits. Otherwise traces will be found. Also you have to
ensure the integrity of the file which may be the limiting factor.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Schrodinger's Cat and *really* good compression
Date: Mon, 27 Sep 1999 15:33:02 -0600
Reply-To: [EMAIL PROTECTED]
John Savard wrote:
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>
> >The issue
> >is not whether the experiment could be performed; it could.
>
> Actually, however, the box has to be *very* well-insulated in order
> for the cat not to be inadvertently observed. Maintaining the
> coherence of such superposed states is extremely difficult.
>
> In fact, since a cat is big enough to have a detectable gravitational
> pull, and no insulator for gravity is known - after all, it bends the
> fabric of space itself - and so there may be a *fundamental*
> impssibility involved; at least this is what Roger Penrose has
> suggested.
>
> John Savard ( teneerf<- )
> http://www.ecn.ab.ca/~jsavard/crypto.htm
If we place the cat in an adiabatic box, the gravitational field should
be the same for a dead, or live cat. (Or even half-dead.)
Tony
------------------------------
From: "me" <[EMAIL PROTECTED]>
Subject: Please review proposed rebuttal...
Date: Mon, 27 Sep 1999 16:28:55 -0500
To all,
Please review the following article for technical correctness. It is at
best, my amateur compilation of inputs I received over the past few weeks
from many different security related newsgroups. Hopefully, this will calm
the storm generated by the clueless reporting of the "512-bit RSA key
cracked" event. Keep in mind the audience for this article is the general
public and those reporters that have "reported" on this event.
Please let me know your comments/opinions.
Thanks in advance,
A Webmaster with half a clue.
Here's my proposed article:
A team of researchers, numbering in the hundreds, combined with over 300
awesome computers working over a seven-month period demonstrated that using
their combined resources the capability exists to "crack" the 512-bit RSA
key. This 512-bit key is currently used largely by E-Commerce sites that
want to be able to do business internationally. Most of the U.S. based
financial institutions have already made the upgrade to the 1024-bit RSA
key.
The actual 512-bit RSA key was not cracked. A 155-digit number that is the
same length as the number for the 512-bit key was factored to its prime
numbers. So the "actual" key was not factored or cracked, but a number
similar to it was. The researchers demonstrated to the World that the key
could be cracked, not that it was cracked. To actually crack the key,
someone will have to duplicate the efforts of the researchers on the actual
key. Most of the folks involved in this endeavor would not participate in an
actual attack on a key.
This 512 or 1024-bit RSA key is only one level of protection given to
transactions on the Internet. Almost all public transactional Web sites use
SSL (Secured Sockets Layer) to encrypt the data. In SSL, once the data is
encrypted using the 512 or 1024-bit RSA key, it is encrypted again with
ANOTHER key that's generated by the browser. This other key is different
every time you initiate an SSL session. For those browsers using 128-bit
Strong U.S. encryption, a Cray super computer can crack it in 2 days. The
average group of folks would have to get together 30 or so computers,
running in parallel, teamed up with about 5 people at least 2 weeks of 24
hour a day operation to "crack" this second key.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Please review proposed rebuttal...
Date: Mon, 27 Sep 1999 17:38:07 -0400
When we say 512-bit RSA, we talk about a *set* of keys, of
size 512 bits, not one particular key. You seem to refer to
512-bit RSA as *one* RSA key. The number that was factored,
was a number that belongs to the *set* 512-bit RSA. The algorithm
used is a general algo., meening that given another 512-bit RSA
key, they could probably factor it using about the same amount of
computers, taking about the same time.
Anton
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Meeting BXA req. for online dist?
Date: Mon, 27 Sep 1999 16:17:25 -0600
In article <7sohnd$[EMAIL PROTECTED]>, Richard Hyde
<[EMAIL PROTECTED]> wrote:
> Is there a website somewhere that describes tips and techniques one
> can use to meet BXA's requirements for distributing >56 bit software
> on line?
>
> The BXA docs are deliberately obscure and an exhaustive search has
> so far failed to turn up anything concrete.
>
The rocks are in the heads of those that think it is a good idea.
--
Note the latest ad from Apple reflecting the government's
philosophy that good computers should not be exported. It is
interests of our government that foreign computers be vulnerable.
------------------------------
Date: Mon, 27 Sep 1999 22:42:24 +0100
From: sha99y00000 <[EMAIL PROTECTED]>
Subject: Archive
Before I tackle another subject, I would like to know if previous
postings are stored in an archive where I can view them. I don't want to
unnecessarily go other over old ground with questions that have already
been answered.
sha99y
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: SNAKE Web Page
Date: Mon, 27 Sep 1999 23:37:48 +0100
Paul Onions wrote:
> Peter Gunn wrote:
> >
> > Im wondering if this can be fixed by simply not allowing { 0,1,g }
> > for g^Y1 mod f(1,P,R) ??
>
> Looks like it to me. But disallow those values for both A and B.
>
> > Perhaps not allow any values J such that g^J < Z ??
> > (Z being the minimum f(1,P,R))
>
> I'd just go for something simple like:-
>
> 1 < w < p, w != g
I think I'll stick to...
J < w < p
since J is easily calculated (or estimated for g==3 or g==4) and should
hopefully make it more difficult to find other special values for w.
I will have to explicitly state that w !=g though for people who want to
use large modulous values (which might be bigger than J).
I also forgot to put code in RATTLER to check the values it receives for
w... I'll patch that up at the weekend :-)
>
> where w is the value that either A or B receives in the field
> reserved for g^X1 mod f(1,P,R), g^Y1 mod f(1,P,R), etc, and p
> is the relevant prime modulus.
>
> >
> [...]
> >
> > Here, Im thinking that perhaps if I used...
> >
> > K=H(U,R,P,
> > (g^Y1)^X1 mod f(1,P,R),(g^Y2)^X2 mod f(2,P,R),...,
> > g^X1 mod f(1,P,R),g^X2 mod f(2,P,R),...,
> > g^Y1 mod f(1,P,R),g^Y2 mod f(2,P,R),...)
> >
> > (basically throw in the public values for A and B which we have anyway)
> >
> > ...then that might be effective in stopping tampering with the values
> > supplied??
>
> Yes, that looks good. So tampering will at least mean they don't authenticate.
>
> So now it's a question of either:-
> i) what can be done by an adversary who doesn't tamper with other people's
> messages, or
> ii) what information can be gained by an adversary that does tamper with
> their messages but who never sees a successful authentication as a
> result of his tamperings.
>
> where (i) seems to imply either a passive adversary or one who tries to
> impersonate either A or B, and (ii) seems limited to what info can be
> obtained from E[K](S) sent by A before B presumably aborts (without sending
> E[K](R)).
>
> Of course I could also be missing some scenarios here.
Thats why is always best to get input from wherever you can :-)
> Still, plenty to look at then :-)
Yep, but it still looks promising!
Regards,
PG.
------------------------------
From: "Gary" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp
Subject: Re: Increasing password security dramatically without making it harder to
remember
Date: Mon, 27 Sep 1999 22:49:08 +0100
Sorry didn't read the keystretching.ps, but for the salt that is exactly
what you do.
Gary wrote in message <2ROH3.4027$gE.105381@stones>...
>A weak key is hashed and then that hash hashed and so on and so on.
>On the average machine say it took 10 seconds and then the result was used
>as the password.
>Is this analogous to key stretching?
>
>
>
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Please review proposed rebuttal...
Date: 27 Sep 1999 22:54:26 GMT
[EMAIL PROTECTED] writes:
>In SSL, once the data is
>encrypted using the 512 or 1024-bit RSA key, it is encrypted again with
>ANOTHER key that's generated by the browser. This other key is different
>every time you initiate an SSL session. For those browsers using 128-bit
>Strong U.S. encryption, a Cray super computer can crack it in 2 days. The
>average group of folks would have to get together 30 or so computers,
>running in parallel, teamed up with about 5 people at least 2 weeks of 24
>hour a day operation to "crack" this second key.
No, a Cray supercomputer cannot crack "this other key" of 128-bits
in two days. RSA is an asymmetric cipher, while the 128-bit cipher
is symmetric. The mathematics of breaking each of these ciphers
is different. RSA's strength is due to the factoring problem. But
the 128-bit symmetric cipher used in SSL can only be cracked
by a brute-force search of the key space: 2^127 keys (unless some
of the keyspace is known). By the time the key is found, however, no one,
if anyone is still alive, will care.
Schneier estimates that a 128-bit symmetric key is about as
resistant to attack as a 2304-bit public key.
Joe
(A journalist)
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Schrodinger's Cat and *really* good compression
Date: Mon, 27 Sep 1999 22:48:13 GMT
"Tony T. Warnock" <[EMAIL PROTECTED]> wrote, in part:
>If we place the cat in an adiabatic box, the gravitational field should
>be the same for a dead, or live cat. (Or even half-dead.)
Admittedly, the cat would soon die from suffocation or hyperthermia
even in the absence of the cyanide release triggered by radioactive
decay;
but if the box is large enough for the cat to move around, and keel
over, the gravitational field is indeed different depending on the
location of the cat.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Art Dardia <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Mon, 27 Sep 1999 20:24:06 -0400
You have to assume that if you're using crytography to encrypt the
envelope until the year 2020, as given in your example. By the year
2010, processors should be powerful enough to crack that a lot quicker
than you'd want them to. You'd need to use a disgustingly large key
size.
Art Dardia
PS - I'm a newbie. My posts may mean nothing.
Mok-Kong Shen wrote:
> Anton Stiglic wrote:
> >
> > Assuming Alice deposits the enveloppe to Bob. The scheme
> > you described is possible if Bob can communicate with Alice
> > at the moment Bob is to open the enveloppe. When the content
> > in the enveloppe is a bit, this is called a bit commitement scheme.
>
> I wrote in my post that after deposition the sender is assumed to
> be no longer available.
>
> M. K. Shen
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Electronic envelopes
Date: Tue, 28 Sep 1999 00:41:18 GMT
I think the following method could be used by Alice to deposit an
envelope containing a secret message with a notary such that the
message can't be extracted by the notary until after a time that Alice
specifies.
Assume the existence of trusted clock. The trusted clock generates a
set of public-key/private-key key pairs. The clock publishes the
public keys along with a time at which the corresponding private key
will be announced for each public key. The clock guarantees that it
will only release a private key at that time.
N, N' Notary's public key and private key
T Time the envelope should be opened
U, U' Trusted clock's public key and private key for the time
A A random key generated by Alice
M Alice's secret message
The method would work as follows:
1) Alice encrypts a random key with the clock's public key U for the
time she wants the envelope to be opened. She concatenates this
with the time T that the envelope should be opened and then
encrypts them with the notary's public key N. She sends this to
the notary, along with the secret M encrypted by the random key.
E_N(T, E_U(A)), E_A(M)
2) The notary decrypts the first part of the envelope using his
private key N' and then waits until the time indicated by T.
3) The trusted clock announces the private key U' that corresponds
with the time Alice wants the envelope opened.
4) The notary uses the trusted clock's private key to decrypt Alice's
encrypted random key and then uses Alice's key to decrypt Alice's
secret message.
5) The notary announces Alice's secret message.
An opponent who can compromise the notary can learn the time the
secret will be announced, but is unable to read the secret early
because to do so requires the clock's private key that corresponds to
that time. An opponent who can compromise the clock is unable to read
the secret before time T because the opponent also needs the notary's
private key to read the secret. In order for the opponent to read the
secret before time T the opponent has to either compromise Alice or
compromise both the notary and the clock.
However, note that in the above method there is nothing that prevents
the notary from stopping at step 4. While this method prevents the
notary from opening the envelope before the time specified by Alice,
it does not provide any assurance that the notary will actually open
the envelope.
-Richard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Proving cipher strength
Date: Tue, 28 Sep 1999 00:37:29 GMT
Toby Kelsey wrote:
> I wonder if the usual assumption that cipher strength can only be
> disproven, and not proven, is actually valid.
It's not so much an assumption as an observation on
the state of the art.
> Suppose we try a
> mathematical approach:
>
> (a) Choose a model for computation (e.g. a Turing machine) with
> weights for each operation representing time/effort.
>
> (b) Select our trial cipher, which can take variable-length keys.
>
> (c) Show, using an exhaustive search of possible faster programs,
> that for a trivial key-length (e.g. 8 bits), brute-force search of
> the key-space is the most efficient method of breaking the cipher.
That may be practical for very small sizes.
> (d) Prove by induction that brute-force is the most efficient method
> for all key lengths (for specified message lengths).
This step is probably the biggest current stumbling
block. If the cipher is to be useful, encryption and
decryption using the key must be tractable. In a post
from 2 Nov 98, available as
http://x42.deja.com/getdoc.xp?AN=407897337&CONTEXT=938477175.12452024&hi
tnum=1
I argued that such a cipher (variable length key,
poly-time encrypt/decrypt, exponential time break)
requires that P != NP.
> The details of the critical step (d) will depend on the structure of
> the cipher, and it may be possible to design one which makes proving
> this easier (which, say, operates sequentially on the key bits).
I think that's a good observation - that you can
design the cipher for the proof. But one could
also show that P != NP by designing a single
language with a short-certifier that cannot be
decided in poly-time. Alas, it has so far turned
out to be harder than it looks.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
