Cryptography-Digest Digest #219, Volume #11      Tue, 29 Feb 00 12:13:01 EST

Contents:
  Re: code still unbroken (John Myre)
  Re: Are "self-shredding" files possible? (Phil Wakely)
  Re: Best language for encryption?? (Paul Schlyter)
  brute force attack on a 128 bit SSL key? (Domenico Signorello)
  Re: NSA now has a FAQ (Nuno Jaime Cardoso)
  Re: Ciphering = deciphering; is this a weakness? (John Myre)
  Re: Can someone break this cipher? (Runu Knips)
  Re: brute force attack on a 128 bit SSL key? (Michael Sierchio)
  OpenSSL and Netscape (Nigel Smart)
  Re: nonces - a definition (Doug Stell)
  Re: Can someone break this cipher? (John)
  Re: Can someone break this cipher? (John)
  Re: brute force attack on a 128 bit SSL key? ("John E. Kuslich")

----------------------------------------------------------------------------

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: code still unbroken
Date: Tue, 29 Feb 2000 08:07:58 -0700

"Douglas A. Gwyn" wrote:
> 
> There is an interesting area of game theory here.  Suppose that N
> people have all cracked the cipher and are waiting for the prize
> to increase, to maximize their expected payoff.  Obviously, the
> first to submit his claim takes the prize, but if he does it too
> soon he doesn't get as much as if he waited until just before the
> second person submits his claim.  What is the optimal waiting
> time before filing one's claim?  (A simple-minded solution says
> that it is infinite.)

The problem, as stated, has no time units.  If there is in fact a
unique answer, it would have to be either zero or infinite.

If we make the increases discrete, we get a natural time unit of
one per increase.  That is, we could find an optimum expectation
after waiting T steps.  Of course, now we must take account of
ties - perhaps K contestants submit their answer at the "same"
time.

Naively (without doing any math), it looks like waiting is a bad
idea.  If you submit right away, you are guaranteed a payoff.
What if there were a cost for entering?  Then what?

Another way of introducing a time unit would be to have the
prize increase non-linearly (e.g., prize = sqrt(time)).  For what
formulas does the problem have a unique (non-trivial) solution?

John M.

------------------------------

From: Phil Wakely <[EMAIL PROTECTED]>
Crossposted-To: 
alt.security.pgp,alt.security.scramdisk,comp.security.misc,comp.security.pgp.discuss
Subject: Re: Are "self-shredding" files possible?
Date: Tue, 29 Feb 2000 15:21:19 +0000
Reply-To: [EMAIL PROTECTED]



Thomas Moore wrote:
> 
> Does anyone know if it's possible to make a file "self-shredding?" I'm
> thinking of something along the lines of PGP's self-decrypting file type.
> I'm a regular on the groups that this question is posted to and have never
> read about this topic.
> 
> I imagine being able to add or tag the "self-shredder" to a file, then
> letting the user (this could be password protected or not) shred it after
> any number of uses, or maybe after just one use. Files could also self-shred
> after a certain time period - run them after such and such date and they
> would just shred.
> 
> Maybe this idea just isn't possible. I'm not a programmer so I really don't
> know. Please reply if you have any feedback.

The largest difficulty that I could see that you would need to overcome
is that of duplication if you wish the file to operate on a standalone
basis; i.e. you could keep cloning the original since this is only a
collection of bits, and then keep decoding the clones and copying the
original as required.

Other schemes could be envisaged which required third party keys for
decryption which would only be supplied in single instances, which
provided the data was only displayed within a secure application
(whatever than means) could allow a specific maximum number of
decryptions; however the varieties I can think of would all rely on a
third party (and all the inherent risks etc), and be vulnerable to other
forms of attack.

Phil.

------------------------------

From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Best language for encryption??
Date: 29 Feb 2000 14:43:19 +0100

In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
 
> wtshaw wrote:
>> It all depends on your purpose.  C appears useful, but tends to be
>> more cryptic than BASIC, which is a higher level language than C.
>> C and C++ are powerful, but for demonstration purposes BASIC is much
>> more apparent in source, and tends not to rely on brand x classes or
>> header files as training wheels to get the most out of it, as it
>> already works at a sopistocated level.
> 
> French is "cryptic" to those who don't understand French.
> Arabic is "cryptic" to those who don't understand Arabic.
> Chinese is "cryptic" to those who don't understand Chinese.
> etc.
> 
> You have really mischaracterized those programming languages,
> apparently from lack of familiarity with all of them except
> (perhaps) BASIC.
> 
> The vast majority of crypto programming is currently done in C,
> C++, or Java.  However, it *can* be achieved in any language
> that is not too crippled.  Choosing a programming language is
> an issue that has many relevant factors to be considered, none
> of which did you address.  (Nor shall I, as that thread would
> have little relevance to sci.crypt.)  If you know BASIC, feel
> free to use it, but even if you manage to overcome all the
> obstacles it puts in the way of implementing RSA (hint: you
> need a bignum library), the result will be much slower than
> if you had chosen any of several other possible languages.
 
