Cryptography-Digest Digest #590, Volume #9       Tue, 25 May 99 00:13:03 EDT

Contents:
  Re: blowfish hints anyone? ([EMAIL PROTECTED])
  Re: ScramDisk and Windows 2000 (Aidan Skinner)
  Re: Reasons for controlling encryption (Martin Grap)
  Re: Reasons for controlling encryption ("Markku J. Saarelainen")
  Re: AES tweaks ("Markku J. Saarelainen")
  Re: AES tweaks (David A Molnar)
  Re: SHA-1 unpatented? (Paul Rubin)
  Re: HushMail -- Free Secure Email (John Kennedy)
  Re: Reasons for controlling encryption (SCOTT19U.ZIP_GUY)
  Re: Why would a hacker reveal that he has broken a code? (Boris Kazak)
  Re: DSA (Digital Signature Standard) and the Schnorr Patents ("rosi")
  Re: AES tweaks (SCOTT19U.ZIP_GUY)
  Re: Crypto export limits ruled unconstitutional ("Markku J. Saarelainen")
  Re: DSA (Digital Signature Standard) and the Schnorr Patents ("rosi")
  Re: AES tweaks (David A Molnar)

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

From: [EMAIL PROTECTED]
Subject: Re: blowfish hints anyone?
Date: Mon, 24 May 1999 22:45:12 GMT

Matthew Bennett wrote:

> 1) When would it be preferable to use the ECB type instead of CFB?

Very rarely.  A file encryption program shouldn't use ECB.
CFB or CBC are good choices.

> 2) Would you just have a standard, "built-in" IV, or do
> programs get this from your password instead?

Proper use of CFB or CBC requires a unique, but not
necessarily random nor secret IV.  That is, choose an
IV generation method so that there's no significant
chance of using the same value in more than one message.
The combination of time and process number often makes a
good IV.

> 3) How do you make use of the 448-bit (max) key length of
> Blowfish when  people generally are only going to enter a
> single word in as their password?

The Blowfish description in Applied Cryptography is not
clear on this, but see the code (pages 647-654 in the
second edition).  It uses the key bytes periodically.

Discourage people from using single-word passwords.  We
like to call them "pass phrases".


A couple other points:  Upon decryption you should be
sure that you have the correct key before over-writing
any ciphertext.  You can do so by hashing the key and
IV upon encryption, storing a section of the digest along
with the message, and doing a check computation before
decryption.  You may want to use an artificially slowed
hash function to avoid aiding exhaustive attacks.

The system should detect any alteration of the ciphertext.
You can use a keyed MAC (Message Authentication Code) to do
so.

--Bryan


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

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

From: [EMAIL PROTECTED] (Aidan Skinner)
Subject: Re: ScramDisk and Windows 2000
Date: 24 May 1999 23:27:32 GMT
Reply-To: [EMAIL PROTECTED]

On Mon, 24 May 1999 15:20:57 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote: 

>> Are there any plans to produce a Windows 2000 version of ScramDisk?

>This may sound crazy, but wouldn't the current version work?  Maybe
>microsoft has some new 'portability' issues to address.. :)

Of course it does. Especially if she was running the Win9x version, on
what is basically NT5 (it's never entirely clear what M$ mean when
they say W2K).

- Aidan
-- 
http://www.skinner.demon.co.uk/aidan/
Real men whistle ed commands at 300 baud into a can.

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

From: [EMAIL PROTECTED] (Martin Grap)
Subject: Re: Reasons for controlling encryption
Date: 25 May 1999 00:08:22 GMT

>Jerry Park <[EMAIL PROTECTED]> wrote:
>>I've tried to conceptualize the reason for US export restrictions without
>>success. 
>Right. Is there _anyone_ out there that has been able to
>"conceptualize the reason for US export restrictions" ??

Well, the US export restrictions were and are very effective in
keeping strong cryptography out of a lot of mainstream products,
especially in markets which are dominated by US companies. One example
of such a market is obviously the computer industry. The OS market and
the market for most application software is dominated by the
US. Outside the US, and as far as I know even within the US, we still
have no Windows, Solaris, HP-UX, SCO UNIX or AIX which comes with
strong cryptography as a default. Outside the US we also have no
mainstream word processor, data base, web browser, web server or
e-mail client which makes use of strong cryptography as a default. The
US export restrictions probably even have slowed down the deployment
of systems which use strong cryptography inside the US, as companies
do not want to risk that they have to go through a lot of trouble when
exporting their products.

