---

Dette program er unikt til at sikre e-mail og dokument overførsel. Det
anvender både RSA kryptering og One Time Pad, hvilket ikke er set før. Har
arbejdet meget med programmet og kan anbefale det til dig der vil have det
bedste.

TOP SECRET CRYPTO

The Most Powerful Data Encryption Program in the World

Until now, unbreakable encryption methods have been possessed by only a few
government agencies, such as the National Security Agency (NSA) and the
Soviet KGB. With Top Secret Crypto you now have that ability. Privacy
maintained by mathematical law is now a reality.

THE PROGRAM: Top Secret Crypto uses the RSA Public Key Encryption Algorithm
with a key space, or Modulus n size, of 480 to 8,192 bits. Its conventional
encryption algorithm is based upon the One Time Pad Encryption System, which
is considered Unbreakable in Theory and Practice when used correctly.

The One Time Pad Encryption System can use two types of Session Keys. The
first type is for one or more recipients and seeds 4, 8, 16, 32, or 64
pseudo random number generators with a key space of 325-353, 613-669,
1,189-1,301, 2,341-2,565, and 4,645- 5,093 bits respectively. The number of
pseudo random number generators used depends on the smallest RSA Key used.

The second type of Session Key is for one recipient only, and is a One Time
Pad Key File which is comprised of 1,303 randomly generated numbers between
100,000,001 and 4,294,967,295. 768 of these numbers are randomly chosen to
seed 256 pseudo random number generators with a key space of 18,469 to
20,261 bits. Both sender and recipient must have a copy of the file. See the
Images page for a few screen shots of what the program looks like.

Top Secret Crypto Features

Rsa Key sizes from 480 to 8,192 bits.

The conventional cipher is based upon the One Time Pad Encryption System,
which, if used correctly, is considered unbreakable in theory and practice,
i.e. the One Time Pad Key File is used to encrypt with.

Depending on the type of Session Key used (see above), conventional key
sizes can range from 325 to 20,261 bits.

Full featured Win32 program using the new HTML Help System.

Manage your Key Rings with a friendly and easy to use interface.

Compress one or more files before you encrypt them for transmission. The
provided compression procedures take the Limpel-Ziv-Welch (LZW) data
compression algorithm to new heights. Depending on the amount of memory your
computer has, it can output code sizes starting at 9 bits and go all the way
up to 24 bits.

Specify the number of separation bits between Primes p and q. It can range
from 0 to 64 bits. This makes it very difficult for anyone to mount a
concerted attack on factoring Modulus n.

Specify the validity period for the Public and Secret Keys. It can range
from forever to 65,535 days.

All Public Keys you make are automatically signed by the Secret key, which
ensures the validity of the Public Key to anyone who uses it.

Provides a continuously changing pool of 65,536 random bits used in the
generation of Primes p and q, in the generation of One Time Pad Key Files,
and to construct keys for the pseudo random number generators.

Send an encrypted file to one or many recipients.

Conduct Phi and Chi tests on your encrypted files to see how well the
encryption algorithm really works.

Generate and print One Time Pads for secure hand written correspondence.


http://www.topsecretcrypto.com


A. Nobel Denmark.

---

"awn" <awn@sol.dk> writes:

> Dette program er unikt til at sikre e-mail og dokument overførsel. Det
> anvender både RSA kryptering og One Time Pad, hvilket ikke er set før. Har
> arbejdet meget med programmet og kan anbefale det til dig der vil have det
> bedste.

Lad mig på forhånd unskylde, hvis der sniger sig lidt sarkasme ind i
mine kommentarer.

Lad os finde vores crypto-buzzword-bingoplader frem, og høre efter...

> TOP SECRET CRYPTO
>
> The Most Powerful Data Encryption Program in the World
>
> Until now, unbreakable encryption methods have been possessed by only a few
> government agencies, such as the National Security Agency (NSA) and the
> Soviet KGB. With Top Secret Crypto you now have that ability.

PGP er ikke 'unbreakable', men jeg vil gætte på, at sikkerheden er
bedre end i dette program.

> Privacy maintained by mathematical law is now a reality.

One time pads er teoretisk set umulige at knække. Dette program
implementerer ikke one time pads.

> THE PROGRAM: Top Secret Crypto uses the RSA Public Key Encryption Algorithm
> with a key space, or Modulus n size, of 480 to 8,192 bits. Its conventional
> encryption algorithm is based upon the One Time Pad Encryption System, which
> is considered Unbreakable in Theory and Practice when used correctly.

Rigtigt, 'when used correctly'...

> The One Time Pad Encryption System can use two types of Session Keys. The
> first type is for one or more recipients and seeds 4, 8, 16, 32, or 64
> pseudo random number generators with a key space of 325-353, 613-669,
> 1,189-1,301, 2,341-2,565, and 4,645- 5,093 bits respectively. The number of
> pseudo random number generators used depends on the smallest RSA Key used.

Man kan ikke generere en OTP med en pseudo-random number generator.

Dette program benytter en kombination af RSA (som er udmærket), og en
tilsyneladende hjemmelavet symmetrisk algoritme, som ikke har noget
med one time pads at gøre. Hjemmelavede algoritmer bliver ofte
knækket, hvis der er noger, der gider prøve.

Jeg ville holde mig til PGP.

/stoklund

---

Jeg har ind i mellem når jeg har læst nyhedsgrupper undret mig over hvordan
man bliver tiltalt og får svar på/fra en sådan gruppe. F. eks var der en i
en gruppe der spurte pænt om der var omtalt noget specielt i en given bog,
og svaret var mere eller mindre i retning af - Læs bogen. En lidt mere
seriøs, venlig og pæn måde at svare på kunne være ønskelig.

Jeg har som awn også prøvet ( og bruger det til daglig ) TSC fra
topsecretcrypto.com og må sige at det lever fint op til hvad det lover. Men
det kræver at man henter programmet og læser den omfattende dokumentation
der følger med, for at forstå hvordan OTP funktionen virker. Det er korrekt
når vi taler om OTP (One Time Pad) er det perfekte en "key" der er absolut
random og så lang som meddelelsen, og den må kun bruges 1 og kun en gang.
Jeg syntes at man i TSC har fundet en passende måde at indfører OTP
funktionen på. Man genererer et passende antal "OTP Filer" og skal med "
Kurrer" give sin modpart et kopi af disse filer. Der kan være omkring 250 på
en diskette. Som i PGP krypteres det du skal have krypterer ( din plain
tekst ) med en Symmetrisk ( eller singel key ) algoritme og det er Nøglen
til denne der krypteres med RSA algoritmen. Dette fordi RSA er en så langsom
funktion at det i praksis ikke er muligt at benytte den til at krypterer
hele dokumentet. Det fungerer på nøjagtig samme måde i TSC når man vælger
kun at benytte denne funktion, dog med den fordel at længden på den singel
key samt på RSA nøglen er betydeligt større. Her har man altså mulighed for
at sende og modtage post fra personer man ikke kender og har udvekslet
nøgler med, nøjagtig som i PGP.

Når der benyttes OTP filer er det en meget større "Key", altså start nøgle
til den symmetriske algoritme der anvendes, nemlig 20.000 bit. Det
interessante her er at det kun er navnet på OTP nøglen der krypteres med RSA
krypteringen, nøglen til at afkode den symmetriske kryptering følger altså
ikke "brevet" krypteret med RSA, men kun navnet på den. Dvs. at selv om man
evt. kunde knække RSA krypteringen så kan man ikke dekrypterer dokumentet.
Når du modtager brevet dekrypterer RSA navnet på den OTP fil der er brugt
til at krypterer med og den fremskaffes nu for dekryptering. Når det er sket
Wipes den som afsenderen også gjorde og den kan derfor ikke anvendes igen.
Det har også den Store fordel at den krypterede post der evt. skulde være
NOGLE der har opsnappet og efterfølgende vil dekrypterer når de har
konfiskeret din PC og har fundet dit password, ja hvad tror du, det kan de
ikke, for OTP filerne til de pågældende breve mangler og det er derfor ikke
muligt selv med det rette password og nøglefilerne at dekrypterer brevet.

Hvordan de 20.000 bit fra OTP filen starter TSC op til at genererer en
passende random nøgle til at krypterer dit dokument med forklares bedst hvis
man læser den velskrevne vejledning. Og efter at have læst hvordan det sker
og evt. afprøvet det i praksis kan man komme med en seriøs vurdering på
awn´s udmærkede lille "annonce" for TSC.

Jeg kender ikke awn men vil sige til dig at jeg også er faldet over
programmet og er blevet meget glad for det. Når man lige har sat sig ind i
hvordan det fungerer så er det faktisk meget nemt og især overskueligt at
bruge. Samtidig er det et program der ikke har så mange fansi ekstra
funktioner, men kun lige det der skal til.

Det kunde da være spændende hvis der var nogle her på denne nyhedsgruppe der
seriøst kunde teste om det der hævdes i programmet virkelig holder vand. Og
hermed mener jeg ikke kun en overfladisk og lidt overlegen betragtning, men
en seriøs undersøgelse af om det er et program som vi alle sammen kunde have
gavn af og kan stole på. Jeg tror selv på at det er praktisk ubrydeligt når
det anvendes til det formål det har, nemlig at beskytte et dokument fra
punkt A til punkt B.

Lad os få en seriøs debat.

Venligst

Peter Nielsen DTU/Lyngby

---

In article <PO9S6.17706$dS3.939491@news010.worldonline.dk>, Peter Nielsen wrote:

> Jeg har ind i mellem når jeg har læst nyhedsgrupper undret mig over hvordan
> man bliver tiltalt og får svar på/fra en sådan gruppe. F. eks var der en i
> en gruppe der spurte pænt om der var omtalt noget specielt i en given bog,
> og svaret var mere eller mindre i retning af - Læs bogen. En lidt mere
> seriøs, venlig og pæn måde at svare på kunne være ønskelig.

Jeg tror du misforstår, hvad der blot er kritiske holdninger. Ihvertfald
har mine få indlæg i denne gruppe blot handlet om at man ikke bør købe
eller sælge "snake oil". At de så er blevet taget meget personligt af
modtageren er jo uheldigt, men det tolker jeg blot som at personen ikke
har kendskab til, hvad det vil sige at skrive krypto-software.

> Jeg har som awn også prøvet ( og bruger det til daglig ) TSC fra
> topsecretcrypto.com og må sige at det lever fint op til hvad det lover. Men
> det kræver at man henter programmet og læser den omfattende dokumentation
> der følger med, for at forstå hvordan OTP funktionen virker.

Det der blev postet her var skrevet, så det efterlod et indtryk både hos
mig og hvem-det-nu-end-var-der-svarede af at det folkene bag programmet
kaldte for OTP i virkeligheden ikke var dette.

> Lad os få en seriøs debat.

Jatak, men det kræver at de folk der deltager i debatten tager andre
folks spørgsmål seriøst.

--
Andreas Plesner Jacobsen | NOBODY EXPECTS THE SPANISH INQUISITION!

---

Andreas Plesner Jacobsen <apj@daarligstil.dk> skrev i en
nyhedsmeddelelse:slrn9hiaqg.of.apj@slartibartfast.nerd.dk...
> In article <PO9S6.17706$dS3.939491@news010.worldonline.dk>, Peter Nielsen
wrote:
>
> Jeg tror du misforstår, hvad der blot er kritiske holdninger. Ihvertfald
> har mine få indlæg i denne gruppe blot handlet om at man ikke bør købe
> eller sælge "snake oil". At de så er blevet taget meget personligt af
> modtageren er jo uheldigt, men det tolker jeg blot som at personen ikke
> har kendskab til, hvad det vil sige at skrive krypto-software.

Nu er det en af de første gange jeg skriver til en nyhedsgruppe og derfor
skulle jeg lige af med min mening om de svar jeg ofte har læst på disse
nyhedsgrupper. Jeg tror at awn ville gøre opmærksom på at programmet
eksisterer og det er nok meningen at man skal sætte sig lidt mere ind i
funktionerne i programmet inden man dømmer det ude. .

>
> Det der blev postet her var skrevet, så det efterlod et indtryk både hos
> mig og hvem-det-nu-end-var-der-svarede af at det folkene bag programmet
> kaldte for OTP i virkeligheden ikke var dette.

Det er en stream cipher funktion der er tale om, men den bruger nogle
startnøgler som kun bruges den ene gang og derfor minder om OTP filer. Om
det så er så sikkert som man hævder kunde jo vare spændende at undersøge.

> > Lad os få en seriøs debat.
>
> Jatak, men det kræver at de folk der deltager i debatten tager andre
> folks spørgsmål seriøst.

Det har du ganske ret i, men lad os ikke lade dette køre af sporet, men
finde ud af om der er nogle her på denne gruppe der er i stand til at teste
det program så vi kunde få afklaret om det er så kraftig en kryptering som
der hævdes. Jeg har brugt programmet sammen med nogle kollegaer som var i
udlandet og også privat og det fungerer upåklageligt uden den mindste fejl.
Men for at give en seriøs vurdering er man nød til at sætte sig helt ind i
hvordan det foregår og der er i hjælpemenuen beskrevet i detaljer hvordan
det sker.


Venligst Peter Nielsen.


> --
> Andreas Plesner Jacobsen | NOBODY EXPECTS THE SPANISH INQUISITION


!

---

"awn" <awn@sol.dk> writes:

