Cryptography-Digest Digest #145, Volume #11      Thu, 17 Feb 00 20:13:01 EST

Contents:
  Re: NTRU Speed Claims (100x faster, etc.), explained (John Myre)
  Re: Does the NSA have ALL Possible PGP keys? ("Douglas A. Gwyn")
  Re: Does the NSA have ALL Possible PGP keys? ("Douglas A. Gwyn")
  Re: EOF in cipher??? ("Douglas A. Gwyn")
  Re: Question about OTPs - Newbie question added ("Douglas A. Gwyn")
  Re: Question about OTPs ("Douglas A. Gwyn")
  Re: NIST, AES at RSA conference (David Wagner)
  Re: UK publishes 'impossible' decryption law (zapzing)
  Re: Keys & Passwords. (Mok-Kong Shen)
  Re: EOF in cipher??? (lordcow77)
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) ([EMAIL PROTECTED])
  Re: NIST, AES at RSA conference (John Savard)
  Re: Method to break triple-DES (John Savard)
  Re: Method to break triple-DES (Johnny Bravo)
  Re: RSA Speed (Erik)
  Re: RSA Speed (Erik)
  Re: Method to break triple-DES (Mickey McInnis)
  Re: Does the NSA have ALL Possible PGP keys? (Hex)
  Re: Does the NSA have ALL Possible PGP keys? (Hex)
  Re: VB & Crypto (Khalil Haddad)
  Re: I, William A. Nelson, created and utilized the cyberspace character of Markku J. 
Saarelainen for many international business purposes  ("Dave Francis")
  Re: VB & Crypto ("Wilton")
  Re: VB & Crypto (Peter Rabbit)

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

From: John Myre <[EMAIL PROTECTED]>
Subject: Re: NTRU Speed Claims (100x faster, etc.), explained
Date: Thu, 17 Feb 2000 14:05:25 -0700


David Wagner wrote:
> 
> NTRU looks intriguing.  And there are some very interesting academic
> papers on the subject.  It might even be a better, faster, and
> more secure public key cryptosystem.  If it is, I want to use it!

In regards to NTRU's suitability for use, is it correct to say
that it expands the plaintext significantly?  That is, the plaintext
is a sequence of N values, each modulo p ("the small modulus").
The ciphertext is also a sequence of N values, but they are modulo
q ("the large modulus").  This means that the data has expanded
by log(q)/log(p).  In their example parameter sets, we have:

                           (expansion)    plain  cipher
   security   N    q   p   log(q)/log(p)  bits    bits
   ----------------------------------------------------
   moderate  107   64  3       3.8         170    642
   high      167  128  3       4.4         265   1169
   highest   503  256  3       5.0         797   4024

(approximately)

I suppose if we are just trying to exchange session keys, then
this doesn't matter, since the plaintext is small, anyway.
(And RSA, et al., also have a minimum message size, which
seems comparable to the numbers above).

Are there cases where we want to encrypt larger data?

John M.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 21:31:52 GMT

David Hopwood wrote:
> "Douglas A. Gwyn" wrote:
> > Be careful when you say such things -- the security of any actual
> > instance of a cryptosystem cannot be based on "NP-Hard"ness.
> It is still an open question whether it is possible to construct a
> cryptosystem for which almost all cases are effectively "as hard as"
> the worst case.

That's not an open question, nor even a sufficiently exact
question.  It is *certainly* possible to create a encryption
algorithm where, with the missing assumptions supplied such
as: random unknown key, random choice of PT from known parent
population, etc. there is no substantially better way to find
the PT than by brute-force key search, which provides an upper
bound for any specific case.  Whether an *entire cryptosystem*
is secure requires that a lot more be considered than just the
encryption algorithm.  But that wasn't my point.

> OTOH, AFAIK no existing secure cryptosystem is based on an NP-hard
> problem.

I doesn't matter whether one is "based on a ... problem" or not,
that's not what I said.  I said the *security* cannot be based
on "NP-Hard"ness.  "NP-Hard" does not apply to a single instance
of a problem, but rather to an open-ended infinite class of a
parameterized problem.  No instance of a cryptosystem is a class.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 21:36:03 GMT