Not only the language matters -- the implementation also matters, in
particular for such an inherently non-standard language as BASIC.
Yes, there is an ANSI BASIC, but hardly anyone implements it -- every
BASIC implementor implements something else.  In BASIC in particular,
one could choose to use UBASIC (a BASIC implementation with bignum's
built-in right into the language).  UBASIC is great for quick'n'dirty
programming involvong bignum's.  Which means even if you implement
something in a more decent language, UBASIC can still be useful for
checking your numerical results.
 
-- 
================================================================
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch

------------------------------

Date: Tue, 29 Feb 2000 16:37:17 +0100
From: Domenico Signorello <[EMAIL PROTECTED]>
Subject: brute force attack on a 128 bit SSL key?

I have searched the Web for the answer for my question:

How much time will a (local/distributed) computer system need to crack a

128-bit-SSL-encrypted data sequence?

some boulevard computer press has announced in capitals that it would
need a trillion of a trillion years...  but nowhere it is explained how
this result is generated...

my idea is:

t = op / (MOPS)

op: total # of operations performed to generate a 128 bit key and use it
for a crack attempt on a encrypted data sequence

MOPS: Millions Of Ops Per Second

but what is an approx. value of op and MOPS (e.g. a Pentium 700) ? I
have no idea.

Thanks for giving me an answer or picking up my idea and bringing it
further...



--
Domenico Cosimo Signorello <mailto:[EMAIL PROTECTED]>
Industrial Management and Manufacturing
Swiss Federal Institute of Technology, Zurich



------------------------------

From: Nuno Jaime Cardoso <[EMAIL PROTECTED]>
Subject: Re: NSA now has a FAQ
Date: Tue, 29 Feb 2000 15:43:03 +0000

You liked it??

I Loved it. I am Portuguese so, NSA doesn't have that big efect on me but, I
realy loved this question:

"Lately, I've seen NSA/CSS a lot in movies and on TV. Do you
assassinate people? Do you secretly perform experiments on us?

                   Because we work with highly sensitive information, we are
frequently the
                   subject of speculation - and highly imaginative and creative
fictitious
                   pieces in the media. However, it is important to distinguish
fiction from fact.
                   The fact is that the Executive Order 12333 (EO 12333) strictly
prohibits any
                   intelligence agency from conducting these unethical
activities, and we
                   strictly abide by the Order. "


I don't know mutch about US recent History but, that makes me want to say:

"I am not a murderer, I am not a murderer" :)))))

//Jaime Cardoso


Volker Hetzer wrote:

> "Douglas A. Gwyn" wrote:
> >
> > http://www.nsa.gov:8080/about_nsa/faqs_internet.html
> I liked it. Especially the part about "declassifying" paper, films
> and printed circuit boards. :-)
>
> Greetings!
> Volker
> --
> Hi! I'm a signature virus! Copy me into your signature file to help me spread!


------------------------------

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Ciphering = deciphering; is this a weakness?
Date: Tue, 29 Feb 2000 08:56:00 -0700

Manuel Pancorbo wrote:
> 
> I'm designing a block cipher algorithm and I have the option make it in such a way 
>that the enciphering process is the same as deciphering. I mean:
> 
>                 E(E(m;k) ;k) = m
> 
> where E(m;k) is the enciphering algorithm of the plaintext 'm' with key 'k'.
> 
> Could this property could be trivially exploited to crack the cipher?
> 

This behavior is common in stream ciphers (e.g. RC4) but it isn't a good
idea for a block cipher.  Depending on how the cipher is used, it can be
a weakness.  Consider, for example, if someone tried to use such an
algorithm in OFB mode!  I think you'd have to restrict how the cipher
was used to such an extent that you would not be pleased.

John M.

P.S.
Note that on the other hand, there is no reason why enciphering and
deciphering can't use the same steps, as long as the key schedule is
different.  That is what DES does, or any Feistal cipher.

------------------------------

Date: Tue, 29 Feb 2000 17:03:14 +0100
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Can someone break this cipher?