> The Most Powerful Data Encryption Program in the World
<snip>
> Soviet KGB. With Top Secret Crypto you now have that ability. Privacy
> maintained by mathematical law is now a reality.
<snip>
> encryption algorithm is based upon the One Time Pad Encryption System, which
> is considered Unbreakable in Theory and Practice when used correctly.

<etc...>

Se:
http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

---

Det er meget nemt at henvise til:
http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

Men den slags informationer er jo det første man kaster sig over når
man har interesse for kryptografi.

Nu er jeg nok den eneste af dem der har svaret på awns indlæg der også har
arbejdet med
programmet og især har læst den dokumentation der følger med. Der er i
øvrigt et helt afsnit
med programkode i hjælpemenuen, men jeg har ikke et så godt kendskab til
programmering
så jeg er i stand til at vurderer det.

I stedet for smarte bemærkninger som fremkommer ud fra det materiale som awn
lagde ind på denne nyhedsgruppe ( formentlig som en reklame for programmet )
syntes jeg man må forvendte et seriøst indlæg som indebærer at man tester
programmet og undersøger hvordan det fungerer.
Ud fra det kunde man diskuterer om der var nogle ting i programmet der måske
kunde ændres eller tilføjes. De udtagelser der er fremkommet ind til nu
vidner om arrogance og manglende interesse i at sætte sig ind i et nyt og
spændende program.

Peter Nielsen

---

On Sun, 3 Jun 2001 22:08:17 +0200, Peter Nielsen <PDN@ofir.dk> wrote:
> I stedet for smarte bemærkninger som fremkommer ud fra det materiale som awn
> lagde ind på denne nyhedsgruppe ( formentlig som en reklame for programmet )
> syntes jeg man må forvendte et seriøst indlæg som indebærer at man tester
> programmet og undersøger hvordan det fungerer.

Folks største problem er nok, at der blev reklameret med, at det
bruger OTP. Medmindre der kommer noget hardware ud af floppydrevet,
når man har hentet programmet, bruger det ikke OTP. Slut prut.

Hvis man ser bort fra det, kan det sikkert være et udmærket program.
Men ser man bort fra det, kan man jo (næsten) lige så godt lade
være med at bruge kryptering i det hele taget... eller bare XOR'e
sine data med 42.

Mvh.
   Klaus.

---

klaus@ellegaard.dk (Klaus Ellegaard) wrote:

>On Sun, 3 Jun 2001 22:08:17 +0200, Peter Nielsen <PDN@ofir.dk> wrote:
>> I stedet for smarte bemærkninger som fremkommer ud fra det materiale som awn
>> lagde ind på denne nyhedsgruppe ( formentlig som en reklame for programmet )
>> syntes jeg man må forvendte et seriøst indlæg som indebærer at man tester
>> programmet og undersøger hvordan det fungerer.
>
>Folks største problem er nok, at der blev reklameret med, at det
>bruger OTP. Medmindre der kommer noget hardware ud af floppydrevet,
>når man har hentet programmet, bruger det ikke OTP. Slut prut.
>
>Hvis man ser bort fra det, kan det sikkert være et udmærket program.

Ja, men i krypteringsverdenen har man jo brug for at vurdere om dem der laver et program,
har forstand på det de gør. Hvis de ikke har forstand på det, så er deres program
sandsynligvis noget bras selvom det er forfærdelig svært (evt. umuligt for menigmand) at
se på programmet selv at det ikke er godt. NSA kan sikkert ved at bruge nogen tid se på
en krypteringsprogram om det er godt - det kan vi andre ikke, så vi bliver nødt til at
bruge en leverandør vi stoler på.

Fx ville jeg aldrig drømme om at bruge et krypteringsprogram hvis dets leverandør:
* ikke røber hvilken anerkendt krypteringsalgoritme programmet bruger (som i et nyligt
eksempel her i gruppen), eller
* kommer med noget vås om one-time-pads (som i dette eksempel).

--
Jesper Dybdal, Denmark.
http://www.dybdal.dk (in Danish).

---

"Peter Nielsen" <PDN@ofir.dk> wrote in
news:MOwS6.585$R84.121982@news010.worldonline.dk:

> Det er meget nemt at henvise til:
> http://www.interhack.net/people/cmcurtin/snake-oil-faq.html
>
> Men den slags informationer er jo det første man kaster sig over når
> man har interesse for kryptografi.
>
> Nu er jeg nok den eneste af dem der har svaret på awns indlæg der også
> har arbejdet med
> programmet og især har læst den dokumentation der følger med. Der er i
> øvrigt et helt afsnit
> med programkode i hjælpemenuen, men jeg har ikke et så godt kendskab
> til programmering
> så jeg er i stand til at vurderer det.
>

netop dette burde du måske overveje lidt. At du har arbejdet med program fra
brugersiden er ikke det samme som at kunne vurdere om programmet er sikkert.


--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk

---

Jeg har læst dette i vejledningen til programmet. Hvad er jeres mening om
dette.? Det er bla. dette
der har overbevist mig om at det er et udmærket og sikkert program.

Peter Nielsen.



The Random Bits Bin - A True Source of Random Bits

The Random Bits Bin is a file called RandomBitsBin.rbb that is created and
maintained by Top Secret Crypto. It is 8,192 bytes, or 65,536 bits, long,
and once it is read into memory, it is constantly being changed by Top
Secret Crypto. Any time a seed, key, or numeric value, such as Prime p or q,
is required by Top Secret Crypto, it is extracted from somewhere within the
Random Bits Bin. When you exit the program, the RandomBitsBin.rbb file is
updated with the current contents of the Random Bits Bin in memory, thus
creating a new RandomBitsBin.rbb file for the next time you use Top Secret
Crypto.

The big question everyone is asking themselves right now is, how can a
computer be a source of random bits?

Every computer has a system timer. In the case of most Intel® computers, it
beats with a frequency of 1.193 million times per second. This system timer,
or high resolution performance timer, can be read by any computer program.

Top Secret Crypto sets up, and runs, a separate thread whose sole function
is to read the system timer and update the Random Bits Bin. Since the thread
does not have control all the time, there is no way of predicting the value
in the system timer when the thread does get control. The first time the
system timer is read, its low 8 bits are XNORed with the first 8 bits of the
Random Bits Bin. The next time it is read, the next 8 bits are XNORed with
the low 8 bits of the system timer. When you reach the end of the Random
Bits Bin, you start over at the beginning.

Due to the speed of the computer, the entire contents of the Random Bits Bin
may change many thousands of times per second. To prove my point, fire up
Top Secret Crypto and let it run for only a second or two. Take a look at
the contents of the RandomBitsBin.rbb file and you will see how random the
data in it is.



Initial Conditions - Or How to Tell a Good Encryption Formula

Most pseudo random number generators can produce a long string of random
numbers, or characters, to encrypt a file with. What we want to determine is
what makes a good pseudo random number generator, or another way to put it
is what pseudo random number generator makes a good encryption formula.

A complex encryption formula seems like a good idea. But that is forgetting
one of the basic rules of cryptography: The General System is known - to
everyone. If you buy a commercial encryption program that is sold over the
counter, you have the general system for that product. You do not even have
to understand its complex encryption process. The program does it all for
you. DES has a very complicated encryption formula, but only a 56-bit key.
It can be broken with ease. It also burns up computer cycles and takes a
long time, relatively, to encrypt or decrypt a file.

The only thing left is the seed, key, or what I call the Initial Conditions
that start the pseudo random number generator in the encryption formula
going. The larger the number of seeds that can start an encryption formula,
the better. DES with its 56-bit key is no good. 2 to the 56th power equals
7.205 times 10 to the 16th power. PGPT uses the IdealT Encryption Formula,
which uses a 128-bit key. 2 to the 128th power equals 3.402 times 10 to the
38th power. It you believe Tom Clancy in Rainbow Six this is not even good
enough any more. Depending on the size of the smallest RSA Key used, Top
Secret Crypto will seed 4, 8, 16, 32, or 64 random number generators, which
require 325-353, 613-669, 1189-1301, 2341-2565, or 4645-5093 random bits as
the key, when sending an encrypted file to multiple recipients. As long as
the NSA cannot break the RSA Public Key Encryption System, these key sizes
should be sufficient. But in case they are not...

This is why Top Secret Crypto includes a second method for seeding its
pseudo random number generators, or encryption formula. It can create One
Time Pad (OTP) Key Files, each of which contains 1,303 randomly generated
numbers in the range 100,000,001 to 4,294,967,295. Each number is 32 bits
long. From the 1,303 random numbers in an OTP Key file, 768 numbers are
randomly selected to seed the 256 pseudo random number generators used in
the encryption process. 512 of the 768 random numbers use the full 32 bits
for 16,384 bits. The other 256 are shifted right by a factor of 17 to 24
leaving 8 to 15 bits. This gives you 2,048 to 3,840 more bits. Add in 37
more for an initial seed and random factor array shift valve for a final
total of somewhere between 18,469 and 20,261 bits used as the Initial
Condition for the 256 pseudo random number generators. This is a number
between 2 to the 18,469th power and 2 to the 20,261st power. Using
logarithms, this works out to a number between 5.284 times 10 to the 5,559th
power and 1.474 times 10 to the 6,099th power.

For anyone to duplicate this string of 18,469 to 20,261 bits from an OTP Key
file without the original file would require a miracle in the absolute true
sense of the word. Not knowing exactly how many bits are used each time you
encrypt a file is another hurdle for the would be cryptanalyst to overcome
when trying to decrypt the file.


The One Time Pad Encryption System

It was first developed in America in 1918, completely rejected by the U.S.
Government, and first used by the German diplomatic establishment sometime
between 1921 and 1923. It is called the One Time Pad System. It is a
remarkable system in its simplicity. For further information see pages 398
to 400 of the hardback edition of The CODEBREAKERS by David Kahn, published
by The Macmillan Company in 1967. It consists of a random key used once, and
only once. It provides a new and unpredictable key character for each
plaintext character in the message. This means that every letter or
character is enciphered with its own random key. The letter A may be
enciphered into a Z the first time it is encountered in the message and into
an N the next time, a B the next, and so on and so on. This means for a
message that is enciphered as Z T Q W the first Z could be deciphered into
any of the 26 letters of the alphabet. This holds true for all the other
letters also. This could be deciphered into the word L O O K where both the
T and the Q stand for the letter O.

I quote: "And it is an unbreakable system. Some systems are unbreakable in
practice only, because the cryptanalyst can conceive of ways of solving them
if he had enough time. The one-time system is unbreakable both in theory and
practice. No matter how much text a cryptanalyst had available in it, or how
much time he had to work on it, he could never solve it."

I quote again: "The perfect randomness of the one-time system nullifies any
horizontal, or lengthwise, cohesion, as in coherent running key or autokey,
and its one-time nature bars any vertical assembly in Kasiski or Kerckhoffs
columns, as in keys repeated in a single message or among several messages.
The cryptanalyst is blocked."


If you were to use the brute force method and try to decipher this message
with every possible key combination all you would have done is compile a
list of every possible four letter word in the world. There are stop, hard,
slow, kiss, etc., etc., etc. The longer the message the more possibilities
there are. What it boils down to is that you have an equation in two
unknowns with only 1 equation, and that is impossible to solve. X + Y = 9.
You know that 9 is the ciphertext. Without another equation there is no way
to solve X (the plaintext) or Y (the key). X and Y could be any values you
choose that equal 9. All this does is compile a long list of possible
solutions with one just as good as the other. Since there are an infinite
number of numbers there are an infinite number of solutions to the above
equation. One could be just as valid as the other. There is no way to know
which one is right.

In this age of computers why is this One Time Pad System not in widespread
use? Could it be the fact that computers cannot generate random numbers. All
they can generate is pseudo-random numbers. This means that the string of
random numbers produced by one computer can be reproduced by that or another
computer using the same formula. But this is exactly what is required by any
computer program to encipher data. You need to be able to reproduce that
same set of random numbers to decipher the data.

There are many formulas to generate pseudo-random numbers on computers. But
even this is not enough. Most of these formulas only require a small seed
number to get the formula going. This is the key to why these formulas and
other encryption formulas are no good. Remember this:

NO MATTER HOW INTRICATE OR COMPLEX ANY DATA ENCRYPTION FORMULA IS, IF THE
SEED NUMBER TO START THE FORMULA IS SMALL, THAT ENCRYPTION FORMULA CAN BE
VERY EASILY CRACKED BY THE BRUTE FORCE METHOD.

Just plug in all possible seed numbers into the formula using a super
computer and within a matter of hours any message can be decoded. This is
the bane of most encryption formulas. They try to keep the seed number small
by using very complex and lengthy formulas because human beings, you and me,
do not like to enter 100 and 200 digit seed numbers into a computer every
time we have to encipher or decipher a message. The small seed number is
their Achilles Heel.

To see how Top Secret Crypto gets around this problem see Initial
Conditions - Or How to Tell a Good Encryption Formula.

The key to being true to the One Time Pad Encryption System is to always use
One Time Pad Key Files to encrypt your files, and to use a One Time Pad Key
File only once. This ensures that every enciphered message will have a
unique key, which means a unique string of pseudo random characters that is
just as long as the file. If you follow this simple rule, any message that
is intercepted will not be able to be broken or analyzed in any way.

While this may prove a little inconvenient at times, especially if two
people live on opposite sides of the world, it is the only way to ensure
that your encrypted data is 100% safe.