tiwolf wrote:
> Now Johnny who is blatant stupidity, you claim that even God does not know
> what the highest number is. Given that God is created all things in the
> universe, and inspired human creativity and invention, how can you say that
> God does not know what the highest number is. That would be an indication of
> limit and according to the philosophical debate and my religious up bringing
> God is limitless in power and knowledge.

This supposed to be a *science* newsgroup, not a *superstition*
newsgroup.  It is easy to prove that there is no limit to the
size of an integer, with the usual mathematical meaning for the
term.  Similarly, there is no largest prime (different proof).
If you simply reject all such proofs, preferring to override
them with unfounded beliefs, you're being irrational and should
stop posting your delusions here.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 17 Feb 2000 21:44:01 GMT

JPeschel wrote:
> And use FEOF to detect the end of the binary file being read.

I think you mean the feof function.
That isn't necessary (except in an implementation that has made
an extremely perverted choice of sizes for the basic integer types);
testing the int returned from getc agaisnt EOF works properly even
for binary streams.  Of course, if you *miscode* your program,
using a char to hold the return valur of getc, it could malfunction,
but if you code it properly there is no problem.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs - Newbie question added
Date: Thu, 17 Feb 2000 21:48:15 GMT

ink wrote:
> Can you point me in a direction where I can find a description
> of such a test?

The Kappa test is described in Kahn's "The Codebreakers" (hardcover
edition), and also in the MilCryp textbooks.

> How do you determine "probable plaintext"?

Pieces of plaintext that have a fair chance of occuring within
the original message.  Also known as probable cribs.

Read the sci.crypt FAQ, and if there are further questions,
read cryptanalysis texts mentioned therein.

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 21:50:56 GMT

Dave Hazelwood wrote:
> Surely you mean never reuse a byte "sequence" as opposed to "no"
> byte?

He means "no byte of the OTP data".  NOT "no byte *value* found
in the OTP data".  When we say that a file contains 2MB, we don't
mean that it contains 2M distinct byte *values*.

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

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: NIST, AES at RSA conference
Date: 17 Feb 2000 13:26:38 -0800

In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> You have it backwards. Terry Ritter is suggesting using a pool of
> ciphers, and adding triple encryption to that as a safety precaution
> to fix the weakest link problem, not the other way around.
> 
> Subject to certain precautions, triple encryption can be expected to
> be as strong as the strongest of the three ciphers used (so the 3rd
> weakest one in the pool is the worst case) and hoped to be
> considerably stronger.

Ok.  But increasing pool size does make the "weakest link" problem worse,
whether or not you triple the ciphers, so it's not clear to me that tripling
really helps all that much to address the concern.  (And, to me, 3rd weakest
doesn't sound all that much better than weakest...)

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

From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: UK publishes 'impossible' decryption law
Date: Thu, 17 Feb 2000 21:57:55 GMT

In article <888ujl$mro$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Geoff Lane) wrote:
> In article <884m8a$m2i$[EMAIL PROTECTED]>,
>       zapzing <[EMAIL PROTECTED]> writes:
> > *How*, after all, would the
> > police be able to tell an encrypted file
> > from random numbers, anyway, and if the
> > accused must *prove* his innocence, then
> > how would he prove that they were random
> > numbers and not an encrypted file?
>
> This is of course the killer.
>
> Plus, the recent Scottish  case where it was ruled that
> non-self-incrimination is still a valid reason to keep your mouth shut means
> that you can keep the keys to yourself and the courts cannot hold it against
> you.
>
> Major parts of the proposed legislation would be knocked down the first time
> a case was taken to a superior eu court.
>
> --
> Geoff. Lane.   |   Today's target: 47.639963 N; 122.130295 W. Fire at Will!!
>
> Misspelled?  Impossible.  My modem is error correcting.
>

Obviously there is alot I don't know about English law.
I thought you did not *have* the right to remain silent
in England. And you can appeal to EU courts now?
Interesting.
--
Do as thou thinkest best.


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Keys & Passwords.
Date: Thu, 17 Feb 2000 23:15:05 +0100

John wrote:
> 
> This may be a stupid question.  Let's assume, for the sake of
> argument, we have found a good encrypter.  How important is the
> choice of a password?  I have often heard that if you had a
> password like athxa or bthxb, it is not good because there is
> repitition.

