Cryptography-Digest Digest #931, Volume #10 Wed, 19 Jan 00 18:13:01 EST
Contents:
Re: Beginners questions re-OTPs (Mok-Kong Shen)
palm pgp? (Eric Farkas)
Re: Triple-DES and NSA??? (Bernie Cosell)
Re: Suitable hash for this application - in the public domain? (Jerry Coffin)
Re: 1on1lite (Was: Re: Echelon monitors this group) ("Thomas J. Boschloo")
Combination of stream and block encryption techniques (Mok-Kong Shen)
Question about Digital Cash ("Jeff Moser")
Re: RNG for OTPs during WWII ("Bayard Randel")
Re: Combination of stream and block encryption techniques (John Savard)
Re: Java's RSA implimentation ("Bayard Randel")
Predicting Graphs. ([EMAIL PROTECTED])
What about the Satanic Seven??? ("John E. Kuslich")
Re: RSA survey ([EMAIL PROTECTED])
Re: What about the Satanic Seven??? (Sisson)
Re: Suitable hash for this application - in the public domain? (Troed)
Re: What about the Satanic Seven??? (Glenn Larsson)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Beginners questions re-OTPs
Date: Wed, 19 Jan 2000 21:22:09 +0100
Douglas A. Gwyn wrote:
>
> John Savard wrote:
> > If methods 1 or 2 work, it isn't an OTP.
>
> It could be, just not an optimal one.
I am curious to know what 'method 1' really (concretely) means
in a 'realistic' context. After all, how is the 'OTP' defined in
this particular connection? I presume it is some 'relaxed'
definition. For we know from past discussions of this group that
a theorecitcally 'ideal' OTP cannot be obtained -- or rather
known to have been obtained -- in practice, because there is no
way to practically verify that.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Eric Farkas)
Subject: palm pgp?
Date: 19 Jan 2000 20:48:53 GMT
------------------------------
From: Bernie Cosell <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Wed, 19 Jan 2000 15:43:22 -0500
[EMAIL PROTECTED] (Bruno Wolff III) wrote:
} From article <[EMAIL PROTECTED]>, by Jose Castejon-Amenedo
<[EMAIL PROTECTED]>:
} >
} > For all we know, the NSA's intervention made DES more (not less)
} > robust than it would have otherwise been.
}
} Except for limiting the keysize to 56 bits. This may have been done to allow
} them to break it with special purpose hardware that would not typically been
} available to most entities wanting to break messages encrypted with DES.
Not true. As we civilian folk discovered [what was it, *eight* years
later?] there is an _inherent_ weakness in the way DES works which allows
an attack that does _not_ involve forcing the password... said attack was
took 2^49 I think. What that means is that password bits much beyond 49
[or the next multiple-of-8...tadaah: 56] are fake security. Lowering the
password length from 64 to 56 bits was the *right*thing*to*do* [and almost
certainly means that NSA well-understood differential cryptanalysis WELL
before any of us did].
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Suitable hash for this application - in the public domain?
Date: Wed, 19 Jan 2000 13:59:39 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Hi,
>
> I need a good hash algorithm for storing user passwords. The hash will
> later be used in encryption routines. At the moment 32 bytes are used
> to store the hash, which far exceeds MD5 (not secure enough?) and
> SHA-1. I've also looked at RIPE-MD, which I heard has a 256 bit
> variant (no more secure than the 160 bit version though)
>
> Are the various C-implementations of RIPE-MD 160 free for private and
> commercial use? Any pointers to a 256 bit implementation?
>
> If RIPE-MD isn't free, what other options do I have?
There are two separate issues to consider. First of all, there's the
algorithm itself. Second, there's any particular implementation of
that algorithm. Even (to use your example) of RIPE-MD itself is free,
that doesn't mean that all implementations of it are free.
As far as I can tell (though I haven't investigated in detail) the
MD5, SHA and RIPE-MD160 algorithms are all free. That leaves it to
you to figure out whether a particular piece of code implementing one
of them is protected under copyright.
Of these three, I consider SHA-1 probably the best, and MD5 probably
the weakest: though I don't know of anybody who's come up with a real
attack on MD5, there are a number of papers around (e.g:
http://www.cs.ucsd.edu/users/bsy/dobbertin.ps) talking about
characteristics that might eventually be turned into attacks.
In any case, there's little or no room for question that the SHA-1
algorithm is free. I wrote an implementation a while back, and I
think I can give it away (though I'll have to check with my boss to be
sure).
I should warn you that the version I wrote was intended for
readability, so I did as close as I could manage to a transliteration
of the NIST spec into C (up to and including using the same names for
variables). It was fast enough for my purposes, so I never did
anything to optimize it at all -- I'm sure there are faster
implementations around.
If you really want 32 bits of output, the most obvious suggestion
would be to concatenate the results from SHA-1 with the results from
RIPE-MD 160, and discard the excess (or perhaps mix and mash it with
the rest using something like an XOR).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To:
alt.anarchism,alt.computer.security,alt.security,alt.security.espionage,alt.security.pgp
Subject: Re: 1on1lite (Was: Re: Echelon monitors this group)
Date: Wed, 19 Jan 2000 20:18:01 +0100
This is a multi-part message in MIME format.
==============3F6D1303720DA9530A472450
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
=====BEGIN PGP SIGNED MESSAGE=====
Andrew Kwiatkowski wrote:
>
[1on1mail website <http://www.1on1mail.com> > > >]:
> > > Registration is the cornerstone of 1on1mail security.
> > > During registration you are asked to provide a password to protect
> > > the mail stored on your client. The password you choose is only used
> > > to protect the mail stored on your client. Every other password is
> > > selected by the server on your behalf. This prevents any user from
> > > compromising mail security by selecting a weak or obvious password.
> >
> > Wow, this is great for your e-mail security. No weak passwords!! You'll
> > have to write them down of course, if I understand correctly.
> >
>
> No you don't.
Sorry about that. But it seems better to me to generate passwords at the
client site for increased security. If you generate them at your central
server, we place our trust in your company and your server, while if
they are created at our own computer, we only have to trust ourselves
(if the software is written properly, which of course it is).
> > > We have even bypassed the arguments about how random a
> > > random number generator can be. Passwords are derived from truly
> > > random and totally unpredictable sources such as stock market quotes,
> > > background noise from several university radio telescopes, and
> > > internet search times.
> >
> > Wow, stock quotes. Now *THAT* is a good source of randomness. I'm
> > getting a warm fuzzy feeling. I wonder where they get their random
> > background noise BTW <grin> www.nasa.org?
(Sorry, I meant www.seti.org. You can get free random space noise from
them in large quantities, can't you?)
> No we acctually ask Echelon to provide it for us.
Do you have connections with the NSA?! Echelon is a worldwide spy
network operated by the American National Security Agency.
<http://www.nrc.nl/W2/Lab/Echelon/interccapabilities2000vp.html>.
> > They even have a
> > challenge. You can win USD 50000 if you can crack their 448 bit blowfish
> > encrypted message! <http://www.1on1mail.com/k50000.html> Or is it 2048
> > bit RSA, I'm not sure from what it says at their site, but we've just
> > broken 512 bits, so why not?!
>
> So you have then , why don't you try for the 50 000 then ?
I was just being sarcastic. The CWI in Amsterdam cracked RSA-155 some
months ago. That was 512 bits. 700 bits should be safe for the next
10-12 years according to Bob Silverman from RSA Inc. 2048 bits is way
beyond that. Somewhere between 100 and 128 bits strength, which makes
you wonder why you used 448 bit blowfish for symmetric encryption. Seems
a bit overkill (by at least 300 bits compared to RSA). As an example of
how strong just 362 bits is, I have included a post from Scott Nelson.
> If anyone else is interested, please read about the program carefully if it
> is not anything you looking for, ok don't use it, but please don't go around
> bashing other people hard work. Especially if you did not seam to understand
> how the system works like our friend Thomas.
I am trying to understand, only your site doesn't give much information
about your product. Does it use reordering, latency, what are the other
passphrases for that get generated server side, how is the authenticity
of RSA keys validated, is there a authenticity check possible between
users, how does it enforce the deletion of expired documents, how do two
users agree on a mutual session key, can the system be used between
normal e-mail users and 1on1lite users, how?
While I do believe the system is more userfriendly than pgp and
remailers, I think I would rather use Freedom <http://www.freedom.net>
at $49.95 a year plus pgp for my secure and secret communications.
Good luck with 1on1mail, I hope it is secure,
Thomas
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQB5AwUBOIX/0gEP2l8iXKAJAQEBWwMgizlJCXSmDqqrt9mX8QhIzRKAUBf7pFE3
7/fjm9QLY0N15RWLr3A+eAfwZ3pEP7+B+hfnYHnTfh6xXVIfsyNLvbQOrHzxsrZa
usP3qRnfxiLQuhNTo5K81m+CqRgJmg7L9RJuqg==
=HV2M
=====END PGP SIGNATURE=====
--
Boycot Intel Pentium III <http://www.bigbrotherinside.com/>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
==============3F6D1303720DA9530A472450
Content-Type: text/plain; charset=us-ascii;
name="128pkeys.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="128pkeys.txt"
Path:
news2.support.nl!news-x.support.nl!newsfeed.icl.net!news.algonet.se!algonet!newsfeed.online.be!tank.news.pipex.net!pipex!uunet!ams.uu.net!nyc.uu.net!pao.uu.net!news.inreach.com!not-for-mail
From: [EMAIL PROTECTED] (Scott Nelson)
Newsgroups: comp.security.pgp.discuss,sci.crypt,alt.security.pgp
Subject: Re: Is 128 bits safe in the (far) future?
Reply-To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Newsreader: Forte Agent 1.5/32.452
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 43
Date: Thu, 07 Oct 1999 22:25:54 GMT
NNTP-Posting-Host: 209.209.19.160
X-Trace: news.inreach.com 939334871 209.209.19.160 (Thu, 07 Oct 1999 15:21:11 PDT)
NNTP-Posting-Date: Thu, 07 Oct 1999 15:21:11 PDT
Organization: InReach Internet
Xref: news2.support.nl comp.security.pgp.discuss:1493 sci.crypt:6042
alt.security.pgp:2804
On Wed, 06 Oct 1999 23:18:39 -0400, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
[edited]
>Thomas J. Boschloo wrote:
>
>> "Trevor Jackson, III" wrote:
>> It has however made me extremely curious as to what your
>> worst case bit length would be?
>>
>
>Taking the reductio-ad-absurdum numbers I mentioned originally I think you
have 1e33^3
>processors per cubic meter, 1e16^3 meters per cubic light year, and 1e10^3
cubic light
>years per observable universe. Total processor count is thus 1e178. Given
a cycle time
>of 1e-43 seconds, 3e7 seconds per year, and the life of the universe at
1e31 years, you
>have 3e81 testing cycles. Total number of tests is 3e259.
>
>That's about 865 bits. Quite a lot by today's crypto standards. Not a lot
given the rate
>of growth in machine capacities.
>
You can get a much smaller number if you assume that
testing a key requires some energy. This is also
convenient since we don't have to address the time
issue at all.
Mass of the observable universe, < 1e52 kilograms
1Kg, < 1e17 Joules.
Energy needed for calculation, > 1e-40 Joules.
upper-bound on number of key tests performable in
the observable universe; 1e109, or 362 bits.
If you're willing to add other restrictions like
"you can't convert mass to energy without loss,"
or "you have to save some of the universe to live in,"
then you can use even fewer bits.
There are ciphers with more than 362 bit keys,
but long before 256 bits is reached, it becomes easier
to find the key by looking in every place it might
be hidden (including your adversaries mind.)
Scott Nelson <[EMAIL PROTECTED]>
==============3F6D1303720DA9530A472450==
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Combination of stream and block encryption techniques
Date: Wed, 19 Jan 2000 22:36:03 +0100
In the attachment below, which is extracted from a recent issue
of Crypto-Gram, Bruce Schneier has effectively confirmed (if I
understand correctly) that it is desirable to combine the best of
both (what are traditionally termed) stream and block encryption
technologies, a viewpoint that was occasionally also raised in the
past in this group. Does anyone want to contribute new discussions
on this issue? Thanks.
M. K. Shen
=======================================
(From CRYPTO-GRAM, Jan 15, 2000)
So, block and stream ciphers are basically the same thing; the
difference
is primarily a historical accident. You can use a block cipher as a
stream
cipher, and you can take any stream cipher and turn it into a block
cipher.
The mode you use depends a lot on the communications medium -- OFB or
CBC
makes the most sense for computer communications with separate error
detection, while CFB worked really well for radio transmissions -- and
the
algorithm you choose depends mostly on performance, standardization, and
popularity.
There's even some blurring in modern ciphers. SEAL, a stream cipher,
looks
a lot like a block cipher in OFB mode. Skipjack, an NSA-designed block
cipher, looks very much like a stream cipher. Some new algorithms can
be
used both as block ciphers and stream ciphers.
But stream ciphers should be faster than block ciphers. Currently the
fastest block ciphers encrypt data at 18 clock cycles per byte (that's
Twofish, the fastest AES submission). The fastest stream ciphers are
even
faster: RC4 at 9 clock cycles per byte, and SEAL at 4. (I'm using a
general 32-bit architecture for comparison; your actual performance may
vary somewhat.) I don't believe this is an accident.
Stream ciphers can have a large internal state that changes for every
output, but block ciphers have to remain the same. RC4 has a large
table
-- you can think of it as an S-box -- that changes every time there is
an
output. Most block ciphers also have some kind of S-box, but it remains
constant for each encryption with the same key. There's no reason why
you
can't take a block cipher, Blowfish for example, and tweak it so that
the
S-boxes modify themselves with every output. If you're using the
algorithm
in OFB mode, it will still encrypt and decrypt properly. But it will be
a
lot harder to break for two reasons. One, the internal state is a
moving
target and it is a lot harder for an attacker to build model of what is
going on inside the state. Two, if the plaintext-to-ciphertext
transformation is built properly, attacks based on chosen plaintext or
chosen ciphertext are impossible. And if it is a lot harder to break a
cipher with self-modifying internals, then you can probably get by with
fewer rounds, or less complexity, or something. I believe that there is
about a factor of ten speed difference between a good block cipher and a
good stream cipher.
Designing algorithms is very hard, and I don't suggest that people run
out
and modify every block cipher they see. We're likely to continue to use
block ciphers in stream-cipher modes because that's what we're used to,
and
that's what the AES process is going to give us as a new standard. But
further research into stream ciphers, and ways of taking advantage of
the
inherent properties of stream ciphers, is likely to produce families of
algorithms with even better performance.
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Question about Digital Cash
Date: Wed, 19 Jan 2000 16:31:02 -0500
In Applied Crypto, Bruce mentions a scheme where "Alice" has to present the
left or right half of the shared identity secret for each pair depending on
the random bit she is given. He says that these halves are all bit committed
and signed.
Now, I know I probably didn't read too heavily into it, but how exactly does
the merchant know it is getting authentic bits and not some random string?
Surely the bank can't sign each half blindly?
Thanks for your help!
Jeff
------------------------------
From: "Bayard Randel" <[EMAIL PROTECTED]>
Subject: Re: RNG for OTPs during WWII
Date: Thu, 20 Jan 2000 10:54:21 +1300
Ah, many thanks. I will have to pick up a copy of "The Ultra Secret" and
investigate further :)
Bayard Randel
Christchurch, NZ
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Rubin wrote:
> > Bayard Randel <[EMAIL PROTECTED]> wrote:
> > >Just out of historic interest, would anyone happen to know what sort of
RNGs
> > >would have typically been used by either Allied or Axis forces for OTP
> > >keystream generation ? dice, playing cards ?
> > Winterbotham discussed this in "The Ultra Secret". I vaguely recall
> > that dice were used, but I'm not sure.
>
> There were several methods used by the various OTP generators.
> For example, one of them mixed the typographic "slugs" and
> typeset them in oblivious order to print the 2 copies of the pad.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Combination of stream and block encryption techniques
Date: Wed, 19 Jan 2000 14:57:03 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>Does anyone want to contribute new discussions
>on this issue?
I don't see what else there might be to say. I'm glad to see
"establishment" support for this idea, which is one that will allow
more secure ciphers to be constructed which still execute in a
reasonable amount of time.
Block ciphers do have certain convenience advantages, even if they are
somewhat illusory: it's still inconvenient to do something different
from what you understand, even if it wouldn't _really_ be any harder
if you took the time to investigate more closely.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Bayard Randel" <[EMAIL PROTECTED]>
Subject: Re: Java's RSA implimentation
Date: Thu, 20 Jan 2000 11:07:04 +1300
Is there not a method that can be applied for garbage collection/flushing
buffers?
Bayard Randel
Christchurch, NZ
larry <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 19 Jan 2000 14:53:29 +0100, [EMAIL PROTECTED] (Paul Schlyter)
> wrote:
>
> >In article <863m2q$abe$[EMAIL PROTECTED]>,
> >Bill Unruh <[EMAIL PROTECTED]> wrote:
> >
> >> In <862upd$vr$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >>
> >>> Is anyone aware of any effort to analyse the RSA implementation in
Java;
> >>> specifically focusing on key generation.
> >>
> >> ??? Java is a language, much like C in many essentials. It is up to you
> >> to code what you want it to do.
> >>
> >> >Does Java use a table of primes? If so, how big is the table?
> >>
> >> No, Java does not. But you can enter a table of primes if you wish. And
> >> you can encode a prime testing routine in Java just as you can in C.
> >>
> >>> Otherwise how good is it's prime number generation routines ie. what
is
> >>> the probability of a generated number not being prime.
> >>
> >> I do not know that Java has a "prime number generating routine". but
you
> >> can code one up in Java.
> >> Jus tread the code in any RSA implimentation.
> >
> >One difference between C/C++ and java is that Java is now getting a
> >standard bignum class, which may contain prime number generating
> >code. C/C++ never had that, and probably never will.
> >
> >--
> >----------------------------------------------------------------
> >Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> >Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
> >e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
> >WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
>
> One big concern I have is that Java bignums (BigInteger objects) are
> "immutable". They can't be altered once created. If you do something
> like "A=A+1", a new object is created (with the new value of A), and
> the old object (with the old value of A) becomes garbage, but remains
> lying around in memory until the garbage collector decides to recycle
> it (i.e. until who knows when).
> So the problem is, private key material kept in BigIntegers can't be
> wiped out when no longer needed. It sits in memory for an
> undetermined and potentially long time. Long enough to make being
> swapped out to a pagefile rather likely (or long enough for a memory
> sniffer to find it). If someone can get that pagefile, they can get
> the private key.
> If I need to have private key material in memory, I prefer it to be
> for the shortest duration of time possible. If it's in a Java
> BigInteger, I have no way to restrict how long it stays in memory.
------------------------------
From: [EMAIL PROTECTED]
Subject: Predicting Graphs.
Date: Wed, 19 Jan 2000 22:03:47 GMT
Is it possible to predict the course of a curved line graph with a
computer? Could a computer simulate this graph up to numbers the size
of 10^300?
Thanx
Jack
P.S. It is related to crypto - I'm just not telling you how.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: What about the Satanic Seven???
Date: Wed, 19 Jan 2000 15:16:25 -0700
Will someone please explain to me how the new crypto regs apply to the
situation when you have a strong crypto thingy you want to export from
your web site and you have notified the Feds that you intend to export
via a web site BUT
you cannot export to Cuba, Iran etc.
How do you stop those people in the seven bad nations from downloading
your stuff??? Do you have to have your server attempt to filter this
stuff?
Is it not obvious to anyone with a brain (or even perhaps the people who
write these regs) that people in the seven dirty nations can get
whatever they want by well known means if it is otherwise available on
the Internet?
What am I missing here? The emperor really has no clothes, right???
Is this not a terrible ambiguity in the regs???
What's a guy to do in this case?
JK
--
John E. Kuslich
Password Recovery Software
CRAK Software
http://www.crak.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA survey
Date: Wed, 19 Jan 2000 22:06:35 GMT
In article <85vklp$j08$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Just a quick survey... What size of RSA key would you feel safe with
> for your crypto needs?
I'm quite happy with something in the region of 10^120... but then I
don't have anything that really needs securing.
Jack
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sisson <[EMAIL PROTECTED]>
Subject: Re: What about the Satanic Seven???
Date: Wed, 19 Jan 2000 22:38:52 GMT
i think the PGP site makes you "i agree" to some agreement before you
download. it also then has Q&A "Will you export it?" and if you answer the
wrong question then it stops your download. It also checks your IP i think,
to find what nation you're downlaoding from.
I think its a stupid law, because all you need i one person to email it
country thats not allowed it, and its into distribution. they can't do
simple checks like metal scans for terrorists that go to aeroplanes
>From Spendabuck
"John E. Kuslich" wrote:
> Will someone please explain to me how the new crypto regs apply to the
> situation when you have a strong crypto thingy you want to export from
> your web site and you have notified the Feds that you intend to export
> via a web site BUT
>
> you cannot export to Cuba, Iran etc.
>
> How do you stop those people in the seven bad nations from downloading
> your stuff??? Do you have to have your server attempt to filter this
> stuff?
>
> Is it not obvious to anyone with a brain (or even perhaps the people who
> write these regs) that people in the seven dirty nations can get
> whatever they want by well known means if it is otherwise available on
> the Internet?
>
> What am I missing here? The emperor really has no clothes, right???
>
> Is this not a terrible ambiguity in the regs???
>
> What's a guy to do in this case?
>
> JK
>
> --
> John E. Kuslich
> Password Recovery Software
> CRAK Software
> http://www.crak.com
------------------------------
From: [EMAIL PROTECTED] (Troed)
Subject: Re: Suitable hash for this application - in the public domain?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 19 Jan 2000 22:37:08 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
>There are two separate issues to consider. First of all, there's the
>algorithm itself. Second, there's any particular implementation of
>that algorithm. Even (to use your example) of RIPE-MD itself is free,
>that doesn't mean that all implementations of it are free.
Thanks for your answer, this is just what I wanted to know. I would
have no problems at all implementing a version myself, but if there is
ready-made and proof-verified code available I wouldn't have any
problems using that instead :)
>If you really want 32 bits of output, the most obvious suggestion
>would be to concatenate the results from SHA-1 with the results from
>RIPE-MD 160, and discard the excess (or perhaps mix and mash it with
>the rest using something like an XOR).
(32 bytes, but I see that's what you meant anyway :)
Well, the hash is used as a key for encryption rounds later, that's
why I would like it to be 32 bytes. I'm however changing the
encryption routines also, so I might get away with a 160 bit hash.
I'll have a look at doing some implementation now, thanks again.
___/
_/
------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: What about the Satanic Seven???
Date: Wed, 19 Jan 2000 23:26:22 +0100
John E. Kuslich wrote:
>
> you cannot export to Cuba, Iran etc.
>
> How do you stop those people in the seven bad nations from downloading
> your stuff??? Do you have to have your server attempt to filter this
> stuff?
>
> Is it not obvious to anyone with a brain (or even perhaps the people who
> write these regs) that people in the seven dirty nations can get
> whatever they want by well known means if it is otherwise available on
> the Internet?
>
> What am I missing here? The emperor really has no clothes, right???
>
> Is this not a terrible ambiguity in the regs???
>
> What's a guy to do in this case?
>
> JK
Well, Microsoft did this really complex location check to
prevent anyone outside the us to download the 128 bit Service
packs for Windows NT;
First by Ip, Then by checking the BROWSER, because you could
trick the download wizard via altavista's babelfish...
(How did i know that? ;o)
Some other people put notices that said something like
"if you're not from the Us, you're not allowed to access this
information that you can get from any other site outside the
us" (As in *humor* :o)
Some websites allows to filter access by IP, but there are NO
IP LISTS that cover the Satanic Seven, that you can retrive and
apply with ease to your webserver. There is no garantee that
someone inside some country sends a copy to one of the Satanic
Seven countries either. Example:Somebody at an embassy walk to
Joe Q Random's "Internetcafe" and send a product to an email
adress in one of those countries.
I've had this discussion with the ISP in Sweden and know of no
good way of excluding downloads from any of the Satanic Seven
countries, Except for exporting ~2^64 bit crypto products and
then in the license key; activating the 128 bit crypto when the
purchaser have identified him/herself.
If anyone have any better ideas please let us know.
Regards,
Glenn
Sweden
------------------------------
** 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
******************************