Top Secret Crypto provides a method of generating hundreds, or thousands, of
One Time Pad Key Files at one setting, on a hard drive, a floppy disk, or CD
you can write to, so two people do not have to constantly exchange One Time
Pad Key Files with all the risks that this entails. See Tips on Using Top
Secret Crypto in the Real World for some ideas on how to accomplish this.

---

On Mon, 4 Jun 2001 11:14:36 +0200, "Peter Nielsen" <PDN@ofir.dk>
wrote:

>Jeg har læst dette i vejledningen til programmet. Hvad er jeres mening om
>dette.? Det er bla. dette
>der har overbevist mig om at det er et udmærket og sikkert program.
Man kan skrive hvad som helst i vejledningen. Skriver de noget om at
uafhænge eksperter har testet programmet?

---

In article <7oIS6.998$R84.252195@news010.worldonline.dk>, Peter Nielsen wrote:

> The Random Bits Bin - A True Source of Random Bits
>
> The Random Bits Bin is a file called RandomBitsBin.rbb that is created and
> maintained by Top Secret Crypto. It is 8,192 bytes, or 65,536 bits, long,

En computer _kan_ ikke generere fuldstændig tilfældige tal. Det er
faktisk en del af dens grundfunktion at den ikke kan dette.

--
Andreas Plesner Jacobsen | Please take note:

---

On Mon, 4 Jun 2001 11:14:36 +0200, Peter Nielsen <PDN@ofir.dk> wrote:
> Jeg har læst dette i vejledningen til programmet. Hvad er jeres mening om
> dette.? Det er bla. dette
> der har overbevist mig om at det er et udmærket og sikkert program.
....
> The Random Bits Bin is a file called RandomBitsBin.rbb that is created and
> maintained by Top Secret Crypto. It is 8,192 bytes, or 65,536 bits, long,
> and once it is read into memory, it is constantly being changed by Top
> Secret Crypto.

Allerede hér slutter festen: der er ikke tale om tilfældige værdier,
men værdier der er blevet til ved hjælp af algoritmer.

Det kan godt være, at det er komplekst at backtracke, men omvendt kan
der være defekter i algoritmen, der gør, at der måske kun er et lille
antal muligheder (as in, et par tusinde trilliarder muligheder). Hvem
ved? Hvor er dokumentationen for, at der ikke er en kodefejl, der gør
det trivielt?

Under alle omstændigheder: de påstår, at de bruger OTP. OTP kræver
tilfældige tal. Tilfældige tal er ikke noget, man laver ud fra en
algoritme. Altså bruger den *ikke* OTP.

> Take a look at the contents of the RandomBitsBin.rbb file and you
> will see how random the data in it is.

Okay, det er jo helt til grin.

Nej, man kan ikke se det med det blotte øje. Det vil ikke se værre
eller bedre ud, end hvis man brugte standard random-generatoren i
standardbiblioteket.

> Most pseudo random number generators can produce a long string of random
> numbers, or characters, to encrypt a file with. What we want to determine is
> what makes a good pseudo random number generator, or another way to put it
> is what pseudo random number generator makes a good encryption formula.

Pseudo = ikke-OTP. Om den så er "dårlig ikke-OTP" eller "god
ikke-OTP" kan vel næsten komme ud på ét.

Noget helt andet er: enten kan det frit eksporteres fra USA, fordi
det er noget skidt. Eller også er det godkendt til eksport (hvilket
kunne betyde - men ikke nødvendigvis betyder - at der er en bagdør).
Eller som en sidste mulighed er det kriminelt at eksportere det fra
USA.

Har du undersøgt hvilken af ovenstående, der gælder for produktet?

> 38th power. It you believe Tom Clancy in Rainbow Six this is not even good
> enough any more.

Yes! Argumentere på basis af fiktion. Dét er noget, der rykker

> I quote: "And it is an unbreakable system. Some systems are unbreakable in
> practice only, because the cryptanalyst can conceive of ways of solving them
> if he had enough time. The one-time system is unbreakable both in theory and
> practice. No matter how much text a cryptanalyst had available in it, or how
> much time he had to work on it, he could never solve it."

HVIS der er tale om tilfældige tal og ikke pseudo-tilfældige tal.
De skriver selv ovenfor, at de bruger pseudo-tilfældige tal. Ergo
duer ovenstående citat ikke, for forudsætningerne er ikke til stede.

> I quote again: "The perfect randomness of the one-time system nullifies any

Bingo! "Perfect randomness" vs. "pseudo-random". De skriver det jo
ligefrem selv

Mvh.
   Klaus.

---

klaus@ellegaard.dk (Klaus Ellegaard) wrote in
news:slrn9hmsl2.11p.klaus@dustpuppy.worldonline.dk:

> On Mon, 4 Jun 2001 11:14:36 +0200, Peter Nielsen <PDN@ofir.dk> wrote:
>> Jeg har læst dette i vejledningen til programmet. Hvad er jeres mening
>> om dette.? Det er bla. dette
>> der har overbevist mig om at det er et udmærket og sikkert program.
>> ... The Random Bits Bin is a file called RandomBitsBin.rbb that is
>> created and maintained by Top Secret Crypto. It is 8,192 bytes, or
>> 65,536 bits, long, and once it is read into memory, it is constantly
>> being changed by Top Secret Crypto.
>
> Allerede hér slutter festen: der er ikke tale om tilfældige værdier,
> men værdier der er blevet til ved hjælp af algoritmer.
>
> Det kan godt være, at det er komplekst at backtracke, men omvendt kan
> der være defekter i algoritmen, der gør, at der måske kun er et lille
> antal muligheder (as in, et par tusinde trilliarder muligheder). Hvem
> ved? Hvor er dokumentationen for, at der ikke er en kodefejl, der gør
> det trivielt?
>
> Under alle omstændigheder: de påstår, at de bruger OTP. OTP kræver
> tilfældige tal. Tilfældige tal er ikke noget, man laver ud fra en
> algoritme. Altså bruger den *ikke* OTP.
>
>> Take a look at the contents of the RandomBitsBin.rbb file and you
>> will see how random the data in it is.
>
> Okay, det er jo helt til grin.
>
> Nej, man kan ikke se det med det blotte øje. Det vil ikke se værre
> eller bedre ud, end hvis man brugte standard random-generatoren i
> standardbiblioteket.
>

hehe ... jeg må indrømme, at jeg også kom til at klukgrine lidt, da jeg så
denne del af dokumentationen.

Hvilken af disse strenge er mest tilfældig ?

0000000000000000000011111111111111111111

eller

1000101010110101110101101010101010011010

?

>
>> I quote again: "The perfect randomness of the one-time system
>> nullifies any
>
> Bingo! "Perfect randomness" vs. "pseudo-random". De skriver det jo
> ligefrem selv
>

jeg faldt lige over dette citat:

"I have developed an encryption software package that I can best describe as
a ONE-TIME-PAD GENERATOR."

(Anthony Stephen Szopa posting to sci.crypt, August 8, 1997)

Der er flere på http://www.scramdisk.clara.net/quotes.html


--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk

---

Den Thu, 7 Jun 2001 09:15:36 +0000 (UTC) skrev Jesper Stocholm:
>
>hehe ... jeg må indrømme, at jeg også kom til at klukgrine lidt, da jeg så
>denne del af dokumentationen.
>
>Hvilken af disse strenge er mest tilfældig ?
>
>0000000000000000000011111111111111111111
>
>eller
>
>1000101010110101110101101010101010011010
>
>?

Forudsat at vi snakker en rigtig tilfældig funktion (fx. kast med en
mønt (IRL that is)), så er der nøjagtig lige stor sandsynlighed for
at opnå dem begge.

Så på en måde kan man vel sige at de er lige tilfældige

Mvh
Kent
--
http://www.celebrityshine.com/~kfr/

---

kfr@fleggaard.dk (Kent Friis) wrote in message news:<9fo39o$682$2@sunsite.dk>...
> Den Thu, 7 Jun 2001 09:15:36 +0000 (UTC) skrev Jesper Stocholm:
> >
> >hehe ... jeg må indrømme, at jeg også kom til at klukgrine lidt, da jeg så
> >denne del af dokumentationen.
> >
> >Hvilken af disse strenge er mest tilfældig ?
> >
> >0000000000000000000011111111111111111111
> >
> >eller
> >
> >1000101010110101110101101010101010011010
> >
> >?
>
> Forudsat at vi snakker en rigtig tilfældig funktion (fx. kast med en
> mønt (IRL that is)), så er der nøjagtig lige stor sandsynlighed for
> at opnå dem begge.
>
> Så på en måde kan man vel sige at de er lige tilfældige
>

exactly my point - og netop derfor er det lidt mærkeligt med
formuleringen "Så kan du selv se, hvor tilfældige de er ..."



--
Jesper Stocholm
http://stocholm.dk

---

On Sat, 2 Jun 2001 08:57:12 +0200, "awn" <awn@sol.dk> wrote:

>Dette program er unikt til at sikre e-mail og dokument overførsel. Det
>anvender både RSA kryptering og One Time Pad, hvilket ikke er set før. Har
>arbejdet meget med programmet og kan anbefale det til dig der vil have det
>bedste.
Eksperterne i sci.crypt kan heller ikke lide programmet.

---

Spændende samtale I har her!

Når vi nu snakker om krypteringssoftware, hvilke disk-krypteringssoftware,
har I så erfaringer med? Jeg bruger selv BestCrypt der kan generere 256 bits
krypteringer, men findes der software som er bedre og evt. nemmere at
bruge - ikke at det er et problem.

Den eneste ulempe jeg lige kan komme på er, at man ikke kan gemme sine
Outlook mail mappe på den virtual disk, som bliver skabt af den "container"
BestCrypt laver.

Mit spørgsmål er så som skrevet før, om der findes programmer hvor:

1) der laves virtuale disks
2) man kan gemme sin Outlook mail mappe på den
3) og om sikkerheden er nok til at holde personer væk fra container filen
4) og til sidst om I har andre anbefalinger

- GateKeeper -
"Does anyone think that victory is possible without facing danger?"

---

"GateKeeper" <plu2@ofir.dk> wrote:

>Den eneste ulempe jeg lige kan komme på er, at man ikke kan gemme sine
>Outlook mail mappe på den virtual disk, som bliver skabt af den "container"
>BestCrypt laver.

Hvorfor ikke? Jeg har intet kendskab til BestCrypt, men den virtuelle
disk, du omtaler, får vel tildelt et drevbogstav, hvor man kan oprette
sin .pst-fil?


--
Allan Olesen, Lunderskov
Hvorfor er det kun Nej-sigerne, der må køre 55 i byen?

---

Det ville jeg også mene, men det lader ikke til at det er muligt. Programmet
påstår ellers, at alle programmer kan bruge on-the-fly teknologien som var
det et alm. drev.

- GateKeeper -

> >Den eneste ulempe jeg lige kan komme på er, at man ikke kan gemme sine
> >Outlook mail mappe på den virtual disk, som bliver skabt af den
"container"
> >BestCrypt laver.
>
> Hvorfor ikke? Jeg har intet kendskab til BestCrypt, men den virtuelle
> disk, du omtaler, får vel tildelt et drevbogstav, hvor man kan oprette
> sin .pst-fil?
>
>
> --
> Allan Olesen, Lunderskov
> Hvorfor er det kun Nej-sigerne, der må køre 55 i byen?

---

"GateKeeper" <plu2@ofir.dk> writes:
> Den eneste ulempe jeg lige kan komme på er, at man ikke kan gemme sine
> Outlook mail mappe på den virtual disk, som bliver skabt af den "container"
> BestCrypt laver.

Det må vist tilskrives Outlook. Det er sikkert en sikkerheds-feature at
man ikke kan gemme post på et netværksdrev, hvilket sikkert er alle drev
der ikke står i CMOS'en.

> Mit spørgsmål er så som skrevet før, om der findes programmer hvor:
>
> 1) der laves virtuale disks
> 2) man kan gemme sin Outlook mail mappe på den
> 3) og om sikkerheden er nok til at holde personer væk fra container filen
> 4) og til sidst om I har andre anbefalinger

Jeg har PGPdisk, som fulgte med PGP2.6.1i (international version).
Ikke at jeg bruger det til noget, men jeg har da en 100Mb fil et
sted jeg kan mounte hvis jeg vil. Om det kan snyde outlook ved jeg ikke,
men det kan nok bedre betale sig at lede efter en switch i Outlook
eller et eller adnet udokumenteret man kan bruge til at slå den slags
fra.

/L
--
Lasse Reichstein Nielsen - lrn@daimi.au.dk
This message may be reproduced freely for non commercial purposes.
"... but where do you want to go tomorrow?"

---

Nu må i lige huske at jeg ikke er programmøren, jeg læste awns indlæg og
ville derfor komme med mit syn på sagen da jeg selv har brugt programmet et
halvt års tid og syntes godt om det. Min tanke var også at der var nogle
kloge og hjælpsomme personer som kunde give en vurdering på programmets
styrke men det er åbenbart sværere end forventet, for alt hvad der er kommet
frem bliver forkastet.