Not seldom one is limited to the input of maximal 8 characters. 
I prefer to use in that case 8 characters from the set {a-z, 0-9},
determined mechanically (in a rather inelegant way). But the problem 
is that there is some probability that one forgets such sequences. 
So I keep a secure copy for the eventual worst case. This is 
certainly far from ideal. Does someone know a better solution?

M. K. Shen

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

Subject: Re: EOF in cipher???
From: lordcow77 <[EMAIL PROTECTED]>
Date: Thu, 17 Feb 2000 14:14:47 -0800

According to POSIX,
fopen("foo","t")
must be identical to
fopen("foo","b"),
so if you're programming on a UNIXy enough system, it shouldn't
matter how you open the stream as long as you're consistent.


* 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: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Funniest thing I've seen in ages - RSA.COM hacked :)
Date: Thu, 17 Feb 2000 18:11:36 GMT

In article <88bncu$e4o$[EMAIL PROTECTED]>,
  Bob Silverman <[EMAIL PROTECTED]> wrote:
> Note the date!  RSA Security changed its name in fall of 1999.
> The database is out of date!


The most damning part of this thread appears to be in the next thread
(on my screen anyway) Sorry to be verbose, but here's a cut'n'paste...

<<<
Subject:  RSA Cryptography Today FAQ (1/1)
Date:     15 Feb 2000 12:06:01 GMT
From:     [EMAIL PROTECTED]
Organization:  RSA Data Security, Inc.
Newsgroups: sci.crypt, talk.politics.crypto, alt.security.ripem,
sci.answers, talk.answers, alt.answers, news.answers
Followup-To:  poster




Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21


An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997.  These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them.  While we hope the
information
in our FAQ is useful, the version that was being posted here was quite
outdated.  The latest version of the FAQ is more complete and
up-to-date.

Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content.  Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.

RSA Labs FAQ Editor
[EMAIL PROTECTED]

>>>



So, it appears to be a classic case of left hand right hand syndrome.
Or arse elbow syndrome as we Brits would say.

Please do let us know how many heads roll...


Phil


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 17 Feb 2000 15:23:09 GMT

[EMAIL PROTECTED] (David Wagner) wrote, in part:

>Ok.  But increasing pool size does make the "weakest link" problem worse,
>whether or not you triple the ciphers, so it's not clear to me that tripling
>really helps all that much to address the concern.  (And, to me, 3rd weakest
>doesn't sound all that much better than weakest...)

Which is why I made a suggestion that (it seemed to me) Terry Ritter
did not consider was terribly useful: that one should have an option
of constraining the cipher choice, so that at least one of the ciphers
used must come from a "highly trusted" smaller pool (i.e., one's
favorites among the AES candidates) while others come from a broader
range - combining the benefits hoped for with reduced risks.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Method to break triple-DES
Date: Thu, 17 Feb 2000 15:17:29 GMT

[EMAIL PROTECTED] (Mickey McInnis) wrote, in part:

>Actually, I've heard that there was a paper published recently showing
>a potentially practical attack on Triple DES that's considerably less
>effort than standard key exhaustion against a 112 bit (2xDES) key.
>It's some sort of meet-in-the middle attack, and was not too many times
>more trials than regular DES by key exhaustion.

>If true, and if I recall correctly, it did sound like Triple DES was
>significantly less secure than previously thought.

>Unfortunately, I don't have a reference.  I think it was in the last year
>or so that I saw it mentioned, probably on this newsgroup.

Even so, it wouldn't quite qualify as an "implementation" - that is,
if implemented, it probably wouldn't be practical. But this is very
interesting to hear about, although I'm a bit surprised - I would
think that if that had happened, it would be quite big news.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Method to break triple-DES
Date: Thu, 17 Feb 2000 16:51:27 +0000

On 17 Feb 2000 20:32:40 GMT, [EMAIL PROTECTED] (Mickey
McInnis) wrote:

>Actually, I've heard that there was a paper published recently showing
>a potentially practical attack on Triple DES that's considerably less
>effort than standard key exhaustion against a 112 bit (2xDES) key.
>It's some sort of meet-in-the middle attack, and was not too many times
>more trials than regular DES by key exhaustion.

  I've seen the paper (somewhere, I cruise from link to link and don't
bookmark often. :)  The problem with this attack is that you need known
plaintext, 448 million gigabytes of memory and 2^113 operations.

-- 
  Best Wishes,
    Johnny Bravo

"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL

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