The consequence of all this is that people outside the US, and to some
extent even within the US, who want to utilize the protection offered
by cryptography, have to *actively* look for enhancements to their
systems. They have to go through the pain of buying, installing and
administrating (non US) add-ons to mainstream (US) products or to
switch to other (non US) non-mainstream products with all the
associated cost, user acceptance, interoperability and maybe
performance problems. Even though if you are aware of a security
problem and if you are determined to solve this problem by the use of
cryptography your chances are good that you will find a solution which
suits your needs and is not subject to US export restrictions. ( see
also * below)

On the other hand all the people outside the US who do not care, are
not aware of a potential security problem or can not or do not want to
deal with the additional problems (see above) get crap cryptography by
default when they buy a US product. Therefore, given the US dominance
in the computer industry, the overwhelming majority of all users
continues to be an easy target for all organizations which are
interested in the users' computers and the data which is stored,
processed or transmitted by these machines. Where these organizations
may be located in the US or outside the US and where they may be
government agencies, companies or criminal organizations. 

In other words the US export restrictions are in my opinion pretty
effective in preserving the "intelligence gathering capabilities" of
lots of people on this planet with respect to 99% of all computer
users. I think we have a similar similar situation in other areas of
information and telecommunications technology.



Martin



* This of course also applies to international terrorists and rogue
states. As frequently noted in this group the aforementioned entities
are also not limited to legally purchase the products they want. They
may be able to manufacture the needed products by themselves, if they
have the resources, or steal or smuggle them, but still they also have
to become active and have to spend a fair amount of money and/or take
the risk of being caught.

** If one looks at the issue in this way it is also logical for the US
to relax export restrictions for certain industries like banking,
health care or insurances, which have an obvious need for secure
cryptographic products and the resources (especially money) to use any
non US solution they want or even to make one by themselves. This way,
even though they can not stop these companies from using strong
cryptography, they preserve some interesting business for the US
industry and still have one foot in the door .... .


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

From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: Reasons for controlling encryption
Date: Mon, 24 May 1999 14:47:58 -0700

I have heard somewhere that to some extent the role of current encryption
controls is to lead the balance of encryption development and innovation so that
there is a certain inward pull process for the benefit of the centralized
cryptographic control. What do you think?



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

From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: AES tweaks
Date: Mon, 24 May 1999 16:22:00 -0700

I have been following this AES discussion for some time. Knowing many
aspects of open standards development processes, these standardization
activities typically last quite a long time and in many ways, when a new
standard comes out, it may well already be out-dated. So whatever is going
on with AES, it may be intelligent to doubt the real security of these
protocols. Any way, just a thought ... Cheers!



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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: AES tweaks
Date: 25 May 1999 00:59:51 GMT

Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
> I have been following this AES discussion for some time. Knowing many
> aspects of open standards development processes, these standardization
> activities typically last quite a long time and in many ways, when a new
> standard comes out, it may well already be out-dated. So whatever is going
> on with AES, it may be intelligent to doubt the real security of these
> protocols. Any way, just a thought ... Cheers!

You are correct in noting that standards can lag the "latest" developments,
especially when the standard is important enough to warrant a long 
process before being fixed. At the same time, I think you are 
underestimating the ability of this particular process for the AES
to react to such developments. The entire AES process is aimed at 
producing a standard which will be resistant to being "out-dated."

After all, what does "out-dated" mean in the context of a standard?
Your comment on "intelligent to doubt the real security of these 
protocols" suggests that the fear is that the cipher chosen as AES
will become insecure as the result of some new cryptanalytic attack. 
Against this fear I would point to the rather large amounts of 
effort currently being expended on analysis of each of the current
candidates. We can argue over how much assurance this buys us,
but it is much better than nothing. 

This is not to say that the current process is perfect. Doubtless not
every worthwhile cipher design has been entered in the AES competition.
Terry Ritter, for instance, has explained in other threads how his 
disagreement with the patent/royalty requirements of the AES has
prevented him from entering. Then there's the debate over whether to
certify one or multiple ciphers as AES. When the winner is chosen,
there will likely be dispute about whether the "right" decision ws
made; one of the updates from the AES conference already mentioned
the possibility of national bias. 