Til Martin Schultz, du skriver: Man kan skrive hvad som helst i
vejledningen. Skriver de noget om at uafhænge eksperter har testet
programmet?
Til det kan jeg sige følgende: Hvis man skal vurderer programmet må man i
første omgang stole på hvad der står i vejledningen og så gå ud fra det, jeg
sendte det med fordi man der beskriver hvordan de forskellige ting
fremkommer og fungerer. Til det med eksperterne, ja arme programmør, prøv at
se hvordan programmet er blevet modtaget her, det bider jo sig selv i halen.
Hvordan vil du have at en ekspert skal teste programmet, se bare hvordan det
er gået her.

Til Klaus Ellegaard, Som jeg har forstået det er det en Amerikaner der bor
på Phillipinerne
og derfor er der ikke nogle begrænsninger i nøglestørrelsen. Det er nok også
derfor Zdnet.com
kun henviser til Topsecretcrypto.com for download af programmet, det må ikke
ligge på Zdnet.com
Så alt er altså ganske lovligt.

Jeg er Kemiker og skal derfor ikke gøre mig klog på dette felt, men jeg
havde enlig regnet med at der bare var een nysgerrig "ekspert" på denne
nyhedsgruppe som ville ulejlige sig med at downloade programmet og derved
kunde give en tilbagemelding om det var godt eller skidt, nu hvor awn har
bragt programmet op til debat. Det der ligger til grund for vurderingen af
programmet både her og på sci.crypt er de få "vildledende" oplysninger der
er kommet frem her.
Jeg har det selv på den måde at et nyt produkt kræver en ordentlig
undersøgelse før jeg siger noget negativt om det, men det kan man åbenbart
ikke regne med på dette felt. Det tyder på at nævne OTP svarer til at stikke
næsen ned i en flaske Ammoniakvand.

Nå men jeg har jo programmet og sender derfor de Source koder med som er
frigivet i hjælpemenuen, måske det kan bidrage til noget fornuftig, nu hvor
andre ikke har overskud til
at grave dem frem.

I øvrigt glæder det mig at der dog er nogle der svarer og interessere sig
lidt for kryptografi.

Venligst

Peter Nielsen.


Random Bits Bin Source Code
Before delving into the source code please read about the Random Bits Bin
and extracting random bits from the Random Bits Bin.
Random Bits Bin Setup Source Code
// Make sure we have a High Performance Counter in the system
// to generate random bits for the Random Bits Bin.
//...........................................................
if (!QueryPerformanceFrequency(&PerformanceCounter))
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOHPC,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
// Allocate the memory for the random bits bin.
//.............................................
pRandBitsBin = AllocateMemory(RBB_LENGTH);
if (pRandBitsBin)
{
// Initialize the memory to A5 hex
//................................
int i;
pMem = pRandBitsBin;
for (i = 0; i < RBB_LENGTH; i++)
*pMem++ = LOBYTE(LOWORD(FillChar));
}
else
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOMEM,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
// Create or open the Random Bits Bin file.
// ........................................
hFile = CreateMyFile((LPTSTR)&RandomBitsFile,GENERIC_READ |
GENERIC_WRITE,0,NULL,
OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
if (!hFile)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
// Determine if we opened or created the file. If we opened it,
// read the file into the random bits bin buffer. If we created
// it, write the initial buffer to disk.
//.............................................................
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
if (GetFileSize(hFile,NULL) != RBB_LENGTH)
{
if (MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_WRONGLGTH,
MB_USERICON | MB_OKCANCEL | MB_DEFBUTTON1,
MB_ICONQUESTION,lpszQuestion) == IDCANCEL)
{
return(FALSE);
}
else
{
SetEndOfFile(hFile);
bResult = WriteMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,RBB_LENGTH,
d_Write,NULL);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,MB_ICONHAND,
lpszStopSign);
return(FALSE);
}
}
}
else


bResult = ReadMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,
RBB_LENGTH,&dwRead_Write,NULL);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,MB_ICONHAND,
lpszStopSign);
return(FALSE);
}
}
}
else
{
bResult = WriteMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,RBB_LENGTH,
&dwRead_Write,NULL);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_ICONHAND,lpszStopSign);
return(FALSE);
}
}
bResult = CloseMyHandle((LPTSTR)&RandomBitsFile,hFile);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,MB_ICONHAND,lpszStopSign);
return(FALSE);
}
bUpdateRandBitsBin = TRUE;

// Start the thread that will handle the random bits bin.
// First create an event so we can tell the thread when to quit.
//..............................................................
hRBBEvent = CreateEvent(NULL,TRUE,FALSE,TEXT("RBB_SHUTDOWN_EVENT"));
if (!hRBBEvent)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOEVENT,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
hRBBThread = CreateThread(NULL,0,RandomBitsBinThread,hWnd,0,&dwRBBThreadId);
if (!hRBBThread)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOTHREAD,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
Update the Random Bits Bin File
The random bits bin file is updated with the current contents of the random
bits bin in memory just before you exit the program.
// Update the Random Bits Bin File using the Random Bits Bin in memory.
// We do not do any error checking because it should hardly ever fail.
//....................................................................
LRESULT CALLBACK UpdateRandBitsBinFile()
{
HANDLE hFile;
DWORD dwWrite;
BOOL bResult;
BOOL bReturnResult = FALSE;

if (bUpdateRandBitsBin)
{
// Stir up the bits before we write the bits bin to a file.
//.........................................................
StirTheBits();

// Open the file. It will always exist at this point.
//...................................................
hFile = CreateMyFile((LPTSTR)&RandomBitsFile,GENERIC_READ | GENERIC_WRITE,
0,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
if (hFile)


bResult = WriteMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,RBB_LENGTH,&dwWrite,NULL);
if (bResult)
{

bResult = CloseMyHandle((LPTSTR)&RandomBitsFile,hFile);
if (bResult)
{
bReturnResult = TRUE;
}
}
}
}
return(bReturnResult);
}



Random Bits Bin Thread Procedure
The following thread is created at the start of the program and runs
continuously, changing the random bits bin in memory. The only time it is
suspended is during RSA Key Generation to shorten the time is takes to
generate a set of RSA Keys.
What the code does is read the High Performance Counter, performs an xor
operation with the low 8 bits of the performance counter against one byte in
the random bits bin, performs a not on the byte in the random bits bin, and
increments the random bits bin pointer to point to the next byte. When you
reach the end of the random bits bin, you start over at the beginning. Due
to the high speed of today's computers, the entire contents of the random
bits bin can change many hundreds or thousands of times per second. This is
a very effective generator of random bits that can be used to seed pseudo
random number generators, or create One Time Pad Key Files, which are used
to seed 256 pseudo random number generators.
// Random Bits Bin thread procedure. This thread constantly updates
// and randomizes the random bits bin. It is run as a thread until
// the program is terminated.
//.................................................................
DWORD WINAPI RandomBitsBinThread(HWND hWnd)
{
int iRBBIndex = 0;
int iPCLowPart = 0;
LPBYTE pRBBBuffer;

// Open the event we will check for to see if we are shutting down.
//.................................................................
HANDLE hRBBEvent = OpenEvent(SYNCHRONIZE,FALSE,
TEXT("RBB_SHUTDOWN_EVENT"));

pRBBBuffer = pRandBitsBin;

while(TRUE)
{
// Read the high performance counter.
//...................................
QueryPerformanceCounter(&PerformanceCounter);
iPCLowPart = PerformanceCounter.LowPart;
*pRBBBuffer ^= LOBYTE(LOWORD(iPCLowPart));
*pRBBBuffer++ = ~*pRBBBuffer;
iRBBIndex += 1;
if (iRBBIndex >= RBB_LENGTH)
{
pRBBBuffer = pRandBitsBin;
iRBBIndex = 0;
}
if (WaitForSingleObject(hRBBEvent,0) == WAIT_OBJECT_0)
break;
}
CloseHandle(hRBBEvent);
return(TRUE);
}

Stir the Bits in the Random Bits Bin
This procedure stirs up the entire contents of the random bits bin at the
same time. It reads the High Performance Count and performs a xor and not
operation on the first byte of the random bits bin with the low 8 bits of
the high performance counter. It then takes the first byte of the random
bits bin and performs a xor and not between the first and second bytes of
the random bits bin storing the result in the second byte. The operation is
then performed between the results of the second and third bytes, storing
the results in the third byte. This operation is continued until the end of
the random bits bin is reached.
// Stir the bits of the random bits bin.
//......................................
VOID StirTheBits()
{
// Read the high performance counter.
//...................................
QueryPerformanceCounter(&PerformanceCounter);

__asm
{
mov edi,pRandBitsBin
mov edx,PerformanceCounter.LowPart
mov al,byte ptr [edi]
xor al,dl
not al
stosb
mov ecx,RBB_LENGTH
dec ecx
Rbl:
mov dl,al
mov al,byte ptr [edi]
xor al,dl
not al
stosb
loop Rbl
}
}