From: Erik <[EMAIL PROTECTED]>
Subject: Re: RSA Speed
Date: Thu, 17 Feb 2000 17:34:22 -0500

Doug Stell wrote:
> Now, you should investigate faster implementations to get both times
> down. The HAC will give you lots of good algorithms and existing large
> integer libraries will give you good implementation ideas. Mongomery
> multiplication is probably your best choice to use in the
> exponentiation. Once you get a fast math library in place, C.R.T. will
> knock the private key computation down by a factor of about 4.
> 
> doug

Thanks.  After I improved my multiplication routine and implemented
Montgomery multiplication, it came down to around 2 seconds.  But how do
you use the C.R.T?  AC gives an algorithm for it, but doesn't explain
how to use it to find C^d mod n.

Erik

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

From: Erik <[EMAIL PROTECTED]>
Subject: Re: RSA Speed
Date: Thu, 17 Feb 2000 17:36:53 -0500

Tom St Denis wrote:
> 
> In article <[EMAIL PROTECTED]>,
>   Erik <[EMAIL PROTECTED]> wrote:
> > I wrote a program to do RSA with a 1100 bit modulus.  I use 65537 for
> > the public key exponent, and the private key exponent is, of course,
> > near 1100 bits.  It works, and encrypting with the public key takes
> > about a quarter of a second, but decrypting with the private key takes
> > 43 seconds on a 400 MHz Pentium.  Does this seem right?
> >
> 
> With a moduli that size decryption should take at most 5 seconds on
> that type of cpu.  What large integer package are you using?  If it's a
> homebrew maybe it's not optimal?

You were right, my multiplication routine was the main problem.  It's
probably still not optimal, but after fixing that and using Montgomery
multiplication in my tothemod routine, I'm down to about 2 seconds.

Erik

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

From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: Method to break triple-DES
Date: 17 Feb 2000 23:07:16 GMT
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]>, Johnny Bravo 
<[EMAIL PROTECTED]> writes:
|> On 17 Feb 2000 20:32:40 GMT, [EMAIL PROTECTED] (Mickey
|> McInnis) wrote:
|>
|> >Actually, I've heard that there was a paper published recently showing
|> >a potentially practical attack on Triple DES that's considerably less
|> >effort than standard key exhaustion against a 112 bit (2xDES) key.
|> >It's some sort of meet-in-the middle attack, and was not too many times
|> >more trials than regular DES by key exhaustion.
|>
|>   I've seen the paper (somewhere, I cruise from link to link and don't
|> bookmark often. :)  The problem with this attack is that you need known
|> plaintext, 448 million gigabytes of memory and 2^113 operations.

That sounds much more difficult than the description I heard of, but since
I didn't pay that much attention to it, I can't be sure.  I think the
number or operations required was much less, in the range of 2**64 or
less.

My recollection is that it was something difficult and expensive, but
not completely beyond the realm of possibility for a government or
multinational company in the near future.

It wasn't a complete break, but an indication that Triple DES might
be considerably less strong than orignally thought.

|>
|> --
|>   Best Wishes,
|>     Johnny Bravo
|>
|> "The most merciful thing in the world, I think, is the inability
|> of the human mind to correlate all it's contents." - HPL

--
Mickey McInnis - [EMAIL PROTECTED]
--
All opinions expressed are my own opinions, not my company's opinions.

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

From: [EMAIL PROTECTED] (Hex)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 23:53:38 GMT


>Now Johnny who is blatant stupidity, you claim that even God does not know
>what the highest number is. Given that God is created all things in the
>universe, and inspired human creativity and invention, how can you say that
>God does not know what the highest number is. That would be an indication of
>limit and according to the philosophical debate and my religious up bringing
>God is limitless in power and knowledge.
>
I never thought I'd see such an old philosophical chestnut <the
problem of the stone - that is, can God create a stone so heavy that
even he can't lift it....> being invoked in a crypto newsgroup...

Ahh well. 
Philosophy IS everywhere...

Hex


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

From: [EMAIL PROTECTED] (Hex)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 23:59:57 GMT

As a follow up to this, there have been occasional mentions in the
press both throughout the Gulf conflict (not the Desert Storm one but
the later missile launches...) and during the Nato bombing of Kosovo
referring to interception and decryption of `bad guy' communications
by the allies. In some cases specific mention has been made of
`decryption' ...