I'm sure you can raise lots of questions about the AES, but I do not
think that it should be dismissed out of hand in a single sentence.
Then again, considering that the original post was intended to provoke
response, I wonder if you do, either. :-> <g>
 
-David Molnar
P.S. I would mention IEEE P1363 as another example of a standards 
process, but I'm still lurking / new enough as to be reluctant
to comment. 


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

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: SHA-1 unpatented?
Date: Tue, 25 May 1999 01:12:01 GMT

In article <[EMAIL PROTECTED]>,
Alwyn Allan  <[EMAIL PROTECTED]> wrote:
>Related: Does anyone know the status of MD2. Is it patented? It was licensed
>for free for "non-commercial e-mail privacy" or something like that. If I
>write MD2 code from the RFC's that specify it, but do not use RSA's code, do
>I violate their copyright? Since the Pi permutation table is only given in
>the code, can this be obtained elsewhere?

It's not patented.  The pi table and a sample implementation are in
RFC 1319, IIRC.  But use SHA-1 instead.  MD2 is a lot slower and its
security is questionable.  The only reasons to use it are legacy
compatibility, and that it's comparatively easy to implement on 8-bit
processors.

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

From: [EMAIL PROTECTED] (John Kennedy)
Subject: Re: HushMail -- Free Secure Email
Reply-To: [EMAIL PROTECTED]
Date: Tue, 25 May 1999 01:11:02 GMT

On Mon, 24 May 1999 08:35:25 -0700, Peter Pearson
<[EMAIL PROTECTED]> wrote:

>Does my browser download an applet from HushMail every time
>I send encrypted mail?

Seems so.

> If so, don't I have to examine that
>applet every time, before I run it, to make sure it's not
>an evil impostor that's going to send out my private key?

To know you're secure, yes that would be one requirement.

>If so, is there any way to automate that process?

I would think that's possible, but I see no evidence that it's been
implemented in this case yet.


--

John Kennedy

--

The causal world imposes a nonarbitrary distinction between detecting in one's visual 
array
the faint outline of a partly camouflaged stalking predator and not detecting it 
because of
alternative interpretative procedures. Nonpropagating designs are removed from the
population, whether they believe in naive realism or that everything is an arbitrary 
social
construction. 

                            (Tooby and Cosmides, in _The Adapted Mind_, Barkow, 
Cosmides and Tooby, editors )

=======

Best Anarchy Links:

David Friedman -> http://www.best.com/~ddfr/
Niels Buhl -> http://www.math.ku.dk/~buhl/
Billy Beck -> http://www.mindspring.com/~wjb3/promise.html
========


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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reasons for controlling encryption
Date: Tue, 25 May 1999 03:24:56 GMT

In article <7icplm$d92$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Martin Grap) wrote:

>** If one looks at the issue in this way it is also logical for the US
>to relax export restrictions for certain industries like banking,
>health care or insurances, which have an obvious need for secure
>cryptographic products and the resources (especially money) to use any
>non US solution they want or even to make one by themselves. This way,
>even though they can not stop these companies from using strong
>cryptography, they preserve some interesting business for the US
>industry and still have one foot in the door .... .
>

  You wrote a lot but just thought I would attack the last paragraph. 
The US has no interest in really protecting industries like "banking"
since this would interfer with a vital area of information collecting and
would hinder things like the disruption of records for Yugoslovia.
 If you follow recent news events the NSA my have been ordered
to cause disruption in that area. You are being fooled if you think
the NSA would actually help the banking industry make secure
transactions. Big Brother wants to know every thing and I am
surprised you haven;t figured that out yet.



David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

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

From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Why would a hacker reveal that he has broken a code?
Date: Mon, 24 May 1999 20:25:57 -0400
Reply-To: [EMAIL PROTECTED]

SCOTT19U.ZIP_GUY wrote:
(*********)
>  As an example in another field look at the research and money spent
> on uclers. A guy in Australla ( I think it was there the news is surpressed)
> came up with the simple truth of most casues and a cure. The guy was
> ridiculed by the medical gods as an idiot. Of course he was right and
> it is very likley the other medical people knew it. But to keep there pockets
> lined with monely they did there best to treat the guy like shit. Where is
> this guy today. Does anyone even remember his name. And what happened
> to his attackers.
> 
> David A. Scott
======================
The guy's name is Barry Marshall, and I learned about his discovery
about 1993 (the discovery itself dates back to early 80-s).
  After discovering the infectious nature of peptic ulcers and 