"Douglas A. Gwyn" schrieb:
> 
> Runu Knips wrote:
> > The attacker _ALWAYS_ knows your system.
> 
> No, he doesn't, but you don't want the cryptosystem's security
> to *require* that the system remain unknown to the attacker.
> It is simply too difficult to guarantee that in practice,
> and if something goes wrong, you are put in a real bind.

Thats what I meant. If you design a crypto system,
you always assume the attacker knows it. Everything
else doesn't work for long...

------------------------------

From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Tue, 29 Feb 2000 08:13:57 -0800


Applied Cryptography, EFF and AWT produced,  for the cost of $250,000, a
DES cracking machine which checks 90 G keys/s.  Since the brute force
search of the keyspace can be distributed,  it's reasonable to talk
about keys searched per dollar per second (or hour, or year).  

Assume the following:

        Such a machine could be built for RC4, Blowfish, etc.

        the machine would cost $10,000

        the machine could check 1 T k/s (1 Million Million keys per second)

Then we can search approx. 3.16 x 10^15 keys/$-year

If a brute force key search will find the key on average after searching
half the key space (2^127),  then note that

        2^127 keys / 3.16 E 15 keys/$-y == 5.39 E22 $-y

In other words, if these machines were plentiful, and you could spend
the estimated total currency supply of the US (ca. $600,000,000,000),
it would take roughly 9 E 10 years,  or about 15 times the life of
the universe.

NOTE: I have ignore the effect of Moore's Law -- which is not a continuous
but a discrete function -- which if it were to hold would imply a doubling
of keys / $-y every 1.5 years.  I'll work on those calculations and get
back to you... ;-)

------------------------------

From: Nigel Smart <[EMAIL PROTECTED]>
Subject: OpenSSL and Netscape
Date: Tue, 29 Feb 2000 16:09:56 GMT

Hi,

 There must be someone on the Net who knows how to do this, or 
could perhaps explain what I am doing wrong. I have compiled
OpenSSL and was playing around with the demoCA stuff. And I
want to use the generated certs within Netscape. The reason
for doing this is I am looking at a possible demo for some
students for a course which I want to cover simple PKI with.

 As a recap, just in case I missed something in the manuals...

I create a CA using...
        CA.pl -newca
I create a request for a new cert with...
        CA.pl -newreq
I create a signed certificate with
        CA.pl -sign
I must now get this into a format to use with Netscape so I
need to convert it to a PKCS-12 format...
        cat newreq.pem newcert.pem > t.pem
        openssl pkcs12 -export -in t.pem -out f.p12 -name "My Cert"

Now I load this Cert into Netscape via  
        Communictor->Tools->Security Info->Yours->Import a Certificate

This all works fine, except Netscape ofcourse does not recognize my
"root CA". Hence when I come to send a signed email it complains and
will not send the email. 

 In fact there seems no way of installing a new root CA into Netscape.
Now I can think of a number of reasons why people may not think this 
a good idea, but its a bit of a pain if you want to show the students 
how Netscape uses certs etc to sign/encrypt mail.  Does anyone know a 
way around this ? (Which of course does not entail buying some
commercial product etc etc).

NB The course will be given to a mixture of people with different
backgrounds so the simpler the way of setting up a CA the better.

Cheers

Nigel
-- 
Nigel Smart,
Department of Computer Science, University of Bristol,
Merchant Venturers Building, Woodland Road,
Bristol, BS8 1UB, United Kingdom.

------------------------------

From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: nonces - a definition
Date: Tue, 29 Feb 2000 16:19:31 GMT

On 29 Feb 2000 09:35:07 +1100, Anthony David <[EMAIL PROTECTED]>
wrote:

>Greetings
>
>While explaining to management how our IPSec parameters are
>setup, I came across the term "nonces".
>
>After consulting the online Webster's 1913 and my Shorter Oxford
>at home, the term is a Middle English word describing some thing
>that exists for the moment or "for the once".
>
>"Applied Cryptography" makes a number of references to the word
>but I never found a definition it.
>
>Is a nonce in cryptographic parlance simply a truly random
>number generated for the purpose of (public) key exchange?

The HAC contains the definition of a nonce, at the bottom of page 397.
"A nonce is a value used no more than once for the same purpose. It
typically serves to prevent (undetectable) replay."


------------------------------

Subject: Re: Can someone break this cipher?
From: John <[EMAIL PROTECTED]>
Date: Tue, 29 Feb 2000 08:46:27 -0800