[Sorry I can't provide citations right now...]

I'm curious, if PGP and similar widely available freeware and
commercial packages are so secure why aren't the Iraqis, Serbs, etc
etc using them? 

Of are they using them and we are still cracking them?

<Note that I a m not disuputing the mathematical evidence based on
estimates of decryption time based on current attacks on current
crypto algorithims -- but the question does remain whether unknown
techniques, mathematical techniques and so on exist...>

Hex



On Wed, 16 Feb 2000 00:24:06 GMT, [EMAIL PROTECTED] (Steve K)
wrote:

>I just read most of this thread, and it's a very silly thread.
>
>One side is saying, "I am as smart as any moneky in this tree, and I
>know for a fact that the bigger monkeys higher in the tree could beat
>yours or my ass any time they really wanted to.  Math?  What's that?
>Ook ook eek eek!"
>
>And the other monkeys are saying,  "vYlbBW FQ/9aTb XP2SCgxz TwOMVNFCW
>cn46471neY bnfMjPoniXT/ +Sv78VLmY8i Mk5h5so+LoXy2v eK+Ii6zdrooTqKM110
>nrd40yRSd ZYj3siucpL60 UfF5T+u5pz0UzS15c8 c1Ymc1+ULr4yJc+lrtifhTeT
>zDDWk9KVtQ Joszy2odeZxaK8OQiT3E h+tN 4Vm9L+C/ Xo8oWe Nya4uZ
>xcaVYa2X/QYG6 3HKzoY 2POzOjR WXbO MMUv3A3kmvk FCkYuqPniPW"
>
>Well actually, that is what the 1st monkey mentioned above sees and
>hears when the math is explained...
>
>In all fairness, it took a long time and a lot of study for me to
>decide that modern crypto is about as good as the experts say it is.
>After all, we're all monkeys in this tree, and I'm no exception.
>Until or unless a person does the homework, asking him or her to
>believe that a cipher is unbreakable (by a "fair" mathematical
>attack), is really too much.  It does not seem likely, on an intuitive
>basis.  Nobody who doesn't study up on the subject should believe in
>unbreakable ciphers.  So all I can add to the "debate" is a couple of
>suggestions:  
>
>To the folks who admit that they don't know anything about crypto, but
>insist that "The Government" can break any cipher if they really want
>to:  Consider that this is an opinion based on raw emotion, not
>knowlege, and that being so rigidly and publicly attached to it makes
>ya look kind of dumb.  Especially in a forum that's full of crypto
>geeks to begin with.
>
>To the crypto geeks:  Contemplate the sage advice of the great W.C.
>Fields on the subject of trying to wise certain people up.  Guys, it
>can't be done.  Either they get interested enough to study and the
>literature and follow the logic of it, or they don't.  You have
>practically no influence over that choice.
>
>:o)
>
>
>Steve
>
>---Continuing freedom of speech brought to you by---
>   http://www.eff.org/   http://www.epic.org/  
>               http://www.cdt.org/
>
>PGP key 0x5D016218
>All others have been revoked.


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

From: Khalil Haddad <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 01:21:07 +0100

Hello

I most agree on all your arguments ...
But my initial question was not wetherVB is good or not ... my soft is
currently in VB6 and I need a small and STRONG crypto algorithm to encrypt
very small text. I used RSA + RC4 but the code generated is too long and I
have some bugs ...

Could you post an URL where I could find sample code of blowfish or any
other nice crypto algorithm in VB?

Thanks

Khalil


mdc wrote:

> On Thu, 17 Feb 2000 12:53:37 +0100, Runu Knips
> <[EMAIL PROTECTED]> wrote:
>
> >Khalil Haddad schrieb:
> >> I am developping softwares in VB6 and would like to use strong
> >> encryption algorithms.
> >> Anyone could tell me where to find sources in VB so that I can study
> >> them.
> >
> >Ouch.
> >
> >Better use a .dll with C routines, if you can.
>
> I agree with this.  It's been my solution.
>
> >VB is not meant for any serious programming task, and I don't
> >think anyone has ever written a cryptographic software in VB.
>
> VB is great for some serious programming tasks and I have, in
> fact, done both Blowfish and SHA-1 in VB5.  They're excruciatingly
> slow, but that's to be expected.  I banged the code out quickly in
> VB for a prototype and converted to C DLLs for the real thing.
>
> >For example, VB doesn't have shift operations, does it ? And
> >its not very optimizing, so cryptography is slow with it.
>
> The main drawback with using VB is that is doesn't have unsigned
> integers.  You can use the Variant data type and overload integer
> functions like mod and hex.
>
> While I have to disagree with your broad generalization about VB,
> I certainly agree with your comment that it would be better to use
> C DLLs for crypto functions if only to increase performance.
>
> mdc


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