Extract Radom Bits from the Random Bits Bin
For every 32 bits or less requested, the High Performance Counter is read and the low 16 bits of the High Performance Counter is used as an index into the random bits bin. (The random bits bin is 8,192 bytes or 65,536 bits long.) This is the starting point at which you will start to extract bits. If the index is 13,972 and you need to extract 32 bits, you will start at the 13,972nd bit in the random bits bin and extract 32 bits. If you are constructing a large number that requires many thousands of bits, the High Performance Counter will be read again, and the next 32 bits will be extracted using the low 16 bits as an index. After every 32 bits is extracted, the entire content of the random bits bin is stirred up before the next 32 bits are extracted.
// Get the number of requested random bits from the random bits bin
// and place them in the destination address.
//.................................................................
VOID GetRandomBits(DWORD BitsRequested, LPVOID Destination)
{
DWORD Mask32;
LPVOID BitsDestination;

BitsDestination = Destination;

while (BitsRequested != 0)
{
if (BitsRequested >= 32)
{
BitsRequested -= 32;
Mask32 = -1;
}
else
{
__asm
{
mov Mask32,0
mov eax,-1
mov cl,byte ptr BitsRequested
shld Mask32,eax,cl
mov BitsRequested,0
}
}
// Read the high performance counter.
//...................................
QueryPerformanceCount
er(&PerformanceCounter);

// Get up to 32 random bits and place them in the destination.
//............................................................
__asm
{
mov esi,pRandBitsBin
mov edi,BitsDestination
mov ebx,PerformanceCounter.LowPart
and ebx,0ffffh
mov ecx,ebx
shr ebx,5
shl ebx,2
dec ebx
and cl,1fh
mov eax,dword ptr [esi][ebx]
cmp ebx,8187
jne L1
mov edx,dword ptr [esi]
jmp L2
L1: mov edx,dword ptr [esi][ebx+4]
L2: shrd eax,edx,cl
and eax,Mask32
stosd
mov BitsDestination,edi
}
StirTheBits();






Pseudo Random Number Generation Source Code
There are many pseudo random number generation formulas that do a good job,
but what you need for an effective encryption algorithm is a pseudo random
number generator that has a very large key space. This is because the
security of an encryption algorithm does not lie in the encryption algorithm
at all, but in the random key that is used to start the encryption
algorithm. In order to use a large key space we do not use one pseudo random
number generator with a large key space, but many pseudo random number
generators with smaller key spaces. When you add the key space together for
all of the pseudo random number generators you get a very large key space.
When using the One Time Pad Key File to seed the encryption formula, we use
256 pseudo random number generators with an effective key space between
18,469 and 20,261 bits. See Initial Conditions - Or How to Tell a Good
Encryption Formula for more details.
The following variables are used by the pseudo random number generators:
// Variables used by the encryption routines.
//...........................................
DWORD Dividend1;
DWORD Divisor1;
DWORD Seed;
DWORD RdmFactor;
DWORD DbleNumber;
DWORD LimitNumber;

DWORD TopsArray[256];
DWORD FactorArray[256];
DWORD SeedsArray[256];

// Random factor array shift value of 17 to 24.
//.............................................
DWORD RandomFactorShift;

BYTE LastSeed;
BYTE RingMask;

// Bit position in random number file of RandomFactorShift.
//.........................................................
DWORD RFSBitPosition = 16387;
Setup the Arrays for the 256 Pseudo Random Number Generators
The following source code shows how to set up 256 pseudo random number
generators from the contents of a One Time Pad Key File that has been read
into a buffer in memory. There are three arrays called the TopsArray, the
FactorArray, and the SeedsArray with 256 dword elements in each array. Each
pseudo random number generator uses one element from each array. During
pseudo random number generation the low 8 bits of the randomly generated
Seed determines the next pseudo random number generator to use.
Note: Setting up 4, 8, 16, 32, or 64 pseudo random number generators for a
randomly generated session key uses the random bits bin vice a One Time Pad
Key File to extract random numbers between the range 100,000,001 and
4,294,967,295.
Note: It is important to remember that while the numbers from the One Time
Pad Key File are selected with a pseudo random number generator to fill the
arrays, the values themselves in the One Time Pad are true random numbers.
See Random Bits Bin Source Code and One Time Pad Key File Source Code for
more details.
// Setup the arrays for the pseudo random number generators.
//..........................................................
VOID SetupArrays(LPVOID lpBuffer)
{
// First set the random factor array shift value.
//...............................................
SetRFShiftValue(lpBuffer);

__asm
{
// Get the last random number in the file and double it.
//......................................................
mov edi,lpBuffer
mov eax,dword ptr [edi][(Goal-1)*4]
clc
rcl eax,1
jnc L1
mov eax,-1
L1: mov DbleNumber,eax

// Get the first number in the file and make it the
// limit number.
//..................................................
mov eax,dword ptr [edi]
mov LimitNumber,eax

// Setup the random factor value.
//...............................
mov ecx,RandomFactorShift
xor ebx,ebx
shrd eax,ebx,cl
mov RdmFactor,eax

// Select 768 numbers randomly from a buffer with 1,303 numbers.
// Divisor1 is set to 1,303.
//.............................................
mov Divisor1,Goal
}
// Fill the 3 arrays.
//...................
FillOneArray(lpBuffer,(LPVOID)&TopsArray);
FillOneArray(lpBuffer,(LPVOID)&FactorArray);
FillOneArray(lpBuffer, (LPVOID)&SeedsArray);

__asm
{
// Shift the numbers in the FactorArray.
//......................................
xor ebx,ebx
xor edi,edi
mov ecx,NumbersWanted/3
L2: push ecx
mov ecx,RandomFactorShift
mov eax,FactorArray[edi*4]
shrd eax,ebx,cl
mov FactorArray[edi*4],eax
inc edi
pop ecx
loop L2
}
}
Fill One Array Procedure
The following procedure fills one array of 256 elements with pseudo randomly
selected numbers from a buffer of 1,303 numbers.
// Fill one array with randomly selected numbers.
//...............................................
VOID FillOneArray(LPVOID lpBuffer, LPVOID lpArray)
{
__asm
{
xor esi,esi
mov ecx,NumbersWanted/3

// Get the randomly selected numbers.
//...................................
L1: push ecx
push esi
L2: call GetRandNum
mov ebx,eax
mov edi,lpBuffer

// Do not use a number twice.
//...........................
cmp dword ptr [edi][ebx*4],0
je L2
mov eax,dword ptr [edi][ebx*4]
mov dword ptr [edi][ebx*4],0
pop esi
mov edi,lpArray
mov dword ptr [edi][esi*4],eax
inc esi
pop ecx
loop L1
}
}
Set the Random Factor Array Shift Value
The following procedure determines the random factor array shift value for
shifting the FactorArray right by the selected number of bits. The random
factor array shift value will be between 17 and 24 and is extracted starting
at RFSBitPosition, which is the 16,387th bit in the One Time Pad Key File in
memory.
// Set the random factor array shift value.
// It must be between 17 and 24.
//.........................................
VOID SetRFShiftValue(LPVOID lpBuffer)
{
__asm
{
mov edi,lpBuffer
mov ebx,RFSBitPosition
mov ecx,ebx
shr ebx,3
and ecx,7h
mov eax,dword ptr [edi][ebx]
shr eax,cl
and eax,1fh
jmp L2
L1: add eax,8
L2: cmp eax,17
jb L1
jmp L4
L3: sub eax,8
L4: cmp eax,24
ja L3
mov RandomFactorShift,eax
}
}
Get Pseudo Random Number Procedure Number 1
The following procedure is only used when setting up the 256 pseudo random
number generators. One Pseudo Random Number Generator is used to extract 768
numbers from the One Time Pad Key File in memory to fill the arrays used by
the 256 pseudo random number generators. The numbers in the One Time Pad Key
File are made up of true random bits from the random bits bin. Since the
sender and recipient must have a copy of the One Time Pad Key File there can
be no way to duplicate the initial starting numbers for the 256 pseudo
random number generators without a copy of the One Time Pad Key File used to
extract the numbers from.
As you can see, the value in LastSeed when you are done setting up the
arrays, determines the first pseudo random number generator used when you
start encrypting a file.
// Get pseudo random number. Only used to setup our
// 3 arrays of 256 random numbers each.
//.................................................
DWORD GetRandNum()
{
__asm
{
mov eax,Seed
xor edx,edx
mov ebx,Divisor1
div ebx

// Save remainder on the stack.
//.............................
push edx
mov ebx,eax // Quotient to ebx
mov eax,Seed // Seed to eax again
mov ecx,RdmFactor
mov edx,DbleNumber
add eax,ebx // Add quotient to seed
jnc L1
sub eax,ebx // Make the same as before
jmp L3
L1: cmp eax,edx
jae L3
add eax,ecx // Add random factor
jnc L2
sub eax,ecx // Make the same as before
jmp L3
L2: cmp eax,edx
jb L4
L3: mov ebx,LimitNumber
sub eax,ebx
L4: mov Seed,eax // NEW seed
mov LastSeed,al
pop eax
}
}
Get Pseudo Random Number Procedure 2
This pseudo random number generation procedure is used by the encryption and
decryption procedures. It can only be used after the arrays for the 256
pseudo random number generators have been set up.
As you can see, the value in LastSeed determines which pseudo random number
generator out of the 256 will be used. When you exit the procedure a new
value is placed in LastSeed, which determines the next pseudo random number
generator to use.
// Get a pseudo random number.
//............................
DWORD GetRandomNumber()
{
// Get the first byte of the previous LastSeed to be used as the
// pseudo random number to index into one of the 256 pseudo
// random number generators.
//..............................................................
__asm
{
movzx esi,LastSeed
mov eax,SeedsArray[esi*4] // Get seed from seeds array
xor edx,edx
mov ebx,Divisor1
push eax // Save the seed
div ebx
mov ecx,eax // Quotient to ecx
pop eax
push edx // Save remainder on stack
mov edx,DbleNumber
add eax,ecx // Add quotient to seed
jnc L1
sub eax,ecx // Make it the same
jmp L3

// Add the FactorArray to the seed.
//.................................
L1: cmp eax,edx
jae L3
mov ecx,FactorArray[esi*4] // Add random factor to seed
add eax,ecx
jnc L2
sub eax,ecx // Make it the same
jmp L3

file://If the new seed is greater than DbleNumber.
//...........................................
L2: cmp eax,edx
jb L4
L3: mov ecx,TopsArray[esi*4]
sub eax,ecx

// Put the NEW seed into the table and the low byte into
// the LastSeed variable.
//......................................................
L4: mov SeedsArray[esi*4],eax

// Mask off the number of rings in use. Can be
// 4, 8, 16, 32, 64, or 256.
//............................................
and al,RingMask
mov LastSeed,al

// Pop the remainder off the stack and return it as our
// pseudo randomly generated number. Usually
// between the values of 0 and 255 since we are
// encrypting byte values.
//.....................................................
pop eax
}
}




One Time Pad Key File Source Code
The following source code shows how a One Time Pad Key File is created in
memory, which is written to disk when all 1,303 numbers are generated. All
numbers in the One Time Pad Key File must be greater than 100,000,001. Since
the numbers are selected from random bits in the Random Bits Bin, they can
be considered truly random in nature. Due to the way the contents of the
Random Bits Bin is constantly changing, there is no way to predict what the
value of the selected bits will be. Nor is there any way to set up two
computers that will maintain two Random Bits Bins that are the same, or
duplicates of each other. Nor is there any way to set up one computer that
can create duplicate Random Bits Bins when you start from scratch with new
Random Bits Bins. See Random Bits Bin Source Code for details on the Random
Bits Bin and Create One Time Pad Key Files for instructions on creating
hundreds or thousands of One Time Pad Key Files at one time.
// Fill the buffer with random numbers.
//.....................................
dwNumbersWanted = Goal;
lpOtpFileBufferDup = lpOtpFileBuffer;
while(dwNumbersWanted > 0)
{
while(TRUE)
{
GetRandomBits(32,&dwTestNumber);
if (dwTestNumber >= 100000001)
{
break;
}
}
__asm
{
mov edi,lpOtpFileBufferDup
mov eax,dwTestNumber
stosd
mov lpOtpFileBufferDup,edi
}
EmptyTheMessageQue();
if (bCancelOperation == TRUE)
{
break;
}
dwNumbersWanted--;
}
Data Encryption and Decryption Source CodeMost of the data encryption
formulas used today are complicated monstrosities that take a genius with 10
PhDs to figure out. In a commercial encryption program this makes no
difference at all. This is because everyone is forgetting one of the basic
rules of cryptography: The General System is known - to everyone. If you buy
a commercial encryption program that is sold over the counter, you have the
general system for that product. You do not even have to understand its
complex encryption process. The program does it all for you. The key to an
effective and secure encryption formula is in its key. The longer the key,
the more secure your encrypted data will be. See Initial Conditions - Or How
to Tell a Good Encryption Formula and Pseudo Random Number Generation Source
Code for more details. As you can see, my encryption formula consists of a
simple xor and not operation between a byte of plaintext, and a pseudo
randomly generated byte of data between 0 and 255. It is very fast and
efficient. // ChangeBytes will either encipher or decipher the contents// of
the buffer.//..........................................................VOID
ChangeBytes(LPBYTE lpChangeBuffer, DWORD dwBytesToChange){ LPBYTE
lpChangeBufferDup; DWORD dwRandomNumber; lpChangeBufferDup =
lpChangeBuffer; while(dwBytesToChange > 0) { CheckForMessages(); if
(bCancelOperation == TRUE) { return; } // Get a pseudo random number in
the range 0 to 255. //..................................................
dwRandomNumber = GetRandomNumber(); __asm { mov edi,lpChangeBufferDup
mov eax,dwRandomNumber xor byte ptr [edi],al not byte ptr [edi] inc
lpChangeBufferDup dec dwBytesToChange } }}Source Code for Protecting the
Secret Components of a Secret KeyThe secret components of your Secret Key
can be protected by a Pass Phrase that can be up to 250 characters long.
Creating an effective and unguessable Pass Phrase is the key to protecting
your Secret Key in case it gets stolen. See Secret Key Packet for details on
the Cipher Feedback field and exactly what fields in a Secret Key are
encrypted. Note: The Cipher Feedback Data is extracted from the Random Bits
Bin and placed in the Cipher Feedback Field just prior to encrypting the
secret components of a Secret Key. Encipher the Secret Components of a
Secret Key// Encipher the secret components of the secret key. The correct//
pass phrase is required to decipher
it.//..............................................................BOOL
EncipherSecretComponents(LPBYTE lpPassPhrase, LPBYTE lpSecretComponents,
DWORD dwPPCount, DWORD dwSCCount){ LPBYTE lpCipherFeedBack; DWORD dwSCBits;
DWORD dwShift; __asm { mov eax,dwSCCount shl eax,3 mov dwSCBits,eax
mov edi,lpSecretComponents // Setup the cipher feedback address which is
just before // the secret key components.
//....................................................... mov
lpCipherFeedBack,edi sub lpCipherFeedBack,CFB_LENGTH mov
esi,lpCipherFeedBack // First use the bytes of the cipher feedback to xnor
the // data in the secret components.
//....................................................... mov
ecx,CFB_LENGTH L1: push ecx xor ebx,ebx mov ecx,dwSCCount lodsb L2:
xor byte ptr [edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx
jnz L2 pop ecx dec ecx jnz L1 // Calculate a check value on the
cipher feed back. This // method produces a check value that is dependent
on the // value of each byte and the order also.
//....................................................... mov
esi,lpCipherFeedBack xor edx,edx mov ecx,CFB_LENGTH L3: lodsb xor
dl,al rol dx,1 dec ecx jnz L3 // If edx is greater than dwSCBits
divide edx by dwSCBits // and use the remainder for the rotate.
//....................................................... cmp edx,dwSCBits
jbe L4 mov eax,edx xor edx,edx mov ecx,dwSCBits div ecx // See if
it is a multiple of 8. //.............................. L4: test edx,07h
jnz L5 inc edx L5: mov dwShift,edx } // Now rotate the bit field of the
secret components left // by the number of bits calculated.
//.......................................................
RotateBitFieldLeft(lpSecretComponents,dwSCCount,dwShift); // See if we want
to quit. //........................ CheckForMessages(); if
(bCancelOperation) { return(FALSE); } // Now use the pass phrase to hide
the cipher feedback data.
//.......................................................... __asm { mov
esi,lpPassPhrase mov edi,lpCipherFeedBack mov ecx,dwPPCount L6: push
ecx xor ebx,ebx mov ecx,CFB_LENGTH lodsb L7: xor byte ptr
[edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx jnz L7 pop
ecx dec ecx jnz L6 // Calculate a check value on the pass phrase.
//............................................ mov esi,lpPassPhrase xor
edx,edx mov ecx,dwPPCount L8: lodsb xor dl,al rol dx,1 dec ecx jnz
L8 // If edx is greater than the CFB*3 divide edx by // the number of
CFB*3 and use the remainder for // the shift count.
//.................................................. cmp
edx,(CFB_LENGTH*3) jbe L9 mov eax,edx xor edx,edx mov
ecx,(CFB_LENGTH*3) div ecx // See if it is a multiple of 8.
//.............................. L9: test edx,07h jnz L0 inc edx L0:
mov dwShift,edx } // Rotate the cipher feedback field.
//..................................
RotateBitFieldRight(lpCipherFeedBack,CFB_LENGTH,dwShift);
return(TRUE);}Decipher the Secret Components of a Secret Key// Decipher the
secret components of the secret key. The correct// pass phrase is
required.//..............................................................BOO
L DecipherSecretComponents(LPBYTE lpPassPhrase, LPBYTE
lpSecretComponents, DWORD dwPPCount, DWORD dwSCCount){ LPBYTE
lpCipherFeedBack; DWORD dwSCBits; DWORD dwShift; __asm { mov eax,dwSCCount
shl eax,3 mov dwSCBits,eax // Setup the cipher feedback address.
//................................... mov edi,lpSecretComponents mov
lpCipherFeedBack,edi sub lpCipherFeedBack,CFB_LENGTH // First use the
pass phrase to unrotate the cipher feedback // field.
//.......................................................... mov
esi,lpPassPhrase xor edx,edx mov ecx,dwPPCount L1: lodsb xor dl,al
rol dx,1 dec ecx jnz L1 // If edx is greater than CFB*3 divide edx by
CFB*3 // and use the remainder for the rotate.
//................................................. cmp edx,(CFB_LENGTH*3)
jbe L2 mov eax,edx xor edx,edx mov ecx,(CFB_LENGTH*3) div ecx //
See if it is a multiple of 8. //.............................. L2: test
edx,07h jnz L3 inc edx L3: mov dwShift,edx } // Rotate the cipher
feedback field left. //.......................................
RotateBitFieldLeft(lpCipherFeedBack,CFB_LENGTH,dwShift); // See if we want
to quit. //........................ CheckForMessages(); if
(bCancelOperation) { return(FALSE); } // Now use the pass phrase to un xnor
the cipher feedback.
//........................................................ __asm { mov
esi,lpPassPhrase mov edi,lpCipherFeedBack mov ecx,dwPPCount L4: push
ecx xor ebx,ebx mov ecx,CFB_LENGTH lodsb L5: xor byte ptr
[edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx jnz L5 pop
ecx dec ecx jnz L4 // Calculate a check value on the cipher feedback.
//................................................ mov
esi,lpCipherFeedBack xor edx,edx mov ecx,CFB_LENGTH L6: lodsb xor
dl,al rol dx,1 dec ecx jnz L6 // If edx is greater than dwSCBits
divide edx by dwSCBits // and use the remainder for the rotate.
//....................................................... cmp edx,dwSCBits
jbe L7 mov eax,edx xor edx,edx mov ecx,dwSCBits div ecx // See if
it is a multiple of 8. //.............................. L7: test edx,07h
jnz L8 inc edx L8: mov dwShift,edx } // Now rotate the bit field of the
secret components // right the number of bits calculated.
//...................................................
RotateBitFieldRight(lpSecretComponents,dwSCCount,dwShift); // Now use the
bytes of the cipher feedback to un xnor the // date in the secret
components. //........................................................ __asm
{ mov esi,lpCipherFeedBack mov edi,lpSecretComponents mov
ecx,CFB_LENGTH L9: push ecx xor ebx,ebx mov ecx,dwSCCount lodsb L0:
xor byte ptr [edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx
jnz L0 pop ecx dec ecx jnz L9 } return(TRUE);}Rotate Bit Field Left
Procedure// Rotate a bit field left the number of bits passed. Takes// the
end bit and rotates it into the first bit of the
string.//.............................................................VOID
RotateBitFieldLeft(LPBYTE lpBitField, DWORD dwByteCount, DWORD
dwShiftCount){ __asm { mov esi,lpBitField mov edi,esi add
edi,dwByteCount dec edi // Last byte of bit field mov ecx,dwShiftCount
L1: mov ecx,dwByteCount xor ebx,ebx // Put the last bit in the string
into the carry flag // for rotating into the first bit of the string.
//................................................... mov al,byte ptr
[edi] bt eax,7 L2: rcl byte ptr [esi][ebx],1 inc ebx dec ecx jnz
L2 pop ecx dec ecx jnz L1 }}Rotate Bit Field Right Procedure// Rotate
a bit field right the number of bits passed. Takes// the first bit and
rotates it into the last bit of the
string.//..............................................................VOID
RotateBitFieldRight(LPBYTE lpBitField, DWORD dwByteCount, DWORD
dwShiftCount){ __asm { mov esi,lpBitField mov ecx,dwShiftCount L1: push
ecx mov ecx,dwByteCount mov ebx,ecx dec ebx // Index to last byte //
Put the first bit of the string into the carry flag // to be rotated into
the last bit of the string.
//.................................................... bt dword ptr
[esi],0 L2: rcr byte ptr [esi][ebx],1 dec ebx dec ecx jnz L2 pop
ecx dec ecx jnz L1 }}

---

On Mon, 4 Jun 2001 20:19:57 +0200, "Peter Nielsen" <PDN@ofir.dk>
wrote:
>Til det kan jeg sige følgende: Hvis man skal vurderer programmet må man i
>første omgang stole på hvad der står i vejledningen

De siger at de bruger one time pads. Det er forkert. De bruger tal der
er genereret ud fra en algoritme. Derfor kan man ikke stole på hvad
der står i vejledningen. Det gør også at programmørens
viden/kunne/hensigter kan drages i tvivl.

Den måde de siger at man kan chekke om talende er tilfældige er endnu
længere ude. Du kan ikke afgøre hvor tilfældige tal er, bare ved at
kigge på dem.

Påstanden om ubrydelig kryptering er forkert og udsender et meget
dårligt signal. Du ser ikke nogen anden seriøs krypterings pakke der
påstår at den er ubrydelig.

---

Nu må i lige huske at jeg ikke er programmøren, jeg læste awns indlæg og
ville derfor komme med mit syn på sagen da jeg selv har brugt programmet et
halvt års tid og syntes godt om det. Min tanke var også at der var nogle
kloge og hjælpsomme personer som kunde give en vurdering på programmets
styrke men det er åbenbart sværere end forventet, for alt hvad der er kommet
frem bliver forkastet.

Til Martin Schultz, du skriver: Man kan skrive hvad som helst i
vejledningen. Skriver de noget om at uafhænge eksperter har testet
programmet?
Til det kan jeg sige følgende: Hvis man skal vurderer programmet må man i
første omgang stole på hvad der står i vejledningen og så gå ud fra det, jeg
sendte det med fordi man der beskriver hvordan de forskellige ting
fremkommer og fungerer. Til det med eksperterne, ja arme programmør, prøv at
se hvordan programmet er blevet modtaget her, det bider jo sig selv i halen.
Hvordan vil du have at en ekspert skal teste programmet, se bare hvordan det
er gået her.

Til Klaus Ellegaard, Som jeg har forstået det er det en Amerikaner der bor
på Phillipinerne
og derfor er der ikke nogle begrænsninger i nøglestørrelsen. Det er nok også
derfor Zdnet.com
kun henviser til Topsecretcrypto.com for download af programmet, det må ikke
ligge på Zdnet.com
Så alt er altså ganske lovligt.

Jeg er Kemiker og skal derfor ikke gøre mig klog på dette felt, men jeg
havde enlig regnet med at der bare var een nysgerrig "ekspert" på denne
nyhedsgruppe som ville ulejlige sig med at downloade programmet og derved
kunde give en tilbagemelding om det var godt eller skidt, nu hvor awn har
bragt programmet op til debat. Det der ligger til grund for vurderingen af
programmet både her og på sci.crypt er de få "vildledende" oplysninger der
er kommet frem her.
Jeg har det selv på den måde at et nyt produkt kræver en ordentlig
undersøgelse før jeg siger noget negativt om det, men det kan man åbenbart
ikke regne med på dette felt. Det tyder på at nævne OTP svarer til at stikke
næsen ned i en flaske Ammoniakvand.

Nå men jeg har jo programmet og sender derfor de Source koder med som er
frigivet i hjælpemenuen, måske det kan bidrage til noget fornuftig, nu hvor
andre ikke har overskud til
at grave dem frem.

I øvrigt glæder det mig at der dog er nogle der svarer og interessere sig
lidt for kryptografi.

Venligst

Peter Nielsen.


Random Bits Bin Source Code
Before delving into the source code please read about the Random Bits Bin
and extracting random bits from the Random Bits Bin.
Random Bits Bin Setup Source Code
// Make sure we have a High Performance Counter in the system
// to generate random bits for the Random Bits Bin.
//...........................................................
if (!QueryPerformanceFrequency(&PerformanceCounter))
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOHPC,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
// Allocate the memory for the random bits bin.
//.............................................
pRandBitsBin = AllocateMemory(RBB_LENGTH);
if (pRandBitsBin)
{
// Initialize the memory to A5 hex
//................................
int i;
pMem = pRandBitsBin;
for (i = 0; i < RBB_LENGTH; i++)
*pMem++ = LOBYTE(LOWORD(FillChar));
}
else
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOMEM,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
// Create or open the Random Bits Bin file.
// ........................................
hFile = CreateMyFile((LPTSTR)&RandomBitsFile,GENERIC_READ |
GENERIC_WRITE,0,NULL,
OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
if (!hFile)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
// Determine if we opened or created the file. If we opened it,
// read the file into the random bits bin buffer. If we created
// it, write the initial buffer to disk.
//.............................................................
if (GetLastError() == ERROR_ALREADY_EXISTS)
{
if (GetFileSize(hFile,NULL) != RBB_LENGTH)
{
if (MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_WRONGLGTH,
MB_USERICON | MB_OKCANCEL | MB_DEFBUTTON1,
MB_ICONQUESTION,lpszQuestion) == IDCANCEL)
{
return(FALSE);
}
else
{
SetEndOfFile(hFile);
bResult = WriteMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,RBB_LENGTH,
d_Write,NULL);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,MB_ICONHAND,
lpszStopSign);
return(FALSE);
}
}
}
else


bResult = ReadMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,
RBB_LENGTH,&dwRead_Write,NULL);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,MB_ICONHAND,
lpszStopSign);
return(FALSE);
}
}
}
else
{
bResult = WriteMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,RBB_LENGTH,
&dwRead_Write,NULL);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_ICONHAND,lpszStopSign);
return(FALSE);
}
}
bResult = CloseMyHandle((LPTSTR)&RandomBitsFile,hFile);
if (!bResult)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOCREATE,
MB_USERICON | MB_OK,MB_ICONHAND,lpszStopSign);
return(FALSE);
}
bUpdateRandBitsBin = TRUE;

