Cryptography-Digest Digest #170, Volume #11      Sun, 20 Feb 00 19:13:01 EST

Contents:
  There are two interlinked entries in his diaries ... ("William A. Nelson")
  Re: Processor speeds. ("John E. Kuslich")
  Re: Keys & Passwords. ("Joseph Ashwood")
  Re: Does the NSA have ALL Possible PGP keys? (Guy Macon)
  Re: Does the NSA have ALL Possible PGP keys? (Guy Macon)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (Terry Ritter)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (Anthony Stephen 
Szopa)
  Mixmasters encrypt how? (William Rowden)
  Re: NIST publishes AES source code on web (Mok-Kong Shen)
  Re: NIST publishes AES source code on web (Mok-Kong Shen)
  Swapfile Overwriter: R.I.P. (Steve K)
  SV: Is Phi perfect? ("Claes & Gunn Irene")
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (Anthony Stephen 
Szopa)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (lordcow77)
  Re: Beginner Help ? ("Adam Durana")
  Who is using ECC? (JCA)
  Re: Keys & Passwords. (wtshaw)

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

From: "William A. Nelson" <[EMAIL PROTECTED]>
Crossposted-To: 
soc.culture.nordic,soc.culture.usa,soc.culture.australian,soc.culture.israel,soc.culture.europe,alt.politics.org.cia,soc.culture.soviet,soc.culture.russian,alt.2600
Subject: There are two interlinked entries in his diaries ...
Date: Sun, 20 Feb 2000 21:31:27 GMT


1. In December, 1998 (December 29, 1998) he makes a detail entry knowing that his
house, 2441 Inverloch Circle, Duluth, GA 30096, was bugged and monitored by the U.S.
intelligence community and requests these people (aloud) to find a person from his past
whose name starts with H and he seemed to have made this request knowingly to challenge
the U.S. intelligence agencies and systems.

2. In July, 1999, he made the entry that the person, whom he had requested in December,
1998 to be found, was in the same concert in the Chastain Park, Atlanta among few other
people who he observed and overheard. He did not make the eye contact, but he knew that
they had brought this person to him. Later in July, 1999, he makes few notes "I fucked
the CIA and the U.S. Intelligence Agencies". And this is all in his diaries.

In the diary entry, in August, 1998, he writes that Jimmy from 99X (Radio Station in
Atlanta) had called him two times to participate in some competition to win a trip or
some other prize. This person seem to have known Markku J. Saarelainen to be present at
the house at that time. According to his entries, this was not usual, because he had
never received any calls from any radio stations or other media companies before. It
does appear also that Leslie, Jimmy and another radio show host had called Jack and the
name of the closest one, which is very interesting indeed. But it does appear that (in
the diary entry) Markku J. Saarelainen "had fucked these radio show hosts".

Yours,

William A. Nelson



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

From: "John E. Kuslich" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Date: Sun, 20 Feb 2000 14:46:56 -0700

I must disagree with you in this regard.

Commodity computer producers and all their chip suppliers have huge
incentive to increase the power of their products through constant redesign
and revision.  Furthermore, there are economies of scale and incredible
amounts of customer money and demand available to fund this constant
improvement.

Supercomputer vendors are not in such a position.  Their customer base and
funding are tiny compared to the commodity computer industry.  The relative
funding required to redesign a supercomputer just cannot support design
improvements on the scale of commodity computers. You cannot trash last
year's model of a super computer each season and sell an all new improved
model this year.  The investment per computer is just too great.

Moore's law and the exponential drop in price/performance of clustered
commodity computers cannot be matched in the supercomputer industry (or what
little remains of it).

Many Beowulf systems around the globe have turned in performance on real
computer problems at price performance ratios literally thousands of times
less than can be done with so called super computers.  When you factor in
the cost of OS software (say Linux running PVM or MPI) Vs specialized OS's
from the supercomputer vendors, there is just no contest.  The motion
picture industry is a good example of the advantage in price performance
that can be achived by using clustered commodity computers.  All the big
animation/special effects houses now use Beowulf type systems. The
performance they achieve on ray trace software would not be possible using
the classic CRAY boat anchor computer.

