Xs4all probeert verspreiding van kinderporno te voorkomen
Boudewijn W. Ch. Visser
jult@xs&all.nl writes:
>>19 May 1997 in xs4all.general (Boudewijn W. Ch. Visser) wrote:
>> jult@xs&all.nl writes:
>> >coderingsprogramma te produceren, iets zoals PGP, maar dan zonder
>> >de encryptie-beperkingen waar de USA de maker van PGP toe verplicht.
>> >Interessant hieraan is dat dit programma in ons land gewoon gebruikt
>> >zal mogen worden, maar in Frankrijk en Amerika (bijvoorbeeld) niet,
>> >wat een boeiende problematiek de netwerken op zal werpen.
>>
>> Ik hoop dat je je beter hebt geinformeerd over de codering dan over
>> de politiek ervan, want wat je hier schrijft klopt niet.
>>
>> PGP heeft -geen- beperkingen in de USA, en hier trouwens ook niet.
>Zoals Philip Zimmermann zelf uitlegt heeft hij het RSA-algoritme zonder
>overeenstemming met de licensiehouder (PKP, California) geimplementeerd.
>Het uitvoeren van de machine-instructies van RSA is reeds in strijd met
>de wet op de patenten; 'The author assumes no liability for any patent
>infringements that may result from executing de RSA algorithm on the
>user's computer without a license from the RSA patent holder (PKP, red.)'
OK.
Maar er zitten geen technische beperkingen in de encryptie wat sterkte
betreft.
En "de USA" verplichten de maker van PGP ook niet tot beperkingen,
zolang hij niets wil exporteren.
>> Een amerikaan mag in Amerika naar hartelust coderen met elk algorithme.
>Onjuist. Toegestaan is het coderen met software-producten waarvan de
>maker overeenstemming heeft met de licensie-houder. Symantec heeft bijv.
>een licensie voor 56-bits DES, waarvan de US Government licensiehouder
>is (zie: Department of Commerce, FIPS PUB 46, jan.'77). Een koper
DES is nu zeker (patent verlopen), maar ook daarvoor gratis te implementeren
geweest.
Een van de redenen waarom het een echte standaard heeft kunnen worden.
(naast de aanbeveling/eis tot gebruik van de US Government, natuurlijk)
[snip voor gebruik van gepatenteerde algorithmen is toesteming van
patent houder nodig.
Inderdaad. Hoewel er misschien een uitzondering is voor eigen gebruik.
In elk geval is het 'slechts' een civielrechtelijke zaak,itt
ongeoorloofde export]
>zitten klieren met algoritmen die NSA-geheim zijn. Daar bestaan genoeg nare
>verhalen over (zie: 'Military Cryptanalysis', William F. Friedman).
Hm, ik meen dat ik die eens gelezen heb, maar daarover kan ik me niets
herinneren.
Het is natuurlijk best mogelijk.
>Niet voor niets heeft 'Applied Cryptograhphy' van Schneier de bij-titel
>'the book the National Security Agency never wanted to be published.'
Wel, zo'n ondertitel is natuurlijk nooit slecht voor de verkoop ;-)
>> Die libraries zijn gewoon als source te krijgen, dus daar is niks
>> verdachts aan.
>> Commerciel gebruik van bv PGP kost dus geld.
>In zoverre dat PZ er geen geld voor wil hebben. Alleen de licensies
>van RSA (MD5 is PD, IDEA is een heel ander verhaal, waarover zometeen
>meer) zou eerst geregeld moeten worden zou men PGP commercieel
>willen gebruiken, m.a.w.: verkopen. Maar omdat het een freeware-product
>is, ligt dat natuurlijk heel lastig. PZ vereist (copyright-wet) dat de
>documentatie bij PGP wordt gedistribueerd. Een verkoper kan PGP dus
>niet verkopen zonder dat de koper in de smiezen krijgt dat hij geld
>betaalt voor een vrij product.
Mwa, dat geld ook voor GNU ware.
Ik meen dat PRZ echter ook geld wil als je het commmerciel gebruikt,
hoor. Niet alleen maar geld aan RSA DSI.
Maar de details van wat is commerciel en hoe duur staan op www.pgp.com.
(voor USA gebruikers).
>>
>> Je mag echter geen sterke encryptie *exporteren* zonder vergunning.
>Je mag uberhaupt geen encryptie-algoritmen uit de VS exporteren met een
>key-lengte > 40 bits. Daar bestaan geen vergunningen voor. Voor educatieve
Ja hoor, even makkelijk als het exporteren van F16's; Het gaat tenslotte
om dezelfde wet.
Ik geloof dat er inderdaad wel wat export gevallen zijn,zoals grote
bedrijven die in hun buitenlandse vestigingen willen coderen.
Maar het schijnt een enorme papierwinkel te zijn.
>doeleinden gelden andere regels, maar naar de letter van de wet is dat
>geen export. Dat zul je dus wel bedoelen met vergunningen.
Nee, dat bedoel ik niet, en ik geloof ook niet dat daar een uitzondering
voor is.
Hoewel dingen misschien veranderd zijn sinds Dan Bernstein z'n zaak heeft
gewonnen.
>Omdat import in de US van deze zaken niet verboden is, wordt PGP
>'vervolgens' geimporteerd uit Europa en gedistribueerd binnen de US.
>Een makkelijk te omzeilen wetje...
Tsja. het zal toch wel schelen in het grote gebruik; Een hoop bedrijven
in de VS zullen hun producten beperken tot <40 bits, om geen gezeur
van twee versies te hebben.
>Julius
>====================================================================
>co-creator SDU.EXE, non-public-key coding en decoding dos-freeware:
>Probeer-maar-eens-te-kraken-wat-daarmee-gecodeerd-is-!-ware by JTHZ,
>downloadable from http://www.xs4all.nl/~jult/4u.htm
Wat voor algorithme gebruik je ?
Boudewijn
--
+-------------------------------------------------------------------+
|Boudewijn Visser |E-mail:vis...@ph.tn.tudelft.nl |finger for |
|Dep. of Applied Physics,Delft University of Technology |PGP-key |
+-- my own opinions etc --------------------------------------------+
Piet Beertema
>>Je mag uberhaupt geen encryptie-algoritmen uit de VS exporteren met
>>een key-lengte > 40 bits. Daar bestaan geen vergunningen voor.
>Ja hoor, even makkelijk als het exporteren van F16's
Da's dan ook maar 16 bits... :-)
--
Piet Beertema, CWI, Amsterdam | URL: http://www.cwi.nl/~piet
|
"Life: chemical waste of time"
ju...@xs&all.nl
22 May 1997 20:08:46 GMT vis...@ph.tn.tudelft.nl (Boudewijn W. Ch. Visser)
caught my attention with:
>>Omdat import in de US van deze zaken niet verboden is, wordt PGP
>>'vervolgens' geimporteerd uit Europa en gedistribueerd binnen de US.
>>Een makkelijk te omzeilen wetje...
>
>Tsja. het zal toch wel schelen in het grote gebruik; Een hoop bedrijven
>in de VS zullen hun producten beperken tot <40 bits, om geen gezeur
>van twee versies te hebben.
Denk ik ook.
>>Julius
>>====================================================================
>>co-creator SDU.EXE, non-public-key coding en decoding dos-freeware:
>>Probeer-maar-eens-te-kraken-wat-daarmee-gecodeerd-is-!-ware by JTHZ,
>>downloadable from http://www.xs4all.nl/~jult/4u.htm
>
>Wat voor algorithme gebruik je ?
Shannon one-pad XOR with proprietary noise-algorithm (c) JTHZ
Groet,
Julius
|\/\/\/| |\/\/\/|
| | | |
| | |~ ~ |
| (-)(-) (O)(O) |
C _) (__ )
| ,___| shpit! |___ |
| \__ - - - - - - - - - o \ ` |
/______/ /_____\
/ \ / \
Boudewijn W. Ch. Visser
jult@xs&all.nl writes:
>>>downloadable from http://www.xs4all.nl/~jult/4u.htm
>>
>>Wat voor algorithme gebruik je ?
>Shannon one-pad XOR with proprietary noise-algorithm (c) JTHZ
One-pad ? Een xor van de boodschap met pure ruis wordt one-time pad
genoemd.(one-time omdat je de ruis maar 1 keer mag gebruiken).
Als je een algorithme gebruikt om de ruis (random numbers) te genereren
is het al geen echt one-time pad meer.[voor een echt one time pad moet je
echte ruis gebruiken: radioactief verval, johnson noise ,etc.
Goed oppassen dat je geen correlaties introduceert bij het samplen]
Nu hoeft een xor van de boodschap met de output van een PRNG (pseudo random
number generator) helemaal niet slecht te zijn; Dat hangt puur af
van de PRNG.
Kortom, wat voor PRNG gebruik je ?
Ik moet wel zeggen dat het ontbreken van source of uitleg op je homepage,
en je commentaar "propietary noise algorithm (c) JHTZ" me niet bijzonder
veel vertrouwen geven in de cryptografische kwaliteit van je software.
JBT
24 May 1997 15:29:48 GMT vis...@ph.tn.tudelft.nl (Boudewijn W. Ch. Visser)
caught my attention with:
>>Shannon one-pad XOR with proprietary noise-algorithm (c) JTHZ
>One-pad ? Een xor van de boodschap met pure ruis wordt one-time pad
>genoemd.(one-time omdat je de ruis maar 1 keer mag gebruiken).
Pff, what's in a name?
>echte ruis gebruiken: radioactief verval, johnson noise ,etc.
>Goed oppassen dat je geen correlaties introduceert bij het samplen
Like we don't know that.
>Kortom, wat voor PRNG gebruik je ?
>
>Ik moet wel zeggen dat het ontbreken van source of uitleg op je homepage,
>en je commentaar "propietary noise algorithm (c) JHTZ" me niet bijzonder
>veel vertrouwen geven in de cryptografische kwaliteit van je software.
1. Probeer het maar eens te kraken! En hoe je dat doet kan mij niet
schelen, maar het zal je gewoonweg niet lukken. Not in a million years!
2. Hoe wij coderen is evenmin van belang, wij hadden nooit als doel met het
maken van dat programma om de source ervan maar eens bekend te gaan maken,
we wilden gewoon sterke codering. Of "encryptie", maar dat woord bevalt mij
persoonlijk niet, omdat het iets impliceert wat helemaal niet op dit soort
software van toepassing is. Codering en decodering zijn de juiste
termen voor wat er hier gebeurt. (Valt me erg tegen van deze business,
die valse bewoording: "cryptografische kwaliteit". Onzin, het gaat hier om
"in onbegrijpelijke code vertalen", dus om coderen.
3. Mijn site bij XS is een "lekker keten met Jules"-gebeuren; Dit zijn de
pagina's op het net waar ik me flink kan en mag uitleven, om het zo maar
even te stellen. Lekker buiten spelen en testjes doen. Ik heb nog niet
de intentie gevoeld hier iets vreselijk engs serieus van te gaan maken,
en al wel als laatste gedacht TU-Delfters te moeten gaan vermaken
met zo iets saais als verhalen over sourcecode van een oud
DOS-programmaatje. Ik betaal voor die 5 Mb, ik word er niet voor betaald,
dus doe ik er liever dingen mee die mij zelf ook vermaken.
4. Van belang is dat wat wij zeggen dat het programma doet (=onkraakbaar
coderen!) klopt, en dat doet het. Hoe we het klaarspelen, hey, mogen we
dat alsjeblieft vakgeheim noemen? Probeer het maar uit te vissen.
Zelfs mensen die graag disassembleren en dan hopen er achter te
komen hoe we het doen wens ik veel succes, want daar hebben we wat
op gevonden. De source ligt veilig bij ons thuis verstopt,
en zo zal dat (helaas voor jou) ook blijven.
5. Wij hadden ons botte gevoel, en dat zei:
a) Random-generators zijn kut, niet echt random
b) Een korte keyfile die herhaalt loopt in de smiezen
c) Logica in de key of plaintext maakt het kraken eenvoudiger
Dus, daar hebben we op gevonden:
a) Haal de random-data uit menselijke input, dat is wel vervelend en
langdradig werk, maar uiterst random. Steeds weer opnieuw diezelfde
random-data gebruiken is op zich geen goed idee, maar dat wordt naar
ons idee allemaal heel veel minder kwetsbaar met wat trucjes:
b) De keyfile wordt constant shattered, zodat er eigenlijk sprake
is van een enorme keyfile. Het was kut om hier iets voor te vinden
wat niet ook heel snel herhalerig werd, maar daar zijn we jaren mee
bezig geweest (destijds) en uiteindelijk wel uitgekomen.
c) Dit alles is gebaseerd op code-ruis, onze breinen zijn uiteindelijk
tot dit briljante (ja kan iemand het effe kraken anders?) idee gekomen:
int ENCRYPT::next(){
if(++VWalk>=VMax) // bounds-check
VWalk=(C1Walk%256);
if(r1[R1Walk]>=VWalk) // add noise
R1Walk++;
if(++R1Walk>=R1Max) // bounds-check
R1Walk=0;
if(R2Walk<VWalk) // add noise
R2Walk++;
if(++R2Walk>=R2Max) // bounds-check
R2Walk=0;
if(R2Walk==VWalk) // add noise
R3Walk++;
if(++R3Walk>=R3Max) // bounds-check
R3Walk=0;
if(++C1Walk>=C1Max) // bounds-check
C1Walk=0;
return VWalk^r1[R1Walk]^r2[R2Walk]^r3[R3Walk]^C1[C1Walk];
}
Deze XOR-noise is verschrikkelijk onvoorspelbaar, want ze beďnvloeden
elkaar allemaal, waardoor steeds weer nieuwe patronen ontstaan.
VWalk is een Vigenere-derived cypher, die breken logica in ASCII-
files, r1 t/m r3 zijn random-arrays van verschillende lengte (die
hebben we op zich al zo laten kiezen dat er zo min mogelijk repetitie
optrad, nog zonder ruis dus). C1 is de file zelf.
Zo, Baud, heb je toch nog een klein beetje je zin...
Groet,
Julius
__
__/o \_
\____ \
/ \
__ //\ \
__/o \-//--\ \_/
\____ ___ \ |
|| \ |\ |
_|| _||_||
Rob Janssen
In <339093b1...@news0.xs4all.nl> Jul...@reply.to.field (JBT) writes:
[een hoop geouwehoer over een ruisgenerator geskipt]
Een one-time-pad werkt alleen als de ontvanger dezelfde pad bezit of
weer kan maken. In het eerste geval moet je de pad van de zender naar
de ontvanger sturen en heeft de hele encryptie geen zin. In het tweede
geval moet de ruisgenerator een voorspelbaar patroon geven, bijvoorbeeld
aan de hand van een seed value die je op de een of andere manier van de
zender naar de ontvanger stuurt. Dat wordt dan "de key".
Hoe ingewikkeld je ruisgenerator is doet er dan verder weinig toe, iedereen
die je het programma geeft heeft er een copie van.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
JBT
Sun, 25 May 1997 13:04:15 GMT rob@pe1chl (Rob Janssen) had this on me:
>Ik heb het niet zo op die zelfbedachte crypto algorithmes. Hun enige
>sterkte ontlenen ze meestal aan het feit dat nog geen serieuze pogingen
>gedaan zijn om ze te analyseren.
Jaloers dat het je niet lukt om zulke analyses te gaan verrichten?
Dergelijke prietpraat zijn we wel gewend hierover (na al die jaren).
Even ter herinnering, de eerste versie van SDU.EXE hadden we al af
ver vССrdat dat popi PGP ons eenmaal bereikte. (aantoonbaar) Dus ja,
wat je nou te emmeren hebt. I rest my case, haal het maar eens op:
http://www.xs4all.nl/~jult/ftp/sdu99x.exe (DOS 65K)
en probeer er maar eens wat van (af) te kraken.
Dan staan we open voor opbouwende kritiek. En die zal dan vast alleen
maar onderdelen betreffen die niets met de zwaarte of kwaliteit van
de codering te maken hebben, maar enkel met geheugen-allocatie
of user-interface en andere bijzaken.
ALLE bestaande coderings-algorithmen zijn "zelfbedacht", Rob.
Wat je nodig hebt, is een heleboel wantrouwen; DAT is een
goede basis voor het verzinnen van beveiligings-systemen.
Wat is dat trouwens toch? Heeft die Phil Z. het alleenrecht
op leuke coderings-algorithmen of zo?!? Pff, wake up !
Die Philip is ook een mens. Zo briljant is 'ie niet, vind ik,
als ik naar zijn software kijk. Ik bedoel, sorry, maar nee,
dat kan echt stukken beter. Gebruikersvriendelijk is anders.
Julius
\|/ \|/
OvO OvO
( ) ( )
--m-m-----http://www.xs4all.nl/~jult/-----m-m--
Boudewijn W. Ch. Visser
Jul...@reply.to.field (JBT) writes:
>Dan staan we open voor opbouwende kritiek. En die zal dan vast alleen
>maar onderdelen betreffen die niets met de zwaarte of kwaliteit van
>de codering te maken hebben, maar enkel met geheugen-allocatie
>of user-interface en andere bijzaken.
>ALLE bestaande coderings-algorithmen zijn "zelfbedacht", Rob.
>Wat je nodig hebt, is een heleboel wantrouwen; DAT is een
>goede basis voor het verzinnen van beveiligings-systemen.
>Wat is dat trouwens toch? Heeft die Phil Z. het alleenrecht
>op leuke coderings-algorithmen of zo?!? Pff, wake up !
>Die Philip is ook een mens. Zo briljant is 'ie niet, vind ik,
>als ik naar zijn software kijk. Ik bedoel, sorry, maar nee,
>dat kan echt stukken beter. Gebruikersvriendelijk is anders.
Moeten jullie niet zeggen. Phil Zimmerman heeft 1 ding voor op jullie,
hij kent z'n beperkingen. Hij weet dat hij geen cryptograaf is,
en dus gebruikt hij een algorithme dat is ontworpen door mensen
die dat wel zijn, en onderzocht door een hoop andere mensen die
ook verstand hebben van cryptografie.
Jullie hebben gewoon een streamcipher met eigenbouw rng geknutseld,
en willen (durven ?) niet te zeggen hoe die rng eruit ziet.
En daar zou iemand dan ook nog tijd aan moeten besteden, om eerst
een berg dos code te debuggen ?
Hens Zimmerman
Okay, net wat ik dacht. Dus *niemand* zag dat mijn 10-regelige
c-progje ongeveer net zo random is als een liniaaltje? Allemaal flink
lullen over OTP's en randomstreams en dan zoiets niet direct zien?
Nou, het is wel duidelijk, voor nl.comp.crypt hoeven we niet te vrezen
inzake het uitwisselen van gecodeerde data.
Als er nog één of andere malloot is die zichzelf en/of zijn Viking
Sparc of Alpha500 ofzo wil bewijzen, dan wil ik trouwens nog wel eens
zien hoe eenvoudig het is om het hergebruiken van dezelfde file als
'random-stream' te kraken.
Zij die wèl zelf ook programmeren en niet alleen theoretisch nablèren
wat anderen reeds vele malen hebben uitgespuugd kunnen krijgen:
- 10 files plaintext
- dezelfde 10 files als cyphertext (met één en dezelfde file
gecodeerd)
- de simpele c-source waarmee dit is gebeurd
- een elfde cyphertext waarin staat hoe ze F100,- van mij kunnen
ontvangen. Ja, het gaat om het gebaar. Dan zal ik met schaamte
bekennen dat we dit soort dingen aan de echte 'cryprograaf'
moeten overlaten.
Responses in deze newsgroups, dat houdt het spannend!
Oh, en voor wie het niet zag:
for(keySpace=0,rnd=0;keySpace<plainSpace;keySpace++){
for(i=0;i<3;i++){
if(kbhit()) // dit smijt alleen de key weg
getch();
gettime(&timebuf);
rnd+=timebuf.ti_hund;
}
// we have three hits!
key[keySpace]=rnd%256;
}
Dus dit ratelt gewoon een array vol, totaal niet rnd, heel af en toe
houdt de toetsenbord-int de boel effe op, maar dat hoeft niet eens te
gebeuren als alle beestjes in het jampotje apathisch tegen het
dekseltje blijven kleven (wat ze in de praktijk trouwens niet doen).
H.Zimmerman (geen fam. van Phil)
woensdag 28 mei 1997
18:36
JBT
27 May 1997 16:35:04 GMT vis...@ph.tn.tudelft.nl (Boudewijn W. Ch. Visser)
caught my attention with:
>Moeten jullie niet zeggen. Phil Zimmerman heeft 1 ding voor op jullie,
>hij kent z'n beperkingen. Hij weet dat hij geen cryptograaf is,
Wat is een cryptograaf?