// Start the thread that will handle the random bits bin.
// First create an event so we can tell the thread when to quit.
//..............................................................
hRBBEvent = CreateEvent(NULL,TRUE,FALSE,TEXT("RBB_SHUTDOWN_EVENT"));
if (!hRBBEvent)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOEVENT,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
hRBBThread = CreateThread(NULL,0,RandomBitsBinThread,hWnd,0,&dwRBBThreadId);
if (!hRBBThread)
{
MessageBoxProc(hWnd,IDS_INITIALIZE,IDS_NOTHREAD,MB_USERICON | MB_OK,
MB_ICONHAND,lpszStopSign);
return(FALSE);
}
Update the Random Bits Bin File
The random bits bin file is updated with the current contents of the random
bits bin in memory just before you exit the program.
// Update the Random Bits Bin File using the Random Bits Bin in memory.
// We do not do any error checking because it should hardly ever fail.
//....................................................................
LRESULT CALLBACK UpdateRandBitsBinFile()
{
HANDLE hFile;
DWORD dwWrite;
BOOL bResult;
BOOL bReturnResult = FALSE;

if (bUpdateRandBitsBin)
{
// Stir up the bits before we write the bits bin to a file.
//.........................................................
StirTheBits();

// Open the file. It will always exist at this point.
//...................................................
hFile = CreateMyFile((LPTSTR)&RandomBitsFile,GENERIC_READ | GENERIC_WRITE,
0,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
if (hFile)


bResult = WriteMyFile((LPTSTR)&RandomBitsFile,hFile,
pRandBitsBin,RBB_LENGTH,&dwWrite,NULL);
if (bResult)
{

bResult = CloseMyHandle((LPTSTR)&RandomBitsFile,hFile);
if (bResult)
{
bReturnResult = TRUE;
}
}
}
}
return(bReturnResult);
}



Random Bits Bin Thread Procedure
The following thread is created at the start of the program and runs
continuously, changing the random bits bin in memory. The only time it is
suspended is during RSA Key Generation to shorten the time is takes to
generate a set of RSA Keys.
What the code does is read the High Performance Counter, performs an xor
operation with the low 8 bits of the performance counter against one byte in
the random bits bin, performs a not on the byte in the random bits bin, and
increments the random bits bin pointer to point to the next byte. When you
reach the end of the random bits bin, you start over at the beginning. Due
to the high speed of today's computers, the entire contents of the random
bits bin can change many hundreds or thousands of times per second. This is
a very effective generator of random bits that can be used to seed pseudo
random number generators, or create One Time Pad Key Files, which are used
to seed 256 pseudo random number generators.
// Random Bits Bin thread procedure. This thread constantly updates
// and randomizes the random bits bin. It is run as a thread until
// the program is terminated.
//.................................................................
DWORD WINAPI RandomBitsBinThread(HWND hWnd)
{
int iRBBIndex = 0;
int iPCLowPart = 0;
LPBYTE pRBBBuffer;

// Open the event we will check for to see if we are shutting down.
//.................................................................
HANDLE hRBBEvent = OpenEvent(SYNCHRONIZE,FALSE,
TEXT("RBB_SHUTDOWN_EVENT"));

pRBBBuffer = pRandBitsBin;

while(TRUE)
{
// Read the high performance counter.
//...................................
QueryPerformanceCounter(&PerformanceCounter);
iPCLowPart = PerformanceCounter.LowPart;
*pRBBBuffer ^= LOBYTE(LOWORD(iPCLowPart));
*pRBBBuffer++ = ~*pRBBBuffer;
iRBBIndex += 1;
if (iRBBIndex >= RBB_LENGTH)
{
pRBBBuffer = pRandBitsBin;
iRBBIndex = 0;
}
if (WaitForSingleObject(hRBBEvent,0) == WAIT_OBJECT_0)
break;
}
CloseHandle(hRBBEvent);
return(TRUE);
}

