Cryptography-Digest Digest #329, Volume #12 Tue, 1 Aug 00 15:13:01 EDT
Contents:
Hardware based PK crypto device - University project ("Paul Morris")
Re: Secure key-based steganography (Steve Weis)
Re: Small block ciphers (Terry Ritter)
Re: Elliptic Curves encryption (Terry Ritter)
Re: Dimensions of m (Mike Rosing)
Re: Stream Ciphers (Anthony Stephen Szopa)
Re: Psuedo-random number generation (Anthony Stephen Szopa)
Re: Hash function? (tweaked) (Francois Grieu)
Re: Just Curious. Are girls/women interested ([EMAIL PROTECTED])
Re: Blowfish Implementation ("Joseph Ashwood")
Re: Hardware based PK crypto device - University project ("Joseph Ashwood")
Re: C++ Plaintext To Block unsigned long (Joseph Stein)
Re: Stream Ciphers (Benjamin Goldberg)
Re: Proving continued possession of a file (Andru Luvisi)
Re: Psuedo-random number generation ("Joseph Ashwood")
Re: Just Curious. Are girls/women interested ("Joseph Ashwood")
Re: C++ Plaintext To Block unsigned long ("Joseph Ashwood")
Re: Stream Ciphers ("Joseph Ashwood")
----------------------------------------------------------------------------
From: "Paul Morris" <[EMAIL PROTECTED]>
Subject: Hardware based PK crypto device - University project
Date: Tue, 1 Aug 2000 18:20:07 +0100
Hi,
I am currently reading Electronic Engineering at Southampton University, UK,
and as a major part of my degree course I must develop an electronics based
project. Having read a little about encryption technology in general and
having a general interest in the subject area I was hoping to base my
project on some form of public key encryption system.
My initial idea revolved around designing a unit capable of conducting a
secure transaction with an authenticated partner. This unit would consist of
a PIC16 micro computer for general control and possible data crunching or
the use of an FPGA board which could provide more sophisticated and faster
data manipulation. Having read a little into SSLv3 I was considering basing
the handshaking process on this model. Is that reasonable?
If anyone has any experience in the area of hardware based encryption
systems I would very much appreciate your assistance.
a, Could a modern (secure) algorithm be implemented using the equipment
described above and just how difficult a job would you rate developing it
onto the hardware.
b, Could you suggest a suitable, secure algorithm for this type of
implementation.
c, Since the project is generally supposed to be of some academic or
commercial value can you think of a specific requirement which could be met
by a project of this nature or similar.
d, Could you suggest a good book or two for a relative newbie (hopefully not
too much mathematical proof) that I could buy through normal channels
(amazon etc.)
Thank you very much for any help you can afford,
Regards,
Paul Morris
[EMAIL PROTECTED]
------------------------------
From: Steve Weis <[EMAIL PROTECTED]>
Subject: Re: Secure key-based steganography
Date: Tue, 01 Aug 2000 10:26:51 -0700
Toby Sharp wrote:
> At each visited pixel, the least significant bit of image data is replaced
> by the next covert message bit until all data bits have been encoded. The
Alice and Bob would have to generate an original image each
transmission. If they use the same image over and over, Eve will notice
the slight changes in the image. If they choose some image which is
publicly available, Eve will be able to compare the original with their
transmission. (Assuming Eve is a powerful adversary and has the
resources to find the original image). There is also the question of
traffic analysis. It will look suspicious if Alice and Bob suddenly
start sending each other images and haven't had a history of doing it in
the past.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Small block ciphers
Date: Tue, 01 Aug 2000 17:27:20 GMT
On 01 Aug 2000 04:16:24 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>[...]
>Obviously an 8 bit cipher is subject to dictionary attack.
>With a small password a cipher is subject to brute force.
If by "dictionary attack" you mean an attack on the key, that is not
obvious. An "8-bit" block cipher is a permutation of 2^8 = 256
elements, and so there are 256! possible keyings, or (from
http://www.io.com/~ritter/JAVASCRP/PERMCOMB.HTM#Factorials
), some binary value with about 1684 bits. This is a large enough
keying potential.
>But perhaps it is possible to make a cipher that is
>provably secure if we use 8 bit blocks. By provably secure
>I mean no attacks better than dictionary or brute force.
The problem with a small block is that there are so few elements in
the selected random permutation.
First, if we encipher individual letters into block elements, the
result will have the same statistics as the letters. This is just
Simple Substitution as in newspaper ciphers.
Next, we normally expect to encounter known plaintext. But with an
8-bit block, even in the best possible case we can't send any more
than 255 blocks before the transformation is absolutely known. (In
general, a better estimate would be 16 blocks before we start getting
repeats we already know.)
And of course defined plaintext will resolve the block directly.
>My current interest is in block ciphers. I am not sure
>what relevance the security of stream ciphers has in this.
>Certainly adding state increases security, however doing so
>it is no longer a block cipher.
Small transformations may make more sense as a stream cipher, since
there will be some hidden RNG involved, or tables can be used in
arbitrary order, or their contents changed. For the single unchanging
transformation of a block cipher, only size and plaintext distribution
hides the contents.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Elliptic Curves encryption
Date: Tue, 01 Aug 2000 17:28:06 GMT
On Tue, 01 Aug 2000 09:30:22 -0500, in
<[EMAIL PROTECTED]>, in sci.crypt Doug Kuhlman
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> On Mon, 31 Jul 2000 12:12:32 -0500, in
>> <[EMAIL PROTECTED]>, in sci.crypt Mike Rosing
>> <[EMAIL PROTECTED]> wrote:
>>
>> >Terry Ritter wrote:
>> >> Nope: Facts exist independent of belief. Convincing someone is not
>> >> relevant to reality.
>> >
>> Facts need no belief, no propaganda, no agreement, no popularity.
>> There is no vote on facts. Facts are there if you don't like them
>> just as much as if you do. Any argument which implies correctness
>> because many experts believe such a thing is a false argument. Facts
>> don't care about experts or belief.
>>
>Please, then, give us an example of a "Fact". By your definition, no
>such thing exists.... "1+1=2" True only because we define it that
>way. "The Earth is a slightly squashed sphere." Sure appears that way
>now, but maybe it exists in 4 dimensions and we can only see 3...maybe
>the Earth really is flat and there are massive teleporters to make it
>appear spherical.
>
>What is a fact?
I don't care *what* a fact is, only that there *are* facts.
Apparently you missed the original context, which was:
<[EMAIL PROTECTED]>:
>>>>>[...]
>>>>>I have an old Russian text that says "proof is our ability to convice
>>>>>someone else we are right".
If one of those facts is that a particular cipher is weak, it really
doesn't matter who is convinced. And if we convince the world of
something which is not a fact, that does not make it one.
If the issue is mathematical fact, we may be able to use some facts to
derive additional facts. This process is called "proving," but it
does not reach a usable "proof" of results until we have an acceptable
basis for assuming the original facts. That basis does not exist in
PK strength proofs.
>> >> I will believe a mathematical proof, if I can understand it, because I
>> >> will have no choice. There are, however, many supposed "proofs" which
>> >> I do not accept because they are only proofs if one accepts certain
>> >> assumptions which I do not accept.
>> >>
>This is self-contradicting. *EVERY* mathematical proof is based on
>asssumptions. Most people accept these assumptions, but some do not.
>The Peano Postulates are the foundation of a lot of math. Other
>branches make other assumptions. *EVERY* mathematical idea starts with
>a series of "IF"s (some are just assumed) before reaching conclusions.
>A mathematical proof can *NEVER* prove its assumptions.
I agree that all mathematics is based upon assumptions. However, I
assert that the sort of assumptions required by cryptographic proofs
are not the fundamental, basic assumptions beyond which mathematics
cannot be expected to go, but instead imply very complex logic systems
which are glossed over by stating the needed result as an assumption.
To use the same word, "assumption," in both cases, and then on that
basis to assume they are equivalent, is a logic error, even for a
mathematician.
>The problem arises when people assume mathematical conclusions exist
>independent of their "IF" statements. "If 1=0 in the integers, then I
>have a Ph.D. in computer science." This is a mathematically true
>statement, but it says NOTHING about my degree or lack thereof in CS.
How odd, then, that your are not criticizing the so-called Public Key
"proofs of strength" yourself.
>Until you are willing to see that all mathematics is based on
>assumptions, you will never be a mathematician.
I'm not a mathematician, and I don't intend to be one. Mathematics is
a tool used in cryptography; it is not the essence of cryptography,
any more than it is the essence of everything else math can describe.
But I doubt we could criticize PK proofs on a mathematical basis; the
problem with them is not really mathematical. The problem is that the
complex assumptions they require cannot be confirmed as fact, and so
the mathematical results do not necessarily apply. That may not be a
math problem, but it sure is a problem for people who take those
results to have real meaning in cryptography, and there are many such
people.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Dimensions of m
Date: Tue, 01 Aug 2000 12:32:10 -0500
Sergio Arrojo wrote:
>
> Why do I find always the same dimensions for m when implementing Elliptic
> Curves appropiate for Cryptography. That is, most softwares offer curves
> with m values (24,30,33,39,40...), are these numbers for any reason better?.
> Why do we want to describe the m with two different factors (prime and not
> prime), why don t just use directly a prime number?
> does it, maybe, make the algorithms easier and faster to run, if then, why?
Are you refering to GF(2^m)? If so, then each of those special field sizes
has an advantage because there is a faster way to do the low level math.
While prime m is best, there are even m which are 2*prime that are well
suited for crypto.
The choice of field size has to do with security, cycle time, cost and
customer satisfaction. These can be mutually inconsistent, and it's difficult
to pick the right field size for any given application.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers
Date: Tue, 01 Aug 2000 10:42:43 -0700
Lisa Retief wrote:
>
> I just did a quick scan through the FAQs and couldn't find anything on
> stream ciphers. Have I missed it or does this newsgroup focus only on block
> ciphers? Are there any non-proprietry/patented stream ciphers out there?
>
> Just curious,
> Lisa
I claim that OAP-L3 encryption software is practicably unbreakable
when used according to recommendations.
Why do you need a "free" stream cipher?
What do you plan to use it for or do with it?
You can have a shareware copy of OAP-L3: Original Absolute
Privacy - Level3 encryption software package.
There are many many people who have it. I realize that many of
them use it without paying for it. There is NO programmed
expiration within the software.
I would not be upset if someone placed the shareware software
on a server for free download from an ISP in Iceland, Ireland,
or Mexico, since these countries do not have any restrictions on
exporting encryption software (unless this has changed recently.)
Go to http://www.ciphile.com
Go to the Pricing and Ordering web page and click on the blue
anchor "email" to get your shareware copy.
If your interest is encryption then you need to at least become
familiar with OAP-L3 firsthand.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generation
Date: Tue, 01 Aug 2000 10:49:59 -0700
RecilS wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Well I'm looking for a bit of brief help. I'm working on a one-time
> pad system and I'm trying at the moment to devise a method to get
> identical sequences of completely random numbers to two different
> people without the possibility of compromise. The only two methods
> I've realized are particle entanglement (obviously a bit impossible
> right now) and trading CDs. Well short of setting up a hardware,
> random number generator in my house (which i plan on doing) I need to
> fill a few CDs with random bits.
>
> Right now, for testing, I'm willing to fall back upon
> psuedo-randomness, but I'd rather be developing my software than a
> program I will use very briefly and never again. So...
>
> If anyone knows of a good program which generates numbers with a high
> degree of randomness and can do so on the scale of 650megs within a
> realistic ammount of time, PLEASE LET ME KNOW! Even if it takes a
> few days or longer I'm interested as I'm still developing the
> interface and have time to kill.
> THANKS.
>
> BTW - Please post a followup and do not email me at this time.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBOYUfDBJETAFqh0RgEQISUACeIcFNv5t7oJ18Jq+h1WrlS6OmHtEAoKhx
> z7XKEmlcDHR56c18UR+pGRGH
> =M4Gy
> -----END PGP SIGNATURE-----
OAP-L3: Original Absolute Privacy - Level3 encryption software
package is SHAREWARE.
Although this software is shareware there is NO programmed
expiration written into the code.
I claim that this encryption software is practicably unbreakable
when used according to recommendations. Get it and prove it for
yourself.
This can give you what you want.
Get your free shareware copy at http://www.ciphile.com
Go to the Pricing and Ordering web page and click on the blue anchor
"email" in the third paragraph.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Hash function? (tweaked)
Date: Tue, 01 Aug 2000 19:57:48 +0200
Boris Kazak <[EMAIL PROTECTED]> proposed
Karagash, a simple hash function.
In the reference implementation, the function accepts a message
containing an arbitrary number of 8 bit bytes, and outputs a 16 bytes
result. An additional input key of up to 16 bytes is optional.
Negative comments:
1) the design goals are not given; in particular it is unclear if the
function is designed to be an unkeyed hash function like MD5 or SHA1
are, or a keyed hash like MAA or ISO-9797 are. The former are usefull as
message digest as part of electronic signature schemes, while the later
are providing message authentification between parties sharing a secret
key.
1a) in the unkeyed hash hypothesis, is the goal to prevent the attacker
from making two messages with the same hash, or from making a message
with a choosen hash ?
1b) in the keyed hash hypothesis (where presumably, for a fixed and
unknown key, the adversary tries to guess the hash of some forged
messages from the hashes of others), is the adversary able to obtain the
hash of some chosen messages ?
2) the design rationale are not given; for example what values are
acceptable for SEED ?
3) the name SEED is misleading; rather than an initial value, this is a
multiplicative constant used thruout the algorithm.
4) For an unknown key as in 1b, and knowing the hash of any N bytes
message, it is trivial to derive the hash of any forged message
consisting of these same N bytes, then the value of N on 8 bytes, then 6
bytes of zeroes, then any arbitrary trailer: just initialize the buffer
to the known hash, make an additional 2 rounds with zeroes, at which
point the buffer is as it should be after the N+14 bytes of the forged
message; then hash the trailer, the forged message length, and the final
zeroes, to get the hash of the forged message. This is a fatal flaw for
a keyed hash.
5) Maybe disclosing the whole buffer on output reveals too much about
the key, if it is unknown as in 1b.
6) Maybe the round function is too simple if the key (and thus the state
of buffer at any time) is known as in 1a, and finding collisions appears
feasible.
7) the reference C impementation is defficient in many ways:
7a) code is badly structured: the core algorithm is coded 3 times with
minor variants inside the main() procedure, rather than as a single
reusable function; the only functions provided duplicate the
functionality built into the standard fgetc() and fputc().
7b) the code attempted at some point to use a sliding index instead of a
buffer rotation, and there are remains of this in the output section,
making it unnecessarily obfuscated.
7c) input file length is assumed to be exactly 45 bytes, when the
definition clearly accepts any length to at least 2^64-1 bytes.
7d) input filenames without extension cause failure.
7e) long input filenames cause buffer overflow.
7f) main() returns void, this is not ANSI-C compliant.
7g) // are used for some comments, this is not ANSI-C compliant.
8) A few reference hash values would help.
Positive comments:
The description is precise enough, and the reference implementation
seems to match it except as the length is concerned.
Breaking the thing (in the various possible meanings) is an interesting
cryptanalysis exercise for the group.
Francois Grieu
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Just Curious. Are girls/women interested
Date: Tue, 01 Aug 2000 18:11:00 GMT
If you wondering if becoming a cryptographer will be a good way to pick
up chicks, the answer is no. "Hey baby what's your prime?" isn't likely
to get you far.
Then again, if you're looking to have an affair, it might not be a bad
idea to choose a woman who knows how to keep a secret!
In article <8ltmh2$mcg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> in cryptography? Is there any female poster on this board? Any
> prestigious woman in the field at all? Thank you for your response.
>
> --Sisi
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
--
"Wife who put husband in doghouse, soon find him in cathouse."
-- Wisdom of the Tao
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Blowfish Implementation
Date: Tue, 1 Aug 2000 11:12:27 -0700
Well assuming you're working with C, and you are not conerned about endian
issues.
> char *str;
> str = "MyStringToEncrypt";
long *ints;
ints = (long *)str;
And for decryption:
long *ints;
ints = decryption
char *str
str = (char *)ints
Just tell the computer that it's a pointer to a different type, in this case
long instead of char.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Hardware based PK crypto device - University project
Date: Tue, 1 Aug 2000 11:25:28 -0700
I'd say that you should make it easy on yourself, and reduce the size of
your threat model at the same time. Simply use RSA to encrypt/sign a
transaction message. The basic module would almost certainly be enough to
justify itself as a major project, even though it's been done (reference
Rainbow technologies). The main portion of your work would be on the
exponentiation unit, although the mod unit would be substantial (little more
than a giant shift register and a subtractor). Of course this is assuming
that you can design the actual hardware components. If you are going to use
prebuilt components, you may want to consider using a different mechanism
entirely, and going with something more modern looking/sounding. Just as an
example, each device has a long term ECDSA key, a random number generator
(this will have to be custom built, but since you dont' need high quality
for a demo there are a large number of easy ones that you could wire up in
well under an hour), some RAM, and a computation unit. Use the RNG to create
an ephemeral ECC key, sign the curve using the long term ECDSA key, exchange
public keys (with signature) on the wire between (standard serial
connection, 9600 baud is suitable), verify other signature (the public
signing key of the other party muct be known before hand), compute the
shared secret, use that to key Twofish, transfer whatever data you want
using Twofish. That should be enough to keep you busy for a while, and is a
fresh enough idea that I'm not sure it's been done yet. It is also quite
secure (provided you choose large enough ECDSA/ECC keys, 160-bits is
enough). I hope you enjoy it, a lot.
Joe
"Paul Morris" <[EMAIL PROTECTED]> wrote in message
news:8m70m4$[EMAIL PROTECTED]...
> Hi,
>
> I am currently reading Electronic Engineering at Southampton University,
UK,
> and as a major part of my degree course I must develop an electronics
based
> project. Having read a little about encryption technology in general and
> having a general interest in the subject area I was hoping to base my
> project on some form of public key encryption system.
> My initial idea revolved around designing a unit capable of conducting a
> secure transaction with an authenticated partner. This unit would consist
of
> a PIC16 micro computer for general control and possible data crunching or
> the use of an FPGA board which could provide more sophisticated and faster
> data manipulation. Having read a little into SSLv3 I was considering
basing
> the handshaking process on this model. Is that reasonable?
>
> If anyone has any experience in the area of hardware based encryption
> systems I would very much appreciate your assistance.
>
> a, Could a modern (secure) algorithm be implemented using the equipment
> described above and just how difficult a job would you rate developing it
> onto the hardware.
> b, Could you suggest a suitable, secure algorithm for this type of
> implementation.
> c, Since the project is generally supposed to be of some academic or
> commercial value can you think of a specific requirement which could be
met
> by a project of this nature or similar.
> d, Could you suggest a good book or two for a relative newbie (hopefully
not
> too much mathematical proof) that I could buy through normal channels
> (amazon etc.)
>
> Thank you very much for any help you can afford,
>
> Regards,
> Paul Morris
> [EMAIL PROTECTED]
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Joseph Stein)
Subject: Re: C++ Plaintext To Block unsigned long
Reply-To: [EMAIL PROTECTED]
Date: Tue, 01 Aug 2000 18:30:59 GMT
That looks great but I still need to have it into the 2 unsigned long
chunks so that I can encrypt it? which is my goal however it is
accomplished
On 1 Aug 2000 16:49:13 +0200, [EMAIL PROTECTED] (Paul Schlyter)
wrote:
>In article <[EMAIL PROTECTED]>,
>Joseph Stein <[EMAIL PROTECTED]> wrote:
>
>> // allocate the buffer (align to the next 8 byte border plus padding)
>> int nStrLen = sPlainText.length();
>> byte[] buf = new byte [((nStrLen << 1) & 0xfffffff8) + 8];
>>
>> / copy all bytes of string into the buffer (use network byte order)
>> int nI;
>> int nPos = 0;
>> for (nI = 0; nI < nStrLen; nI++)
>> {
>> char cActChar = sPlainText.charAt(nI);
>> buf[nPos++] = (byte) ((cActChar >> 8) & 0x0ff);
>> buf[nPos++] = (byte) (cActChar & 0x0ff) ;
>> }
>>
>> // pad the rest with the PKCS5 scheme
>> byte bPadVal = (byte)(buf.length - (nStrLen << 1));
>> while (nPos < buf.length)
>> {
>> buf[nPos++] = bPadVal;
>> }
>>
>> This is the algorithim that I take plaintext and convert it to blocks
>> so that it can be encrypted for Java.
>> How do I accomplish this in C++?
>
>
>Like this (assuming your plaintext resides as ASCII in a normal char * buffer)
>
> // allocate the buffer (align to the next 8 byte border plus padding)
> int nStrLen = strlen(sPlainText);
> int nBufLen = nStrLen & 0xfffffff8) + 8;
> unsigned char *buf = malloc( nBufLen );
>
> // copy all bytes of string into the buffer
> strcpy( buf, sPlainText );
>
> // pad the rest of buffer with the PKCS5 scheme
> unsigned char bPadVal = (unsigned char)(buf.length - nStrLen);
> memset( buf+nStrLen, bPadVal, nBufLen-nStrLen );
>
>
>This code is a little bit in C style, which means it's quite easy to
>translate to plain C as well -- just move all the declarations to the
>beginninf of the block.
>
>
>> Is there a reference I can check out?
>
>
>There are lots of reference books about C++ -- check out
>http://www.amazon.com !!!!
>
>
>--
>----------------------------------------------------------------
>Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
>Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
>e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
>WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers
Date: Tue, 01 Aug 2000 18:33:29 GMT
Runu Knips wrote:
>
> There are also other ciphers such as ISAAC, which is described in
> http://burtleburtle.net/bob/rand/isaacafa.html
> I wouldn't put much trust in that algorithm, however. Its lowest
> period estimate is only 2**40, which is less than you can get when
> using two 32 bit numbers.
The *shortest* cycle length is 2**40 32-bit values [that is a 2**62 bit
cycle], and the average cycle length is 2**8295 values.
I would be interested in knowing how you can get a *secure* stream
cipher with just 64 bits of state.
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: Proving continued possession of a file
Date: 01 Aug 2000 11:28:00 -0700
[EMAIL PROTECTED] writes:
[snip]
> Bob then publishes the date and the single
> number b:
>
> b = r^(M^s) mod n
> = (...(((r^M)^M)^M)...^M) mod n
[snip]
How does Bob compute this number so as to minimize ram usage and work?
Andru
--
Andru Luvisi, Programmer/Analyst
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generation
Date: Tue, 1 Aug 2000 11:42:23 -0700
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
I thought we had finally gotten rid of you? What happened, did you miss
being verbally bloodied, or are you still too dumb to know when you've been
insulted? Ooh, ooh, I know, the burns finally healed from your somewhat
lackluster attempts at flames from last time.
To anyone who doesn't know yet:
Szopa is one of the worst trolls I've seen floating around on sci.crypt
(and I've been reading it for 5 years or so). He has no clue about anything
he claims. He is the perfect embodiment of opening your mouth to prove
you're <cough> not the most intellectually advanced person in the room.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Just Curious. Are girls/women interested
Date: Tue, 1 Aug 2000 11:34:11 -0700
Maybe it's my twisted nature, but I found some grain of humor in this. But I
think we should encourage more women to join our ranks for one very solidly
established reason, they think differently than men, and new ideas are good
to have.
Joe
BTW has anyone else noticed that if the Intel RNG is not available, you get
random data?
> If you wondering if becoming a cryptographer will be a good way to pick
> up chicks, the answer is no. "Hey baby what's your prime?" isn't likely
> to get you far.
>
> Then again, if you're looking to have an affair, it might not be a bad
> idea to choose a woman who knows how to keep a secret!
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: C++ Plaintext To Block unsigned long
Date: Tue, 1 Aug 2000 11:44:30 -0700
> That looks great but I still need to have it into the 2 unsigned long
> chunks so that I can encrypt it? which is my goal however it is
> accomplished
Cast the pointer to a different pointer type.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Stream Ciphers
Date: Tue, 1 Aug 2000 11:45:11 -0700
Please see my response in
Re: Psuedo-random number generation
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote [something stupid again]
------------------------------
** 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
******************************