producing the bacterial culture "in vitro", he did the only thing
which an honest doctor should do - he infected himself. In 72 hours he
had all clinical symptoms of severe peptic ulcer, then in 10 days he 
healed himself with antibiotics. 
  It took more than 15 years for his discovery to be accepted, but now
the medical reference books all mention the "Helicobacter Pylori" as
the prime suspect in peptic ulcer (for those who read these books).
On the other hand, practicing physicians keep this information hidden
from their patients, and repeatedly perscribe diet, acid reducers and
other Bl-St so that patients would return to them year after year.

  Moral: never go to a doctor without doing your homework first.
         remember - all doctors are in business, they care first
         about their checkbook, then about their business partners,
         and then, (maybe...) about your well-being.

    Best wishes         BNK
> --
>                     SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
>                     http://www.jim.com/jamesd/Kong/scott19u.zip
>                     http://members.xoom.com/ecil/index.htm
>                     NOTE EMAIL address is for SPAMERS

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

From: "rosi" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Mon, 24 May 1999 22:25:46 -0400

I quit agree.

Not only on this one, but in a more general setting. There are many
patents but few inventions.

One sometimes has to be very clear at first on what grounds he talks
about such a thing (or not?) Patenting certainly it is not doing
mathematics where universality is the norm. People may agree on
certain issues concerning patents, but this one is likely not one of
those.

--- (My Signature)

Paul Rubin wrote in message ...
>In article <[EMAIL PROTECTED]>,
>Vin McLellan  <The, Prtivacy, Guild> wrote:
>>...Bruce Schneier, who studied and wrote about the DSS patent issues
>>in Applied Crypto, certainly didn't glibly dismiss Schnorr's claims
>>as some have here.
>
>"In my opinion, this finally puts to rest any patent dispute between
>Schnorr[1398] and DSA[897]: DSA is not a derivative of Schnorr, nor
>even of ElGamal.  All three are examples of this general construction,
>and this general construction is unpatented."
>  --Applied Cryptography (2nd ed.), p. 498.



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES tweaks
Date: Tue, 25 May 1999 03:50:05 GMT

In article <7icsm7$1io$[EMAIL PROTECTED]>, David A Molnar 
<[EMAIL PROTECTED]> wrote:
>Markku J. Saarelainen <[EMAIL PROTECTED]> wrote:
>> I have been following this AES discussion for some time. Knowing many
>> aspects of open standards development processes, these standardization
>> activities typically last quite a long time and in many ways, when a new
>> standard comes out, it may well already be out-dated. So whatever is going
>> on with AES, it may be intelligent to doubt the real security of these
>> protocols. Any way, just a thought ... Cheers!
>
>You are correct in noting that standards can lag the "latest" developments,
>especially when the standard is important enough to warrant a long 
>process before being fixed. At the same time, I think you are 
>underestimating the ability of this particular process for the AES
>to react to such developments. The entire AES process is aimed at 
>producing a standard which will be resistant to being "out-dated."
>
>

  I feel that you are wrong. It is obvious the entire AES process is only
aimed at keeping encryption easy for the NSA to read. As you know the
NSA does its best to try to make encryption programs illegal to export
since a large number of methods would make it hard to read peoples mail.
So they came up with the CLIPPER chip but to many people screamed.
So this is just an extension of that process. No way in HELL would the
NSA let a secure method become a standard. I am not sure which horse
in this race the NSA is backing but I would not trust any method where some
of the developers could have been influenced by the NSA. and it is more than
likely they can break several if not all of the methods that where granted
this special status. I doubt if any method that is unbreakable by the NSA
has a snow balls chance in hell of being blessed.
 Because encryption is information that is as guarded as nuclear secrets in 
the US you are not likely to find much good info about either in the free 
press but if you have good chinese connections one might be able to find out
what the NSA thinks is secure because we seem to like to give them our best
secrets but then again they seem to know which pockets to grease. I may be
wrong but I had to pee several times for Uncle Sam may be if I was chinese or
a high government offical my piss would have been required less often. Does
anyone know how often Clinton has to pee for Uncles tests. Oops I am sorry
the higher one is in government and the more one really knows the less one 
gets tested. Yes that is the way it is in government the chinese are smart
enough to go after political leaders and management becuase of there special
status in the US of being above corruption only the common man is not to
be trusted and if one works for the governement you quickly learn to kiss the
ass of management or you don't go up..