Stir the Bits in the Random Bits Bin
This procedure stirs up the entire contents of the random bits bin at the
same time. It reads the High Performance Count and performs a xor and not
operation on the first byte of the random bits bin with the low 8 bits of
the high performance counter. It then takes the first byte of the random
bits bin and performs a xor and not between the first and second bytes of
the random bits bin storing the result in the second byte. The operation is
then performed between the results of the second and third bytes, storing
the results in the third byte. This operation is continued until the end of
the random bits bin is reached.
// Stir the bits of the random bits bin.
//......................................
VOID StirTheBits()
{
// Read the high performance counter.
//...................................
QueryPerformanceCounter(&PerformanceCounter);

__asm
{
mov edi,pRandBitsBin
mov edx,PerformanceCounter.LowPart
mov al,byte ptr [edi]
xor al,dl
not al
stosb
mov ecx,RBB_LENGTH
dec ecx
Rbl:
mov dl,al
mov al,byte ptr [edi]
xor al,dl
not al
stosb
loop Rbl
}
}


Extract Radom Bits from the Random Bits Bin
For every 32 bits or less requested, the High Performance Counter is read and the low 16 bits of the High Performance Counter is used as an index into the random bits bin. (The random bits bin is 8,192 bytes or 65,536 bits long.) This is the starting point at which you will start to extract bits. If the index is 13,972 and you need to extract 32 bits, you will start at the 13,972nd bit in the random bits bin and extract 32 bits. If you are constructing a large number that requires many thousands of bits, the High Performance Counter will be read again, and the next 32 bits will be extracted using the low 16 bits as an index. After every 32 bits is extracted, the entire content of the random bits bin is stirred up before the next 32 bits are extracted.
// Get the number of requested random bits from the random bits bin
// and place them in the destination address.
//.................................................................
VOID GetRandomBits(DWORD BitsRequested, LPVOID Destination)
{
DWORD Mask32;
LPVOID BitsDestination;

BitsDestination = Destination;

while (BitsRequested != 0)
{
if (BitsRequested >= 32)
{
BitsRequested -= 32;
Mask32 = -1;
}
else
{
__asm
{
mov Mask32,0
mov eax,-1
mov cl,byte ptr BitsRequested
shld Mask32,eax,cl
mov BitsRequested,0
}
}
// Read the high performance counter.
//................................
....
QueryPerformanceCount
er(&PerformanceCounter);

// Get up to 32 random bits and place them in the destination.
//............................................................
__asm
{
mov esi,pRandBitsBin
mov edi,BitsDestination
mov ebx,PerformanceCounter.LowPart
and ebx,0ffffh
mov ecx,ebx
shr ebx,5
shl ebx,2
dec ebx
and cl,1fh
mov eax,dword ptr [esi][ebx]
cmp ebx,8187
jne L1
mov edx,dword ptr [esi]
jmp L2
L1: mov edx,dword ptr [esi][ebx+4]
L2: shrd eax,edx,cl
and eax,Mask32
stosd
mov BitsDestination,edi
}
StirTheBits();






Pseudo Random Number Generation Source Code
There are many pseudo random number generation formulas that do a good job,
but what you need for an effective encryption algorithm is a pseudo random
number generator that has a very large key space. This is because the
security of an encryption algorithm does not lie in the encryption algorithm
at all, but in the random key that is used to start the encryption
algorithm. In order to use a large key space we do not use one pseudo random
number generator with a large key space, but many pseudo random number
generators with smaller key spaces. When you add the key space together for
all of the pseudo random number generators you get a very large key space.
When using the One Time Pad Key File to seed the encryption formula, we use
256 pseudo random number generators with an effective key space between
18,469 and 20,261 bits. See Initial Conditions - Or How to Tell a Good
Encryption Formula for more details.
The following variables are used by the pseudo random number generators:
// Variables used by the encryption routines.
//...........................................
DWORD Dividend1;
DWORD Divisor1;
DWORD Seed;
DWORD RdmFactor;
DWORD DbleNumber;
DWORD LimitNumber;

DWORD TopsArray[256];
DWORD FactorArray[256];
DWORD SeedsArray[256];

// Random factor array shift value of 17 to 24.
//.............................................
DWORD RandomFactorShift;

BYTE LastSeed;
BYTE RingMask;

// Bit position in random number file of RandomFactorShift.
//.........................................................
DWORD RFSBitPosition = 16387;
Setup the Arrays for the 256 Pseudo Random Number Generators
The following source code shows how to set up 256 pseudo random number
generators from the contents of a One Time Pad Key File that has been read
into a buffer in memory. There are three arrays called the TopsArray, the
FactorArray, and the SeedsArray with 256 dword elements in each array. Each
pseudo random number generator uses one element from each array. During
pseudo random number generation the low 8 bits of the randomly generated
Seed determines the next pseudo random number generator to use.
Note: Setting up 4, 8, 16, 32, or 64 pseudo random number generators for a
randomly generated session key uses the random bits bin vice a One Time Pad
Key File to extract random numbers between the range 100,000,001 and
4,294,967,295.
Note: It is important to remember that while the numbers from the One Time
Pad Key File are selected with a pseudo random number generator to fill the
arrays, the values themselves in the One Time Pad are true random numbers.
See Random Bits Bin Source Code and One Time Pad Key File Source Code for
more details.
// Setup the arrays for the pseudo random number generators.
//..........................................................
VOID SetupArrays(LPVOID lpBuffer)
{
// First set the random factor array shift value.
//...............................................
SetRFShiftValue(lpBuffer);

__asm
{
// Get the last random number in the file and double it.
//......................................................
mov edi,lpBuffer
mov eax,dword ptr [edi][(Goal-1)*4]
clc
rcl eax,1
jnc L1
mov eax,-1
L1: mov DbleNumber,eax

// Get the first number in the file and make it the
// limit number.
//..................................................
mov eax,dword ptr [edi]
mov LimitNumber,eax

// Setup the random factor value.
//...............................
mov ecx,RandomFactorShift
xor ebx,ebx
shrd eax,ebx,cl
mov RdmFactor,eax

// Select 768 numbers randomly from a buffer with 1,303 numbers.
// Divisor1 is set to 1,303.
//.............................................
mov Divisor1,Goal
}
// Fill the 3 arrays.
//...................
FillOneArray(lpBuffer,(LPVOID)&TopsArray);
FillOneArray(lpBuffer,(LPVOID)&FactorArray);
FillOneArray(lpBuffer, (LPVOID)&SeedsArray);

__asm
{
// Shift the numbers in the FactorArray.
//......................................
xor ebx,ebx
xor edi,edi
mov ecx,NumbersWanted/3
L2: push ecx
mov ecx,RandomFactorShift
mov eax,FactorArray[edi*4]
shrd eax,ebx,cl
mov FactorArray[edi*4],eax
inc edi
pop ecx
loop L2
}
}
Fill One Array Procedure
The following procedure fills one array of 256 elements with pseudo randomly
selected numbers from a buffer of 1,303 numbers.
// Fill one array with randomly selected numbers.
//...............................................
VOID FillOneArray(LPVOID lpBuffer, LPVOID lpArray)
{
__asm
{
xor esi,esi
mov ecx,NumbersWanted/3

// Get the randomly selected numbers.
//...................................
L1: push ecx
push esi
L2: call GetRandNum
mov ebx,eax
mov edi,lpBuffer

// Do not use a number twice.
//...........................
cmp dword ptr [edi][ebx*4],0
je L2
mov eax,dword ptr [edi][ebx*4]
mov dword ptr [edi][ebx*4],0
pop esi
mov edi,lpArray
mov dword ptr [edi][esi*4],eax
inc esi
pop ecx
loop L1
}
}
Set the Random Factor Array Shift Value
The following procedure determines the random factor array shift value for
shifting the FactorArray right by the selected number of bits. The random
factor array shift value will be between 17 and 24 and is extracted starting
at RFSBitPosition, which is the 16,387th bit in the One Time Pad Key File in
memory.
// Set the random factor array shift value.
// It must be between 17 and 24.
//.........................................
VOID SetRFShiftValue(LPVOID lpBuffer)
{
__asm
{
mov edi,lpBuffer
mov ebx,RFSBitPosition
mov ecx,ebx
shr ebx,3
and ecx,7h
mov eax,dword ptr [edi][ebx]
shr eax,cl
and eax,1fh
jmp L2
L1: add eax,8
L2: cmp eax,17
jb L1
jmp L4
L3: sub eax,8
L4: cmp eax,24
ja L3
mov RandomFactorShift,eax
}
}
Get Pseudo Random Number Procedure Number 1
The following procedure is only used when setting up the 256 pseudo random
number generators. One Pseudo Random Number Generator is used to extract 768
numbers from the One Time Pad Key File in memory to fill the arrays used by
the 256 pseudo random number generators. The numbers in the One Time Pad Key
File are made up of true random bits from the random bits bin. Since the
sender and recipient must have a copy of the One Time Pad Key File there can
be no way to duplicate the initial starting numbers for the 256 pseudo
random number generators without a copy of the One Time Pad Key File used to
extract the numbers from.
As you can see, the value in LastSeed when you are done setting up the
arrays, determines the first pseudo random number generator used when you
start encrypting a file.
// Get pseudo random number. Only used to setup our
// 3 arrays of 256 random numbers each.
//.................................................
DWORD GetRandNum()
{
__asm
{
mov eax,Seed
xor edx,edx
mov ebx,Divisor1
div ebx

// Save remainder on the stack.
//.............................
push edx
mov ebx,eax // Quotient to ebx
mov eax,Seed // Seed to eax again
mov ecx,RdmFactor
mov edx,DbleNumber
add eax,ebx // Add quotient to seed
jnc L1
sub eax,ebx // Make the same as before
jmp L3
L1: cmp eax,edx
jae L3
add eax,ecx // Add random factor
jnc L2
sub eax,ecx // Make the same as before
jmp L3
L2: cmp eax,edx
jb L4
L3: mov ebx,LimitNumber
sub eax,ebx
L4: mov Seed,eax // NEW seed
mov LastSeed,al
pop eax
}
}
Get Pseudo Random Number Procedure 2
This pseudo random number generation procedure is used by the encryption and
decryption procedures. It can only be used after the arrays for the 256
pseudo random number generators have been set up.
As you can see, the value in LastSeed determines which pseudo random number
generator out of the 256 will be used. When you exit the procedure a new
value is placed in LastSeed, which determines the next pseudo random number
generator to use.
// Get a pseudo random number.
//............................
DWORD GetRandomNumber()
{
// Get the first byte of the previous LastSeed to be used as the
// pseudo random number to index into one of the 256 pseudo
// random number generators.
//..............................................................
__asm
{
movzx esi,LastSeed
mov eax,SeedsArray[esi*4] // Get seed from seeds array
xor edx,edx
mov ebx,Divisor1
push eax // Save the seed
div ebx
mov ecx,eax // Quotient to ecx
pop eax
push edx // Save remainder on stack
mov edx,DbleNumber
add eax,ecx // Add quotient to seed
jnc L1
sub eax,ecx // Make it the same
jmp L3

// Add the FactorArray to the seed.
//.................................
L1: cmp eax,edx
jae L3
mov ecx,FactorArray[esi*4] // Add random factor to seed
add eax,ecx
jnc L2
sub eax,ecx // Make it the same
jmp L3

file://If the new seed is greater than DbleNumber.
//...........................................
L2: cmp eax,edx
jb L4
L3: mov ecx,TopsArray[esi*4]
sub eax,ecx

// Put the NEW seed into the table and the low byte into
// the LastSeed variable.
//......................................................
L4: mov SeedsArray[esi*4],eax

// Mask off the number of rings in use. Can be
// 4, 8, 16, 32, 64, or 256.
//............................................
and al,RingMask
mov LastSeed,al

// Pop the remainder off the stack and return it as our
// pseudo randomly generated number. Usually
// between the values of 0 and 255 since we are
// encrypting byte values.
//.....................................................
pop eax
}
}




One Time Pad Key File Source Code
The following source code shows how a One Time Pad Key File is created in
memory, which is written to disk when all 1,303 numbers are generated. All
numbers in the One Time Pad Key File must be greater than 100,000,001. Since
the numbers are selected from random bits in the Random Bits Bin, they can
be considered truly random in nature. Due to the way the contents of the
Random Bits Bin is constantly changing, there is no way to predict what the
value of the selected bits will be. Nor is there any way to set up two
computers that will maintain two Random Bits Bins that are the same, or
duplicates of each other. Nor is there any way to set up one computer that
can create duplicate Random Bits Bins when you start from scratch with new
Random Bits Bins. See Random Bits Bin Source Code for details on the Random
Bits Bin and Create One Time Pad Key Files for instructions on creating
hundreds or thousands of One Time Pad Key Files at one time.
// Fill the buffer with random numbers.
//.....................................
dwNumbersWanted = Goal;
lpOtpFileBufferDup = lpOtpFileBuffer;
while(dwNumbersWanted > 0)
{
while(TRUE)
{
GetRandomBits(32,&dwTestNumber);
if (dwTestNumber >= 100000001)
{
break;
}
}
__asm
{
mov edi,lpOtpFileBufferDup
mov eax,dwTestNumber
stosd
mov lpOtpFileBufferDup,edi
}
EmptyTheMessageQue();
if (bCancelOperation == TRUE)
{
break;
}
dwNumbersWanted--;
}
Data Encryption and Decryption Source CodeMost of the data encryption
formulas used today are complicated monstrosities that take a genius with 10
PhDs to figure out. In a commercial encryption program this makes no
difference at all. This is because everyone is forgetting one of the basic
rules of cryptography: The General System is known - to everyone. If you buy
a commercial encryption program that is sold over the counter, you have the
general system for that product. You do not even have to understand its
complex encryption process. The program does it all for you. The key to an
effective and secure encryption formula is in its key. The longer the key,
the more secure your encrypted data will be. See Initial Conditions - Or How
to Tell a Good Encryption Formula and Pseudo Random Number Generation Source
Code for more details. As you can see, my encryption formula consists of a
simple xor and not operation between a byte of plaintext, and a pseudo
randomly generated byte of data between 0 and 255. It is very fast and
efficient. // ChangeBytes will either encipher or decipher the contents// of
the buffer.//..........................................................VOID
ChangeBytes(LPBYTE lpChangeBuffer, DWORD dwBytesToChange){ LPBYTE
lpChangeBufferDup; DWORD dwRandomNumber; lpChangeBufferDup =
lpChangeBuffer; while(dwBytesToChange > 0) { CheckForMessages(); if
(bCancelOperation == TRUE) { return; } // Get a pseudo random number in
the range 0 to 255. //..................................................
dwRandomNumber = GetRandomNumber(); __asm { mov edi,lpChangeBufferDup
mov eax,dwRandomNumber xor byte ptr [edi],al not byte ptr [edi] inc
lpChangeBufferDup dec dwBytesToChange } }}Source Code for Protecting the
Secret Components of a Secret KeyThe secret components of your Secret Key
can be protected by a Pass Phrase that can be up to 250 characters long.
Creating an effective and unguessable Pass Phrase is the key to protecting
your Secret Key in case it gets stolen. See Secret Key Packet for details on
the Cipher Feedback field and exactly what fields in a Secret Key are
encrypted. Note: The Cipher Feedback Data is extracted from the Random Bits
Bin and placed in the Cipher Feedback Field just prior to encrypting the
secret components of a Secret Key. Encipher the Secret Components of a
Secret Key// Encipher the secret components of the secret key. The correct//
pass phrase is required to decipher
it.//..............................................................BOOL
EncipherSecretComponents(LPBYTE lpPassPhrase, LPBYTE lpSecretComponents,
DWORD dwPPCount, DWORD dwSCCount){ LPBYTE lpCipherFeedBack; DWORD dwSCBits;
DWORD dwShift; __asm { mov eax,dwSCCount shl eax,3 mov dwSCBits,eax
mov edi,lpSecretComponents // Setup the cipher feedback address which is
just before // the secret key components.
//....................................................... mov
lpCipherFeedBack,edi sub lpCipherFeedBack,CFB_LENGTH mov
esi,lpCipherFeedBack // First use the bytes of the cipher feedback to xnor
the // data in the secret components.
//....................................................... mov
ecx,CFB_LENGTH L1: push ecx xor ebx,ebx mov ecx,dwSCCount lodsb L2:
xor byte ptr [edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx
jnz L2 pop ecx dec ecx jnz L1 // Calculate a check value on the
cipher feed back. This // method produces a check value that is dependent
on the // value of each byte and the order also.
//....................................................... mov
esi,lpCipherFeedBack xor edx,edx mov ecx,CFB_LENGTH L3: lodsb xor
dl,al rol dx,1 dec ecx jnz L3 // If edx is greater than dwSCBits
divide edx by dwSCBits // and use the remainder for the rotate.
//....................................................... cmp edx,dwSCBits
jbe L4 mov eax,edx xor edx,edx mov ecx,dwSCBits div ecx // See if
it is a multiple of 8. //.............................. L4: test edx,07h
jnz L5 inc edx L5: mov dwShift,edx } // Now rotate the bit field of the
secret components left // by the number of bits calculated.
//.......................................................
RotateBitFieldLeft(lpSecretComponents,dwSCCount,dwShift); // See if we want
to quit. //........................ CheckForMessages(); if
(bCancelOperation) { return(FALSE); } // Now use the pass phrase to hide
the cipher feedback data.
//.......................................................... __asm { mov
esi,lpPassPhrase mov edi,lpCipherFeedBack mov ecx,dwPPCount L6: push
ecx xor ebx,ebx mov ecx,CFB_LENGTH lodsb L7: xor byte ptr
[edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx jnz L7 pop
ecx dec ecx jnz L6 // Calculate a check value on the pass phrase.
//............................................ mov esi,lpPassPhrase xor
edx,edx mov ecx,dwPPCount L8: lodsb xor dl,al rol dx,1 dec ecx jnz
L8 // If edx is greater than the CFB*3 divide edx by // the number of
CFB*3 and use the remainder for // the shift count.
//.................................................. cmp
edx,(CFB_LENGTH*3) jbe L9 mov eax,edx xor edx,edx mov
ecx,(CFB_LENGTH*3) div ecx // See if it is a multiple of 8.
//.............................. L9: test edx,07h jnz L0 inc edx L0:
mov dwShift,edx } // Rotate the cipher feedback field.
//..................................
RotateBitFieldRight(lpCipherFeedBack,CFB_LENGTH,dwShift);
return(TRUE);}Decipher the Secret Components of a Secret Key// Decipher the
secret components of the secret key. The correct// pass phrase is
required.//..............................................................BOO
L DecipherSecretComponents(LPBYTE lpPassPhrase, LPBYTE
lpSecretComponents, DWORD dwPPCount, DWORD dwSCCount){ LPBYTE
lpCipherFeedBack; DWORD dwSCBits; DWORD dwShift; __asm { mov eax,dwSCCount
shl eax,3 mov dwSCBits,eax // Setup the cipher feedback address.
//................................... mov edi,lpSecretComponents mov
lpCipherFeedBack,edi sub lpCipherFeedBack,CFB_LENGTH // First use the
pass phrase to unrotate the cipher feedback // field.
//.......................................................... mov
esi,lpPassPhrase xor edx,edx mov ecx,dwPPCount L1: lodsb xor dl,al
rol dx,1 dec ecx jnz L1 // If edx is greater than CFB*3 divide edx by
CFB*3 // and use the remainder for the rotate.
//................................................. cmp edx,(CFB_LENGTH*3)
jbe L2 mov eax,edx xor edx,edx mov ecx,(CFB_LENGTH*3) div ecx //
See if it is a multiple of 8. //.............................. L2: test
edx,07h jnz L3 inc edx L3: mov dwShift,edx } // Rotate the cipher
feedback field left. //.......................................
RotateBitFieldLeft(lpCipherFeedBack,CFB_LENGTH,dwShift); // See if we want
to quit. //........................ CheckForMessages(); if
(bCancelOperation) { return(FALSE); } // Now use the pass phrase to un xnor
the cipher feedback.
//........................................................ __asm { mov
esi,lpPassPhrase mov edi,lpCipherFeedBack mov ecx,dwPPCount L4: push
ecx xor ebx,ebx mov ecx,CFB_LENGTH lodsb L5: xor byte ptr
[edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx jnz L5 pop
ecx dec ecx jnz L4 // Calculate a check value on the cipher feedback.
//................................................ mov
esi,lpCipherFeedBack xor edx,edx mov ecx,CFB_LENGTH L6: lodsb xor
dl,al rol dx,1 dec ecx jnz L6 // If edx is greater than dwSCBits
divide edx by dwSCBits // and use the remainder for the rotate.
//....................................................... cmp edx,dwSCBits
jbe L7 mov eax,edx xor edx,edx mov ecx,dwSCBits div ecx // See if
it is a multiple of 8. //.............................. L7: test edx,07h
jnz L8 inc edx L8: mov dwShift,edx } // Now rotate the bit field of the
secret components // right the number of bits calculated.
//...................................................
RotateBitFieldRight(lpSecretComponents,dwSCCount,dwShift); // Now use the
bytes of the cipher feedback to un xnor the // date in the secret
components. //........................................................ __asm
{ mov esi,lpCipherFeedBack mov edi,lpSecretComponents mov
ecx,CFB_LENGTH L9: push ecx xor ebx,ebx mov ecx,dwSCCount lodsb L0:
xor byte ptr [edi][ebx],al not byte ptr [edi][ebx] inc ebx dec ecx
jnz L0 pop ecx dec ecx jnz L9 } return(TRUE);}Rotate Bit Field Left
Procedure// Rotate a bit field left the number of bits passed. Takes// the
end bit and rotates it into the first bit of the
string.//.............................................................VOID
RotateBitFieldLeft(LPBYTE lpBitField, DWORD dwByteCount, DWORD
dwShiftCount){ __asm { mov esi,lpBitField mov edi,esi add
edi,dwByteCount dec edi // Last byte of bit field mov ecx,dwShiftCount
L1: mov ecx,dwByteCount xor ebx,ebx // Put the last bit in the string
into the carry flag // for rotating into the first bit of the string.
//................................................... mov al,byte ptr
[edi] bt eax,7 L2: rcl byte ptr [esi][ebx],1 inc ebx dec ecx jnz
L2 pop ecx dec ecx jnz L1 }}Rotate Bit Field Right Procedure// Rotate
a bit field right the number of bits passed. Takes// the first bit and
rotates it into the last bit of the
string.//..............................................................VOID
RotateBitFieldRight(LPBYTE lpBitField, DWORD dwByteCount, DWORD
dwShiftCount){ __asm { mov esi,lpBitField mov ecx,dwShiftCount L1: push
ecx mov ecx,dwByteCount mov ebx,ecx dec ebx // Index to last byte //
Put the first bit of the string into the carry flag // to be rotated into
the last bit of the string.
//.................................................... bt dword ptr
[esi],0 L2: rcr byte ptr [esi][ebx],1 dec ebx dec ecx jnz L2 pop
ecx dec ecx jnz L1 }}

---

"Peter Nielsen" <PDN@ofir.dk> wrote in
news:gqQS6.1719$R84.373088@news010.worldonline.dk:

> Nu må i lige huske at jeg ikke er programmøren,
[snip]
>
> Til Martin Schultz, du skriver: Man kan skrive hvad som helst i
> vejledningen. Skriver de noget om at uafhænge eksperter har testet
> programmet?
> Til det kan jeg sige følgende: Hvis man skal vurderer programmet må man
> i første omgang stole på hvad der står i vejledningen og så gå ud fra
> det,

neeej ... for som udgangspunkt kan du jo ikke stole på de informationer, som
står i vejledningen. Det eneste du 100% kan stole på er kildekoden og så din
egen kompilering af denne.

> Jeg har det selv på den måde at et nyt produkt kræver en ordentlig
> undersøgelse før jeg siger noget negativt om det, men det kan man
> åbenbart ikke regne med på dette felt. Det tyder på at nævne OTP svarer
> til at stikke næsen ned i en flaske Ammoniakvand.
>

det er ikke fordi OTP er noget skidt noget ... det er bare forbasket svært
at implementere. Som det er blevet skrevet tidligere, så skal en OTP være en
sandt tilfældig række af bits - og længere end beskeden. Der er så også
problemer med distributionen af dette ... men det er lidt en anden snak.

Jeg er lidt nødt til at trække det citat jeg tidligere har sendt i denne
tråd frem igen ...


"I have developed an encryption software package that I can best describe as
a ONE-TIME-PAD GENERATOR."

(Anthony Stephen Szopa posting to sci.crypt, August 8, 1997)




> Nå men jeg har jo programmet og sender derfor de Source koder med som
> er frigivet i hjælpemenuen, måske det kan bidrage til noget fornuftig,
> nu hvor andre ikke har overskud til
> at grave dem frem.
>
> I øvrigt glæder det mig at der dog er nogle der svarer og interessere
> sig lidt for kryptografi.
>

der er da flere og flere mennesker, der interesserer sig for kryptografi ...
og det er ganske rigtigt glædeligt.

Se i øvrigt link i min signatur

Jesper Stocholm
DTU/MAT

--
Læs mit midtvejsprojekt om digitale signaturer på Smart Cards på
http://stocholm.dk/pmp

- Jesper Stocholm - http://stocholm.dk

---

spam@stocholm.dk (Jesper Stocholm) writes:

> neeej ... for som udgangspunkt kan du jo ikke stole på de informationer, som
> står i vejledningen. Det eneste du 100% kan stole på er kildekoden og så din
> egen kompilering af denne.

Stoler du på din compiler? Trusting trust:
http://www.acm.org/classics/sep95/

- Jacob

---

Jacob Atzen <jacob_a@NOSPAMos.dk> wrote in
news:m366e84mgv.fsf@morpheus.dyndns.dk:

> spam@stocholm.dk (Jesper Stocholm) writes:
>
>> neeej ... for som udgangspunkt kan du jo ikke stole på de
>> informationer, som står i vejledningen. Det eneste du 100% kan stole
>> på er kildekoden og så din egen kompilering af denne.
>
> Stoler du på din compiler? Trusting trust:
> http://www.acm.org/classics/sep95/
>

læg mærke til ordet "egen" ... ... men du har jo trods alt ret -
kompileren skulle ikke have været med.




--
I wrote to George W. Bush - see why at
http://stocholm.dk/emailgeorgewbush.asp

- Jesper Stocholm - http://stocholm.dk