In article <[EMAIL PROTECTED]>, "A
[Temporary] Dog" <[EMAIL PROTECTED]> wrote:
>On Sun, 27 Feb 2000 16:16:05 GMT, [EMAIL PROTECTED]
(Mary -
>Jayne) wrote:
>
>>Could anyone willing to do so please solve the challenge at
>>
>>http://www.xarabungha.btinternet.co.uk/xicipher/xichallenge.htm
>
>The above link is 404 compliant.  Did you mean -
>http://www.xarabungha.btinternet.co.uk/xicrypt/xichallenge.htm
>
>>I designed the algorithm and if it can be readily broken, then
it is useless.
>
>The challenge at xicrypt/xichallenge.htm doesn't give any
details of
>the algorithm, just a bunch of raw ciphertext.  In
general, "can you
>break this cipher" posts are a bad idea.  In particular, even
with a
>complete description, you'll have a hard time getting
knowledgable
>people to analysis your cipher.  Without a description, no one
will
>bother.
>

That seems like a paradox. If nobody will bother without doing
it "the right way," could their not be some good "stuff" out
there that nobody knows about. If you want security, isn't it
better if nobody knows how it works? I know that there is no
link between the two ideas of releasing the details, but let's
assume someone was able to verify a good encoder. If they did
the right tests, etc. If they were sure of the security, and
they really wanted security, what would be the advantage
of "leaking" the details?  Wouldn't that be what the "enemy"
wanted?

>>Your destructive assistance would be appreciated.
>
>
>--
>- A (Temporary) Dog             |"Intelligent, reasonable
>The Domain is *erols dot com*   |people understand that -
>The Name is tempdog             |unfortunately, we're dealing
>http://users.erols.com/tempdog/ |with elected officials"
>Put together as name@domain     | - name withheld
>
>



* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


------------------------------

Subject: Re: Can someone break this cipher?
From: John <[EMAIL PROTECTED]>
Date: Tue, 29 Feb 2000 08:52:09 -0800

It's also easier when you have knowledge of the system. It takes
a "little" out of the brute-force attack.  If the text is truly
random, brute force is the only way to go without any other
knowledge.

In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
>Adam Durana wrote:
>> So if you are serrious about testing
>> the the security of your cipher you'll have to make it public.
>
>The official party line on this is:  If a cryptosystem becomes
>crackable without knowing the key once its "general system" is
>known, it is unsafe to field the system, because there are too
>many ways in which the general system (or an equivalent) might
>be discovered, be it deduction, lucky guessing, or copying of
>an operator's manual.  (All of these have occurred many times
>in the course of history.)  Since there are cryptosystems
>already available with security that can withstand disclosure
>of the general system, there is no real competition from a
>new cryptosystem that lacks this property.  In order to
>demonstrate this property, one discloses the general system to
>the cryptanalysts who one uses to probe it for weaknesses
>before fielding the system; since those cryppies are working
>on the same side, they should be provided as much assistance
>as possible short of giving them the key.  Otherwise you make
>them work too hard on inessential aspects of the problem,
>which reduces the likelihood that they will find the real
>weaknesses.
>
>



* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


------------------------------

From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: brute force attack on a 128 bit SSL key?
Date: Tue, 29 Feb 2000 10:01:01 -0700

The correct answer is about twenty seconds.

This is the amount of time it would take to install  a trojan on the target
machine which would create a back door for the plain text recovery.

Never take them head - on.  :--)

JK  http://www.crak.com  Password Recovery Software for QuickBooks and more



Michael Sierchio <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Applied Cryptography, EFF and AWT produced,  for the cost of $250,000, a
> DES cracking machine which checks 90 G keys/s.  Since the brute force
> search of the keyspace can be distributed,  it's reasonable to talk
> about keys searched per dollar per second (or hour, or year).
>
> Assume the following:
>
> Such a machine could be built for RC4, Blowfish, etc.
>
> the machine would cost $10,000
>
> the machine could check 1 T k/s (1 Million Million keys per second)
>
> Then we can search approx. 3.16 x 10^15 keys/$-year
>
> If a brute force key search will find the key on average after searching
> half the key space (2^127),  then note that
>
> 2^127 keys / 3.16 E 15 keys/$-y == 5.39 E22 $-y
>
> In other words, if these machines were plentiful, and you could spend
> the estimated total currency supply of the US (ca. $600,000,000,000),
> it would take roughly 9 E 10 years,  or about 15 times the life of
> the universe.
>
> NOTE: I have ignore the effect of Moore's Law -- which is not a continuous
> but a discrete function -- which if it were to hold would imply a doubling
> of keys / $-y every 1.5 years.  I'll work on those calculations and get
> back to you... ;-)


------------------------------


** 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
******************************

Reply via email to