Cryptography-Digest Digest #827, Volume #12 Tue, 3 Oct 00 14:13:01 EDT
Contents:
Is there any keyed MD5 or Blowfish encryption software out there?
([EMAIL PROTECTED])
Re: is NIST just nuts? (Tom St Denis)
Re: Looking Closely at Rijndael, the new AES (Tom St Denis)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Tom St Denis)
Re: Is there any keyed MD5 or Blowfish encryption software out there? (Tom St Denis)
Re: Signature size ("Michael Scott")
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: Any products using Rijndael? (Tom St Denis)
Re: Advanced Encryption Standard - winner is Rijndael (Tom St Denis)
Re: It's Rijndael (Tom St Denis)
Re: Requirements of AES (Tom St Denis)
Re: AES Rijndael 9 Round not secure ? (David Crick)
key management on static system ("Jason R. Coombs")
Re: Shareware Protection Schemes (Ichinin)
Re: Advanced Encryption Standard - winner is Rijndael (Jim Gillogly)
Re: It's Rijndael (David Crick)
Authenticating a PIN Without Compromising the PIN (Guy Lancaster)
Re: Shareware Protection Schemes (Mike Rosing)
Re: NIST Statistical Test Suite (Mok-Kong Shen)
Re: is NIST just nuts? (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Is there any keyed MD5 or Blowfish encryption software out there?
Date: Tue, 03 Oct 2000 16:55:58 GMT
Reply-To: [EMAIL PROTECTED]
Hello,
Your help is MUCH appreciated... I'm looking for a DLL, Active-X control
or .Bas module that implements a Keyed MD5 scheme which can be used
outside of the US too. I am using vb on the front end and Unix/C
on the back end so it must be implemented in both Unix/C and VB so that
I can encrypt and decrypt strings to and from eachother.
So far I have searched the web and have come up with nothing that :
1) Has both a VB and C/Unix implementation
2) Can take in a Key for encrypting/decrypting
3) Can be used outside of the US also (I hear that if the control
implements DES also, you are considered an arms dealer if you export it)
Thanks in Advance,
Scott
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Tue, 03 Oct 2000 16:56:30 GMT
In article <[EMAIL PROTECTED]>,
Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > Yeah, but given all our advances in crypto we can barely break 9
rounds
> > of Serpent because it was designed to resist these attacks.
Rijndael
> > suffers 8 of 10 rounds.
>
> The Counterpane paper describes an attack on 7 rounds, which they seem
> to indicate is not practical: it uses 2^128 known texts, i.e. the
entire
> codebook, 2^120 work and 2^64 bits of memory. This is an interesting
> attack and result, but it's obviously completely academic, and I
wouldn't
> consider it a break of 7-round Rijndael. They do not (yet) extend the
> 7-round attack to an 8-round attack: at that point they move to the
> longer key sizes.
I never said the attack could be used. In 1977 searching a 56-bit key
space was academic too.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Looking Closely at Rijndael, the new AES
Date: Tue, 03 Oct 2000 16:59:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (John Savard) wrote in
> <[EMAIL PROTECTED]>:
>
> >I hadn't really made up my mind about Rijndael.
> >
> >Given comments made about its security, I tended to be somewhat
> >dismayed that security didn't play a larger role in the selection
> >process, but since from the outset efficiency and speed were known to
> >play a large role in the selection, Rijndael seems to be the proper
> >winner.
> >
>
> As much as I bad mouth the whole AES effort. I have tried to think
> what I would do if I was to judge a cipher for the specifacations
listed.
> I don't think any small fast cipher can really be secure but I think
the
> security part has to be judged from two points of view. One does any
one
> have a reasonable break for the whole cipher. That being done, You
treat
> all the reamaing as at the same security level. Which of course is
unture
> but one should not speculate the order in which they will be broken
since
> they all will. If and when it gets easily broken you run another
contest.
> But of those that pass the so called security checks. You then go to
> the one that is cheapest to impliment in the wide variety of uses
that
> cipher was meant for. After all only a small degree of security is
needed.
> One can't prove how secure each of these ciphers are to each other.
You
> only get a real measure if one is broken at which point you throw
that
> cipher out.
> This was intended for commerical use. These ciphers should not be
used
> by any one who wants private truely secure encryption. For example the
> governement will not allow it for anything but sensitive info. They
will
> not use it for secret info and you should not either. But hopefully it
> is good enough so that no 14 year old hacker can easily break it with
> his home computer in the next 20 years.
> One should keep in mind the specification are such that if the NSA
> has decent quantum computers. It is likely only a few blocks of data
> would be needed such that in most cases only one solution could be
backed
> out. I don't think we will see 14 year olds with large quatum compters
> in the next 20 years. But who knows.
Why can't a fast cipher be secure? Fast is very subjective. I could
implement Scottu19 in hardware (tons of ram) and be faster then
Blowfish in software. Then Scottu19 is bad because it's fast?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,alt.security.scramdisk
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: Tue, 03 Oct 2000 17:03:19 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Rich Wales) wrote:
> "pgp651" wrote:
>
> > Mr. Zimmermann, Mr. Price when can we expect this feature?
> > After RSA patent hoopla is over, isn't now the time to
> > implement 4k RSA keys into PGP v262?
>
> I don't work for NAI and can't speak for them, but I wouldn't hold my
> breath waiting for NAI to release =any= updates to PGP 2.6.2. This
> version of PGP is over four years old, and (for better or worse) they
> have gone on to newer versions.
>
> If anyone is going to modify PGP 2.6.2 (or, more appropriately, the
> bug-fixed international version, 2.6.3ia) to accommodate larger keys,
> it will presumably be a third party not connected to NAI. Actually,
> I believe some groups have already done this. Have you checked out
> the CKT version, for example?
Why the hell would you use a RSA key over 1024 bits anyways?
Are people plain stupid, paranoid or know something I dont?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is there any keyed MD5 or Blowfish encryption software out there?
Date: Tue, 03 Oct 2000 17:02:14 GMT
In article <8rd32r$1d8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hello,
>
> Your help is MUCH appreciated... I'm looking for a DLL, Active-X
control
> or .Bas module that implements a Keyed MD5 scheme which can be used
> outside of the US too. I am using vb on the front end and Unix/C
> on the back end so it must be implemented in both Unix/C and VB so
that
> I can encrypt and decrypt strings to and from eachother.
MD5 is not techincally a cipher. Are you using MD5 has a stream
cipher, a block cipher or a hash?
> So far I have searched the web and have come up with nothing that :
>
> 1) Has both a VB and C/Unix implementation
> 2) Can take in a Key for encrypting/decrypting
> 3) Can be used outside of the US also (I hear that if the control
> implements DES also, you are considered an arms dealer if you export
it)
>
What do you want with MD5?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Signature size
Date: Tue, 3 Oct 2000 18:13:43 +0100
See "Signing on a Postcard", by Nacche & Stern
"We investigate the problem of signing short messages using a scheme that
minimizes the total length of the original message and the appended
signature............................ Using further optimizations we
can lower the scheme's overhead to 26 bytes for a 2-80 security level,
compared to forty bytes for DSA and ECDSA and 128 bytes 1024-bit RSA. "
See http://www.manta.ieee.org/groups/1363/Research/Schemes.html
<[EMAIL PROTECTED]> wrote in message news:8ralqb$2l6$[EMAIL PROTECTED]...
>
> > The mathematical problem is different. The amount of work you need
> to do
> > to crack 170 bit ECC problem is about the same (but not really -
> there's
> > lots of details I'm leaving out) as the work you need to do to crack
> 1024 bit
> > RSA problem. You need to learn a lot of math to understand why.
>
> I understand that ;-) I was just wondering because ECDSS signatures are
> 2x160=320 bits long and it is claimed on
> http://www.certicom.com/research/wecc2.html that digital signatures
> using ECC are 320 bits long for messages longer than 2000 bits (with
> security comparable to RSA 1024 bit).
>
> So my questions are:
>
> How can I achieve shorter signatures when the messages are shorter?
>
> How can I achieve a a 160/170 bit signature using ECC signature
> algorithms? (Answer seems to be ECC ElGamal)
>
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Tue, 03 Oct 2000 19:18:55 +0200
[EMAIL PROTECTED] (DJohn37050) wrote:
> The MOST info about an RSA key is revealed when using 2 or 3 for the
> public exponent. For example, 1/2 the high order bits of d (the private
> exponent) are revealed.
Quite an interesting remark. Can the amount of information leaked
on d be quantified as a function of e, to weight the justification
of e=2^16+1 rather than e=3 on these grounds ?
> and the fact that the key space of all possible primes of the right
> size is reduced by the gcd req.
this at most 2 bits of info for e=3; no big deal IMHO.
> By the nature of RSA, it is concievable that low exponent RSA could
> be insecure but high exponent RSA be secure.
I think this applies to odd e only; for even e, Bellare and Rogaway have
signatures schemes provably as secure as factoring under the random oracle
model, right ?
> Dan Boneh has a paper discussing this.
Is this Ref[2] or another paper ?
Francois Grieu
[2] Dan Boneh, Ramarathnam Venkatesan: Breaking RSA May Be
Easier Than Factoring
<http://crypto.stanford.edu/~dabo/papers/no_rsa_red.pdf>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Any products using Rijndael?
Date: Tue, 03 Oct 2000 17:11:57 GMT
In article <8rctk6$9na$[EMAIL PROTECTED]>,
"Jeff Moser" <[EMAIL PROTECTED]> wrote:
> > So because it uses AES it must be a good tool right?
> >
> > See: It's starting already. People are buzzing towards AES.
>
> Ah, c'mon.. if it's "buzzword compliant", it must be secure :-)
I heard that trimming the DES key from 112 bits to 56 was ok... cause
nobody can guess a 56 bit key in 10 quadrillion billion years. And
that DVD CSS is really secure it's just Johansen that is some math
devil that undid the splendid work...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 17:10:23 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (Jeff Moser) wrote in
> <8rcrtl$90p$[EMAIL PROTECTED]>:
>
> >> Not really. If they want a real contest. Make a 10k doucument
> >> encrypted with a secret key. And offer someone 10 million dollars
> >> state and federal government tax fee if they can decrypt it
> >> it in a years time. Will they do that. Hell no someone might
> >> break it. And they don't want anyone to break it.
> >
> >If you're smart enough to break the cipher, you sure as hell wouldn't
> >take the 10 million. That is peanuts compared to what you could make
if
> >you knew that you could break all "secure" documents of the future
for
> >~20 years.
> >
> >Jeff
> >
> >
> >
>
> That is your guess. I think someone smart enough to break the cipher
> would take the 10 million. Becasue once it gets out how it was done
> you may not make a dime. There is also the chance you could be
teminated
> by some accident arranged by a 3 letter agency. So taking the money
> with everyone aware may be the safest option.
What if the attack is private and I can steal debit PIN's for the next
10 years....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 17:18:05 GMT
In article <8rd3ad$s25$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jonathan Thornburg) wrote:
> In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]>
wrote:
> [[many clear and cogent remarks with which I quite agree]]
> >suppose Serpent
> >had been chosen, with its perceived high security margin. If the
> >rounds were doubled, it would have an even higher security margin.
> >If they were doubled again, it would be higher still. Would this
> >make you more comfortable with it? After all, security is the
> >most important criterion (I agree with this), and adding rounds
> >makes it harder. At some point you <have> to trade efficiency
> >against your perceived security margin. The only argument we
> >can reasonably have is how high a security margin is enough.
>
> Another interesting design point is 3AES = 3Rijndael, done just the
> same way people do encrypt/decrypt/encrypt 3DES to get extra security
> from DES. Judging from the DES experience, if this is done carefully
[*]
> it gives a big boost in security, roughly squaring the work factor for
> the best known breaks. It has the advantage that it can exploit the
> many ultra-optimized Rijndael implementations (tuned software, special
> hardware complete with NSA backdoors^W^W^W^W, etc etc) which will no
> doubt appear.
Now you're being a complete idiot. AES is supposed to be more secure
then 3DES. So if Rijndael is not secure then why pick it and use
3Rijndael over say 1Serpent or 1Twofish.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Requirements of AES
Date: Tue, 03 Oct 2000 17:16:35 GMT
In article <[EMAIL PROTECTED]>,
Mike Connell <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> writes:
>
> my $0.02, IMHO, IANAL, etc. etc... ;)
>
> With just a cursory look over a random selection of documents on the
> AES pages, I feel compelled to share my nearly groundless
opinion ;)...
Do you know what a block cipher is? Do you know the attacks? Do you
know how they are used? Your opinion is not groundless.
While I never claim to be a crypto-know-all I certainly can provide
argument against Rijndael.
> > Given that security is the MOST IMPORTANT requirement and
versatility
> > is the second most important criteria I think Twofish or Serpent
should
> > have won over Rijndael.
> >
>
> FWIW, I was expecting Serpent to win - fast in hardware, not so fast
> in software, but I assumed that wouldn't carry so much weight on the
> assumption of Moore's law holding. Most important of all - serpent
> seemed really solid and secure. I could have had a nice warm fuzzy
> feeling using it (albiet a little slowly ;), based upon the trust of
> the security.
Bingo. Serpent should have win, or at least Twofish.
> > Does it matter how fast the cipher is if it's not secure? Now right
> > now Rijndael is secure, but it has had the most number of rounds
broken
> > compared to the other ciphers. While that's not a definate saying
it
> > is an indication of the ability for people to attack it.
> >
> > I hope people just disregard AES and pick the ciphers they know are
> > better.
> >
> > Tom
>
> It would seem to be a hard choice for the paranoid. On one hand,
> Serpent (or maybe Twofish ;) seems more secure (albeit technically),
> but OTOH, Rijndael is going to be getting most (if not all) of the
> attention as the winner. Should I go with what seems to be more
> secure, but has less analysis, or go with what may appear to be less
> secure?
Well Twofish has had alot of attraction. There was a $10K challenge to
break it, and it's been in the press for four years (or was it two?).
So it's not a relatively new cipher as compared to Rijndael.` Sure
Rijndael is based on an older square design, but Twofish is based on a
Feistel Network and Serpent on simple sboxes+linear transform. No new
tricks here.
> All in all, I'm a little dissapointed. I am missing the "warm fuzzy
> feeling" that I was hoping for...
Same here.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: AES Rijndael 9 Round not secure ?
Date: Tue, 03 Oct 2000 18:34:52 +0100
Martin Miller wrote:
>
> Hi!
>
> I'm really not an expert, but this paper describe a cryptanalysis of
> Rijndael for 6,7,8 and a key attack that can break 9 round rijndael...
>
> Should I be worried? (Well I am, but ;-)
>
> http://www.counterpane.com/rijndael.ps.zip
>
> I would like to hear some comments, since I did not see comments here
> about it and I think that would be of interest to some of you here ;-)
The 9 round break is for 256-bit keys, which runs with 14 rounds.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: "Jason R. Coombs" <[EMAIL PROTECTED]>
Subject: key management on static system
Date: Tue, 3 Oct 2000 11:38:04 -0600
I've read high and low. I've read the HAC regarding key management, I've
read through this newsgroup, and I don't see how to address my issue. I
suspect it's either an impossible problem or an unsolved problem. In any
case, here it is.
We have a software system that we wish to distribute on a CD. It has a
database that's potentially fairly large. This database contains
highly-propriatary information, and so must be protected with very good
secrecy. So, I see before me many cryptographic algorithms, but all require
some sort of password or secret key.
Our difficulty lies in that we would like to distribute this key on the CD,
but have it more-or-less inaccessible to anyone but the program. Is there a
well-known mechanism for protecting such a key?
Perhaps better would be to ask how systems such the OS protect the keys to
the encrypted file system... or how they protect the user's private keys. I
believe I essentially want to solve the same problem.
Any direction is appreciated.
Jason
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Shareware Protection Schemes
Date: Tue, 03 Oct 2000 07:37:57 +0200
Darren New wrote:
>
> Ichinin wrote:
> > - What would stop anyone from distributing the software WITH
> > a (stolen or compromised) legitemate key?
>
> I saw an interesting mechanism once that just put the credit card number
> used to pay for the software into the "About" box. Encrypted in the
> executable, of course.
How does it work? Does it have a PK that encrypts Name+CC
number, ships it to the manufactorer, which returns a
valid key?
That could work.
But then - there is CC fraud to worry about.
/Ichinin
(I saw such a standalone software too, i broke it
for the fun of it = Meaning there is a need for
such a tool with better encryption; if i can break
it - anyone can!)
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Tue, 03 Oct 2000 17:42:08 +0000
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> > [EMAIL PROTECTED] (Jeff Moser) wrote in
> > <8rcrtl$90p$[EMAIL PROTECTED]>:
> > >
> > >If you're smart enough to break the cipher, you sure as hell wouldn't
> > >take the 10 million. That is peanuts compared to what you could make if
> > >you knew that you could break all "secure" documents of the future
> > >for ~20 years.
> > That is your guess. I think someone smart enough to break the cipher
> > would take the 10 million. Becasue once it gets out how it was done
> > you may not make a dime. There is also the chance you could be
> teminated
> > by some accident arranged by a 3 letter agency. So taking the money
> > with everyone aware may be the safest option.
>
> What if the attack is private and I can steal debit PIN's for the next
> 10 years....
Some of us would rather have $10M legally than steal $10B, even if there's
no risk. Not only would I take it, I'd even pay taxes on it -- whatever
didn't go to charity. I agree with Scott this time. (!)
--
Jim Gillogly
Hevensday, 12 Winterfilth S.R. 2000, 17:36
12.19.7.10.16, 12 Cib 19 Chen, Ninth Lord of Night
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 03 Oct 2000 18:44:55 +0100
lcs Mixmaster Remailer wrote:
[..]
> Rijndael appears to be a compromise between security and efficiency.
> This leaves us in an unhappy and uncomfortable position. It may well be
> that Twofish and perhaps Serpent continue to be widely used alternatives
> to AES.
Assuming you don't want to interact with the US Government, you
and your parties may use whatever crypto you feel safe with.
And if you require a FIPS, 3DES is and will be available to you.
--
+-------------------------------------------------------------------+
| David A. Crick <[EMAIL PROTECTED]> PGP: (OCT-2000 KEY) 0xE0F73D98 |
| Damon Hill Tribute Site: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
+-------------------------------------------------------------------+
------------------------------
From: Guy Lancaster <[EMAIL PROTECTED]>
Subject: Authenticating a PIN Without Compromising the PIN
Date: Tue, 03 Oct 2000 17:52:44 GMT
If it's possible, how could a protocol authenticate a user's
PIN without revealing information that would make it
relatively easy to determine the actual PIN value?
PINs are commonly used to authenticate users of trusted
machines but is there any way that they can be secure for
use over untrusted networks? I'm beginning to think that
the answer is no.
Here's a scenario. We want to allow authorized users of a
service to access that service over an untrusted network
such as the Internet. We provide a small device that can
connect via this network. These devices are not keyed
to specific users and are readily accessible. Our server
needs to authenticate the user but we cannot guarantee that
the connection won't get redirected by a third party to
another server for the purposes of gaining unauthorized
access to our system. Thus our device needs to provide
information that allows us to authenticate the user but
does not allow an attacker's server to be able to determine
the shared secrets.
The problem is that PINs must be short (i.e. a few digits)
which makes it all too easy for a computer to exhaustively
search for the correct value given sufficient information to
know when it has the correct value. I can find no way of
authenticating a PIN without revealing enough information to
crack it. Am I wrong?
Guy
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Shareware Protection Schemes
Date: Tue, 03 Oct 2000 13:01:57 -0500
musashi_x wrote:
> Actually my original thought was that I would separate the first 7
> characters (yeah, bad phrasing, this isn't a pub/private key system) of
> *the* key. Once reajoined with the key that I send the person (through a
> Help/Register Box), it would unlock the extra features.
> They could just cut and paste the key from e-mail, and it would only work
> for their copy. I've really been getting helpful responses about possible
> flaws in my logic, which was what I was looking for (there's ALWAYS
> something ya didn't think of). Really, I don't expect this to be an
> impenetrable defense, I would just like it to be harder than the average
> protection to patch and to eliminate serial number distribution. By making
> every copy a slightly different length, wouldn't that make it very difficult
> to distribute a patch for it?
As long as you recognize it can be bypassed, you can create a registration
system which allows your software to be shared, and to work with expanded
capabilities when registered, and not have fake registrations. You build
a public key system into your code, along with your public key. When
a user registers, they create a passphrase/password which gets hashed into
their private key. They send you a public key based on this, along with
their encrypted registration information (like username, stuff they want
turned on, and any other check data you want to include). All that is
automatic, the user doesn't have to type anything.
The key used is the Diffie-Hellman key based on their private key and your
public key, which is equal to your private key and their public key. You can
encrypt any data you like and store it on the users system. The only way
to unlock it is with the users password/passphrase and your public key.
The only way to figure out what is inside the encrypted data is to first
register. The warez guyz will just put in jmp instructions and bypass
all this stuff, but you don't care. You can't get support unless you are
registered.
For mind numbing details and code, send me e-mail: [EMAIL PROTECTED]
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: Tue, 03 Oct 2000 20:15:48 +0200
[EMAIL PROTECTED] wrote:
>
> Has anyone got code for the function erfc() that i could include in the
> software as this function does not seem to be available when using
> Visual C++ 6.0.
There is code on p.551 of
H. K. Lau, A numerical library in C for scientists
and engineers. CRC, 1995.
The code computes erf and erfc simultaneously. Maybe
you have to adapt it to the needs of the NIST package.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Tue, 03 Oct 2000 18:02:16 +0000
Tom St Denis wrote (about the Counterpane attack on Rijndael):
> I never said the attack could be used. In 1977 searching a 56-bit key
> space was academic too.
It's not the same situation. In 1977 it was clear (at least to Diffie
and Hellman and to those of us who were convinced by their paper) that
DES would soon be vulnerable to a specific known attack, i.e. key
exhaustion, and it was simply a matter of spending a lot of money to
build a machine that could execute it -- a real machine that could be
built in our universe.
With Rijndael, we don't yet see any specific exploitable weakness.
There's less of a perceived security margin than with some of the
other candidates, but no known weakness that can obviously be converted
into a crack given a feasible expenditure of resources.
The NSA apparently designs even closer to the margin: the best known
attacks by academics on Skipjack just barely miss being able to reduce
the work factor below brute force keysearch. By that standard having
a security headroom of 4 out of 10 rounds above the best nearly
practical attack seems generous.
--
Jim Gillogly
Hevensday, 12 Winterfilth S.R. 2000, 17:49
12.19.7.10.16, 12 Cib 19 Chen, Ninth Lord of Night
------------------------------
** 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
******************************