Reply-To: "Dave Francis" <[EMAIL PROTECTED]>
From: "Dave Francis" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.politics.org.cia,soc.culture.russian,soc.culture.soviet,soc.culture.israel,soc.culture.europe,soc.culture.nordic,alt.2600
Subject: Re: I, William A. Nelson, created and utilized the cyberspace character of 
Markku J. Saarelainen for many international business purposes 
Date: Fri, 18 Feb 2000 00:35:36 GMT

OK, now you have screwed up!  This cat pissed me off bad by some of the shit
he said.  He is dead!

Dave


--

[EMAIL PROTECTED] (Email Address)

http://www.angelfire.com/tx2/candyman (Web Page)

503/905-6832 (Fax Number)

"William A. Nelson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> I, William A. Nelson, created the character of Markku J. Saarelainen.
> During the utilization of this unreal cyberspace character, many people
> attacked the character and several information security experts started
> arguing with it - and  these people mailed many aggressive messages to
> the email address that was set up for the unreal Internet character. As
> it turns out the real character of this Markku J. Saarelainen (the
> stolen identity) is actually a small black cat. I have attached the
> picture of this cat. I did indeed do some comprehensive research on
> Markku's background, his pleasures and other desires. I did steal his
> business secrets and files from his hard drive and put them to other
> network locations for people's enjoyment. Indeed, I did all this by
> myself for you to show how easy it is to steal somebody's identity
> without anybody really knowing it. His business secrets are quite
> significant due to the global operations of Markku J. Saarelainen for
> many years, but his secrets were stolen by me. I did start tailing him
> already in the mid of February, 1999.
>
> Greetings,
>
> William A. Nelson
>
>
>


============================================================================
----







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

From: "Wilton" <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Thu, 17 Feb 2000 16:43:53 -0800

What about the wheeler encryption scheme?  I think it's 64 bits.  Very
little code too.



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

From: Peter Rabbit <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 00:52:43 GMT

mdc wrote:
> 
> On Thu, 17 Feb 2000 12:53:37 +0100, Runu Knips
> <[EMAIL PROTECTED]> wrote:
> 
> >Khalil Haddad schrieb:
> >> I am developping softwares in VB6 and would like to use strong
> >> encryption algorithms.
> >> Anyone could tell me where to find sources in VB so that I can study
> >> them.
> >
> >Ouch.
> >
> >Better use a .dll with C routines, if you can.
> 
> I agree with this.  It's been my solution.
> 
> >VB is not meant for any serious programming task, and I don't
> >think anyone has ever written a cryptographic software in VB.
> 
> VB is great for some serious programming tasks and I have, in
> fact, done both Blowfish and SHA-1 in VB5.  They're excruciatingly
> slow, but that's to be expected.  I banged the code out quickly in
> VB for a prototype and converted to C DLLs for the real thing.
> 
> >For example, VB doesn't have shift operations, does it ? And
> >its not very optimizing, so cryptography is slow with it.
> 
> The main drawback with using VB is that is doesn't have unsigned
> integers.  You can use the Variant data type and overload integer
> functions like mod and hex.
> 
> While I have to disagree with your broad generalization about VB,
> I certainly agree with your comment that it would be better to use
> C DLLs for crypto functions if only to increase performance.
> 
> mdc

I do not agree that VB is too slow. It all depends what you try to
accomplish. I've written encryption software in VB6 that does ~1 Meg per
second using 6 rounds of XOR and BitRotation in a stream cipher algo.
The slowest part, when writing in VB, is the conversion from STRING to
NUMERICAL but that is because most VB programmers don't know about
StrConv() which is very fast. Granted, C/C++ is probably faster, but
don't knock VB. For working on, and testing your algo on the fly VB is
hard to beat.
Peter Rabbit

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


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