Sure, there will always be the special machine like those at NSA that will
outperform clustered commodity units.  But these are a special case.

JK





Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> John wrote:
> > ...  I guess I wanted a rough estimate of how much faster the
> > best home PC is as compared to the latest "super-computer."
> > I know that the gap is closing.
>
> How do you "know" this?  Improvements in microcircuit technology
> can (often) be used in supercomputers too.  Further, supercomputers
> are a whole lot more than just a CPU or two; typically they have
> incredibly high-throughput I/O systems.  Many supercomputers are
> also capable of processing a huge number of computational threads
> in parallel, although it is not always easy to exploit that
> capability.
>
> If there has been a lessening of the "gap" between PCs and
> supercomputers, it has more to do with funding and personnel
> changes for supercomputer development than with improvements to PCs.


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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Keys & Passwords.
Date: Sun, 20 Feb 2000 13:55:38 -0000

> A hex (4 bits) has only 32 bits, so one can only map that
to 32
> specifically chosen symbols between the ascii values
32-126. The
> small set {a-z, 0-9} has already 36 symbols. Further, if
one maps
> a hex to a subset of that, one could just as well use the
hex
> itself, I suppose. (What I meant was mapping a pair of
hexs (8 bits).
> That seems out of the question in any case.)

I think you misunderstood the first first part, or perhaps I
misunderstood at least one of the statements. What I believe
was meant was to create a mapping of greater than 16
possibilities (hex) to the range of 32-126, perhaps going as
high as using the full range of 94 characters. This would
give much more range of characters, and suitably shrink the
data size by a factor of 5.875. The only reason I see
against doing these operations is that if you're dealing
with a large text it could be quite compute intensive to
convert, but the original question was for keys and
passwords, which I'd put an upper limit of 30 base 256 to
make the new max in the high 30s which can be memorized by a
person in a short amount of time. If instead you chose to go
with hex the length would be 60, which is more difficult to
remember.
                    Joe



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

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 20 Feb 2000 17:19:52 EST


(followups set)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>
>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.

It even fails on a purely theological basis.  He is saying
the logical equivalent of "God is incapable of adding one
to an integer", which violates his own claim of limitless
power and knowledge.

We now return to the topic at hand.


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

From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 20 Feb 2000 17:24:25 EST

(followups set)

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Douglas A. Gwyn) wrote:
>
>"Trevor Jackson, III" wrote:
>> Ah, but can he create a rock that he cannot lift?
>
>Basically, the question is whether a contradiction can exist.
>If you take the position that it cannot (which is fundamental
>to effective thought), then it is easy to show that there is
>a problem with the definition of X as something that has no
>restrictions.  Non-contradiction *is* a restriction; thus the
>conclusion is that X as described must not exist.  For some
>people, this comes down to choosing between belief in an
>all-powerful God versus a non-contradictory universe.  (Others
>manage to avoid making the choice, in which case they have
>implicitly chosen the former.)

Indeed, traditional christian/jewish/islamic theology rejects
the concept of an all powerful God for that very reason.  In
fact, all three of the religions I just mentioned place various
additional restrictions on God, such as the inability to do evil.


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

From: [EMAIL PROTECTED] (Terry Ritter)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Sun, 20 Feb 2000 22:35:44 GMT


On Sun, 20 Feb 2000 09:26:45 -0600, in
<[EMAIL PROTECTED]>, in sci.crypt Chuck
<[EMAIL PROTECTED]> wrote:

>[...]
>In the privacy and encryption communities, an algorithm or
>implementation is considered guilty until proven innocent. 

But in cryptography there *can* *be* *no* "proven innocent."  About
the best we get is "not proven weak," and we just get that when people
run out of attack ideas, or when something must be chosen on schedule.



>[...]
>Of all the algorithms subjected to rigorous analysis
>over the past 15 years, there are fewer than ten survivors that are
>trusted well enough by governments to be used in military and
>spy-vs-spy communications.

That value sounds way, way low.  

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


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

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Sun, 20 Feb 2000 14:51:32 -0800