David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

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

From: "Markku J. Saarelainen" <[EMAIL PROTECTED]>
Subject: Re: Crypto export limits ruled unconstitutional
Date: Mon, 24 May 1999 23:14:46 -0700

Actually ... a real story ...

Once Bob asked Alice, if Bob knew a very unique language called "Boblingo"
that
nobody else knew, should Bob be able to teach Alice how to speak and
understand
this "Boblingo" in order to communicate in this language . Alice's answer
was
promptly "Yes". This just gives an interesting insight ...



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

From: "rosi" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.security.pgp,comp.security.pgp.discuss
Subject: Re: DSA (Digital Signature Standard) and the Schnorr Patents
Date: Mon, 24 May 1999 22:52:47 -0400

This is one that interested me.

Am I correct that Roger is the one 'entangled' with RSA in some kind
of a law suit? Actually it was that argument that led to the questions I
did not ask. (Part of the reason being not wanting to get entangled
as well. Strong primes, necessary or not, not really necessary to
take a stand. But Roger's link to the article about Bidzos in which
the NIST telling Prof. Schnorr to 'get lost' started my questions,
quite similar to those brought up here. And strangely enough I was
this morning thinking about this thing!)

Roger Schlafly wrote in message
[ ... etc. ...]
>* Yes, DSS was intended for authentication, not confidentiality.
>Most crypto people have now come around to the view that
>encryption and signature keys should be separate.
>

   'now'! What a shame! But never too late! I like the making explicit
the point by Roger in his next post. Secrecy, data integrity, and
source identification are too different beasts.

   You may entrust a 'trusted' party for signature, which is much too
active an act. 'Isurance', a thing I saw people trying to bring into
the picture of privacy, is a bit more fitting here. I think, there is much
more (much more time at hand too) to assist in checking here.

>* Although DSA does not explicitly give a confidentiality method
>(encryption or key agreement), the closely related Diffie-Hellman
>methods are well-known and widely used. Use of DSA does not
>inhibit confidentiality.
>
>* We may soon find out whether historians will find that patents
>contributed to the spread of strong crypto. The MIT/RSA patent
>runs out in Sept. 2000. My guess is that use of strong crypto will
>go up at that time, not down.
>
>* All this spook conspiracy talk belongs in the X-files. The specs
>for Fortezza have been declassified. Sure, the NSA has some
>GAK-related motives, but these grand conspiracy theories just
>haven't panned out.
>
>
>



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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: AES tweaks
Date: 25 May 1999 03:12:41 GMT

SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:

>   I feel that you are wrong. It is obvious the entire AES process is only
> aimed at keeping encryption easy for the NSA to read. As you know the
> NSA does its best to try to make encryption programs illegal to export
> since a large number of methods would make it hard to read peoples mail.
> So they came up with the CLIPPER chip but to many people screamed.
> So this is just an extension of that process. No way in HELL would the
> NSA let a secure method become a standard. I am not sure which horse
> in this race the NSA is backing but I would not trust any method where some
> of the developers could have been influenced by the NSA. and it is more than
> likely they can break several if not all of the methods that where granted
> this special status. I doubt if any method that is unbreakable by the NSA
> has a snow balls chance in hell of being blessed.


All right. We disagree, then. I admit that my view of AES is somewhat
idealistic. I have some faith that the NSA will not dictate the final
outcome, or at least if they do then the fact that other well-qualified
ciphers were passed over will not pass without notice. 
I also can not dismiss the NSA's involvement out of hand,
since they clearly were involved in the creation of DES with their
own aims and interests in mind. 

Right now I am not as worried as you, since the AES designs seem to 
have been independently developed. If/when the NSA "tweaks" them
as it did Lucifer, then I'll start worrying. As you point out, this
may be difficult to notice, since none of us (few of us?) know all
of the developers personally. 

In any case, it is probably a good thing to have this much attention
paid to block ciphers...and even if they are all breakable by some
secret NSA attack, past results tell us that this will be 
discovered about 25 years from now. Just in time to get my kids
(should I have any) interested in cryptography. 

-David Molnar


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


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