Joseph Ashwood wrote:
> 
> [snip stuff I'm not replying to]
> > Support your conclusion with fact-based logic citing the
> theory and
> > operation of the OAP-L3 encryption software package as
> presented in
> > the Help files available at http://www.ciphile.com
> [snip other stuff I'm not replying to]
> Well, let's do it this way.
> 
> On your claim of originality:
> Your random number generator may or may not be original, but
> you use of XOR is certainly not, I hereby propose renaming
> this cipher to YEST, Yet Another Stream Cipher. Of course if
> you don't use XOR, then your comparison to OTP is likely to
> fail on more levels.
> 
> On your naming:
> You claim absolute privacy, yet even OTP does not gaurentee
> that, just that the plaintext cannot be found.
> 
> On your comparison to OTP:
> OTP offers absolute secrecy, it is impossible to determine
> the contained information without already knowing it. It
> also requires true random numbers, something which you have
> yourself admitted your program does not offer.
> 
> On your use of permutations of base 10:
> You severely limit the possibilities for keys, even if you
> were to limit against having the same base 10 digit repeated
> immediately your security could potentially rise a
> significant amount.
> 
> Any questions?
>             Joe

I get it.

This is a news group where gentlemen dual verbally.

Touché!

I suppose eventually most detractors of OAP-L3 will realize that 
they have run out of minor points to object to and finally get to 
the "will it or won't it live up to its claims" issues.

The first issue to address is the theory upon which OAP-L3 is based.

At your leisure:  I am patiently waiting for an intelligent 
thoughtful discussion on this theory.  Of course it is well covered 
in the theory and processes Help files at http://www.ciphle.com  

I am available to clarify any questions anyone may have on this 
theory.

Thank you.

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

From: William Rowden <[EMAIL PROTECTED]>
Subject: Mixmasters encrypt how?
Date: Sun, 20 Feb 2000 22:52:48 GMT

I'm interested in the encryption methods used by anonymous remailers.
Can someone point me to some documentation on the algorithms,
particularly the one used by type 2 (Mixmaster)?  My basic
understanding is that type 1 remailers use PGP's method (i.e., CAST,
IDEA, or 3DES for the message, with the session key encrypted by a
public key--an Elgamal, or DH/DSS, public key in this case).  I see
that Mixmaster remailers use RSA keys, but they appear to have a
special key format.  I'll browse the sources, but I'd like a more
detailed algorithm description first.  I imagine one of the sci.crypt
regulars knows.

TIA
--
    -William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB  DA28 379D 47DB 599E 0B1A


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

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 00:05:57 +0100

John Savard wrote:
> 
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
> 
> >John Savard wrote:
> >> ... I am somewhat puzzled by that comment.
> 
> >I'm sorry you're puzzled, but it directly addressed the point
> >raised in the message to which it was a response.
> 
> Oh, I liked the post: but applying the adjective "thankfully" to a
> statement that the U.S. hasn't ratified a treaty that would obligate
> it only to do much less than it already voluntarily does in the way of
> export control was the one thing that puzzled me.
> 
> Perhaps either I'm missing some restrictions in Wassenaar that are not
> in force under U.S. law, or you are thankful that the U.S. has the
> power to change its mind in the future.

Concerning ratification, no participating country has, as far as
I am aware, yet ratified the current Wassenaar Agreement. As I
mentioned in other follow-ups, the US lobbyed to have the crypto
clauses put in. (A high official came to Bonn for that.) By chance
or not, France shortly afterwards canceled its very restrictive
crypto laws. Then Germany followed suit (for apparently the same
underlying reasons as France, though these real reasons have never 
been explicitly ackowledged, for wanting of pubically 'demonstratable'
materials.) In this situation it was clear that the chance of 
ratification of Wassenaar crypto clauses became minimal. I read in 
fact shortly after the Agreement was signed in a newspaper of a 
time point at which the issue of ratification would be treated by the 
Bundestag but I have later never again heard anything about that.

In my view, the US has changed its mind, and that very drastically.
Making strong crypto of 128/256 bits (entirely) freely available
to the terrorist countries does not only contradict its previous
wishes (while lobbying) but also evidently goes in a direction 
diametrically opposite to the aim and spirit of Wassenaar as a whole 
(crypto is only a part of the issues contained in the Agreement). 
Why it does this is not yet very clear (in the sense of understandable
proofs) to me. I surmise that that has some non-trivial connection 
with the fact that crypto industries of the other countries (whether
Wassenaar or not) are threatening to obtain a firm or even major
position in the international market of information security.
Relaxing the restriction allows the US crypto firms to more easily
deal with their foreign competitors. This seems in my humble view
to explain well why the (sacred) issue of combatting terrorism 
suddenly has become a non-issue in this context. Once again, one 
sees the 'power' of money. Everything else, whether terrorism, 
crimes, protection of teenagers from immoral informations on the 
internet, etc. etc. etc., all are really 'secondary' in comparison 
to money as seen by the politicians. There is an Asian proverb 
saying that money can cause devils to turn your mills (i.e. to
work for you).

You wrote about 'change of mind in the future'. Hopefully, the
US wouldn't (again) change its mind in the future. For that would
mean strenthening crypto restrictions, perhaps even much more 
severe than the EAR 'before' its recent modifications.

M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Mon, 21 Feb 2000 00:15:16 +0100

Errata:

The sentence 'Then Germany followed suit' should read:
'Then Germany, though without such laws, followed suit in
officially declaring that R&D in crypto is entirely free 
(for at least the coming two years)'.

M. K. Shen

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

From: [EMAIL PROTECTED] (Steve K)
Subject: Swapfile Overwriter: R.I.P.
Date: Sun, 20 Feb 2000 23:12:26 GMT

>From the bad news / bad news department:

The EULA for Scorch has changed, to prohibit integrated use with
external applications.

In compliance with this, Visual Fantasy has withdrawn Swapfile
Overwriter, which re-boots Win9.x to DOS and runs Scorch to overwrite
win386.swp.  

Not a problem for old timers who know what a command line is and how
to write a batch file, but maybe someone wants to write a utility to
replace the combination of Swapfile Overwriter and Scorch, for the
point-and-click crowd? 

Visual Fantasy (Where Swapfile Overwriter used to live):
http://www.kagi.com/vfstudio/faq.htm

Iolo Davidson's RealDelete page (good stuff):
http://www.bonaventura.free-online.co.uk/realdelete/

: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: "Claes & Gunn Irene" <cla-lann@removethispart.(and this part)online.no>
Subject: SV: Is Phi perfect?
Date: Sat, 19 Feb 2000 21:48:22 +0100

Hi ..in every textbook you can see that the phi funtion is defined as:
phi(n)=n(1-1/p1)(1-1/p2).....(1-1/pk)
n=p1^e1*p2^e2*.....pk^ek, where p is the primefactorization of n (e is the
exponet of p).
In your case
n=125=5^3=>phi(125)=125(1-1/5)=100
n=49=7^2 => phi(49)=49(1-1/7)=42
........
...........


"Frank the_root" <[EMAIL PROTECTED]> skrev i melding
news:[EMAIL PROTECTED]...
> Hi,
>
> I always thought that the Euler's Phi fonction ( Phi(n) ) was the
> fonction that gives the number of numbers relatively prime to n and
> smaller than n by the multiplication of each primes factors of n reduced
> by one. Last day, I found that it wasn't always true.
>
> For exemple: Let's determine the number of numbers relatively prime to
> 125: 125 = 5³, so we can see that at each 5 numbers, 4 of them are
> relatively prime to 125. 125 × (5/4) = 42 != (5-1)(5-1)(5-1)
>
> I noticed that Phi doesn't work with numbers that are perfect squares,
> perfect cubes ... etc. Ex:
>
> Phi(9) (3-1)(3-1) != 6
> Phi(16): (2-1)(2-1)(2-1)(2-1) != 8
> Phi(49): (7-1)(7-1) != 42
>
> This contradiction seems me to obvious. Was this problem known when
> Euler presented his fonction and is there a official restriction that
> was attributed to this fonction?
>
>
> Tanks
>
> Frank
>
> --
> Ceux qui rêvent le jour, savent des choses qu'ignorent ceux qui rêvent
> la nuit.



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

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Sun, 20 Feb 2000 15:18:20 -0800

lordcow77 wrote:
> 
> In article <[EMAIL PROTECTED]>, Anthony Stephen
> Szopa <[EMAIL PROTECTED]> wrote:
> >Obviously you claim to be unimpressed with my random number
> generator
> >and the processing done on this output to generate the OTP
> files in
> >OAP-L3 encryption software.
> >
> 
> True; why use your PRNG when there are others that have
> withstood far more attention (ie. RC4, SEAL)?
> 
> >Are you also saying that the OTP file management used in the
> software
> >is also worthless?
> >
> >(major snipe)
> 
> >Hallelujah!
> >
> >
> 
> Indeed.
> 
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!


I choose not to complicate an extremely simple process just for the 
sake of window dressing.

Little Boy and Fat Man didn't look like much either but they were 
quite effective.

With the total lack of effort at putting OAP-L3 to rest by simply 
showing that the theory is bogus might lead people to think that 
OAP-L3 has merit.  I don't blame you for not spending much time 
fighting a fight where only a sharp left jab followed by a knockout 
right awaits you.

Isn't this news group all about claimed specialized knowledge and 
or expertise?  Come on, guys.  OAP-L3 isn't rocket science.  It 
is very simple.  Surely someone out there can effectively trash 
the theory upon which the random number generator is based and 
the subsequent processing of these random numbers to generate 
the "OTPs."

Or are most of you just stalling in the hopes someone might come up 
with a clue?

For all the arguments about not wasting the time, just look at all 
the time many of you have spent squirming in this thread.

If the US had made a third atomic bomb in WWII they would have 
called it Fat Chance.

Cheers.

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

Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
From: lordcow77 <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Date: Sun, 20 Feb 2000 15:33:30 -0800

I see that you have failed to respond to any of my source code
that can duplicate what your software package does. For your
conveinence, I will attach the message here. I eagerly await
your point by point rebuttal.

I am singularly unimpressed at your encryption program. As far
as I can see, the only distinguishing characteristic is the
algorithm used to produce the stream of pseudorandom bits that
is XORed with the plaintext (ie. your PRNG). Care to comment on
this assertion?

In article <[EMAIL PROTECTED]>, Anthony Stephen
Szopa <[EMAIL PROTECTED]> wrote:
>>Obviously you claim to be unimpressed with my random number
generator and the processing done on this output to generate the
OTP files in OAP-L3 encryption software.

True; why use your PRNG when there are others that have
withstood far more attention (ie. RC4, SEAL)?


>>Are you also saying that the OTP file management used in the
software is also worthless?
Let's say you use your own random numbers and just use OAP-L3 to
encrypt and manage your own OTP files. Are you saying no one
should do this because you merely say so with no supporting
arguments?

Yes. Your user interface looks like it was designed by a person
who has no conception of GUI design. It does not appear to be
event-based at all, as it is centered on a series of uni-modal
dialog boxes. There are no "wizards" for novice users and no
multi-document interface system for more advanced users.


>>What about the utility files included with the software? You
are saying that it should be of no interest to anyone to have a
utility program to look at a random number file and provide them
with a frequency for each random number in the file?

#include <...>

int main(void)
{
FILE *fin;
struct stat fs;
int arr[256];
int fsize;
int i;
char c;

fin=fopen("foo","rb");
stat("foo",&fs);
fsize=fs.st_size;
for(i=0;i<255;i++){arr[i]=0};
for(i=0;i<fsize;i++){
fread(&c,1,1,fin);
arr[c]++;
}
for(i=0;i<255;i++){
printf("I=%d, n=%d\n",i,arr[i]);
}

return EXIT_SUCCESS;
}


>>Do you think no one should be interested in a utility program
that will read a file in binary and output the ASCII decimal
equivalent for each character?

#include <...>

int main(void)
{
FILE *fin;
struct stat fs;
int fsize;
int i;
char c;

fin=fopen("foo","rb");
stat("foo",&fs);
fsize=fs.st_size;
for(i=0;i<fsize;i++){
fread(&c,1,1,fin);
printf("%c",c);
}
return EXIT_SUCCESS;
}


>>Do you also think that no one should be interested in a
utility program that will overwrite a file completely where each
BIT is overwritten first with one's (every byte to 11111111) and
then the entire file is overwritten again with zeros (every byte
to 00000000) to effectively wipe out any trace of the original
data contained in the file?

#include <...>

int main(void)
{
FILE *fin;
struct stat fs;
int arr[256];
int fsize;
int i;
char c;

stat("foo",&fs);
fin=fopen("foo","wb");
fsize=fs.st_size;
c=0xff;
for(i=0;i<fsize;i++){
fwrite(&c,1,1,fin);
}
fclose(fin);
fin=fopen("foo","wb");
c=0x00;
for(i=0;i<fsize;i++){
fwrite(&c,1,1,fin);
}

fclose(fin);
return EXIT_SUCCESS;
}


>>Damn, nearly everyone in this news group must be shaking their
heads in awe for your awesome mental powers to know what they
should NOT have and what they should think yet without offering
one shred of factual support for your position regarding OAP-L3.
I'm certainly shaking my head, but for a different reason.


>>Hallelujah!
Indeed.



* 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: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Beginner Help ?
Date: Sun, 20 Feb 2000 18:49:09 -0500


Assuming your plain text is not in single bytes, or 8bit blocks, you could
break it up into 8bit blocks in several ways.  For example in C...

unsigned long int Plaintext;
unsigned char Plaintext_8bit[4];

memcpy(Plaintext_8bit, &Plaintext, 4);

Since unsigned long int is a 32bit (or 4 bytes) variable all you have to do
is copy it into an array of chars of the correct size, and then you have
your plaintext in an array of 8bit variables.  If you wanted to get creative
you could use bit shifts plus some casting and avoid the memcpy() all
together.

Plaintext_8bit[0] = (unsigned char) (Plaintext >> 24);
Plaintext_8bit[1] = (unsigned char) (Plaintext >> 16);
Plaintext_8bit[2] = (unsigned char) (Plaintext >> 8);
Plaintext_8bit[3] = (unsigned char) Plaintext;

Either way will result in the same thing.

- Adam Durana

"Norman Little" <[EMAIL PROTECTED]> wrote in message
news:88pdsb$m7g$[EMAIL PROTECTED]...
> Hi,
>
> I have undertaken a cryptography assignment for my final year at
University.
>
> The plan is to write JAVA applets that "demonstrate" the various
encryption
> algorithms.  This has varied from the very old ciphers such as caesar,
> playfair, and vigenere....etc and now I am moving onto DES and RSA etc.
>
> The problem is, the books I am reading on DES, they explain the algorithms
> in terms of dividing the plaintext into 8-bit blocks.  The reduced block
> size is to help understand the algorithm.  Anyway, what I would like to
> know, is if anyone can help me how to split my plaintext up into 8-bit
> blocks or whatever, or even if there is a way for me to demonstrate this
by
> dividing the message into characters.....
>
> I am not sure how I would divide my message in the way the book
details....
>
>
>
> thanks
>
>
> Norman
>
>



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

From: JCA <[EMAIL PROTECTED]>
Subject: Who is using ECC?
Date: Sun, 20 Feb 2000 15:38:16 -0800


    I'd be interested to learn who is using ECC. I am aware that it is
far less well-known than RSA,
and that not many certificate authorities issue ECC- (ECDSA) based
certificates yet, these two
factors working against its usage. However, I wonder if people working
on smartcards, cell phones
and similarly resource-constrained environments are already using it on
an industrial scale.

    Any pointers will be welcome.



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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Keys & Passwords.
Date: Sun, 20 Feb 2000 17:05:56 -0600

In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:

> wtshaw wrote:
> > 
> 
> > Welcome to display in a convenient base, base 16 or 64 being the most
common.
> 
> One has to write a little bit of code or script to convert the
> hex output of hashing to the set of characters one chooses to use.
> That's some work and needs some bit of thought to get a satisfactory
> solution.
> 
It's not all that bad.  The whole business about base translations is
aimed at finding optional satisfactory base solutions that one may choose
from.  Diffulty of doing that varies somewhat.
-- 
Let's all sit back an watch the inhabitants of the political zoo 
perform in three rings.  It's more exciting than soap operas.  Then 
vote out anyone who has been in long enough to abuse things.  

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


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