Superrask opp/nedlasting over internett mulig?

[bkak]

Nå har jeg bare skumlest side 2, men hva med at man har en teoretisk uendelig CPU-kraft tilgjengelig. Ingen problemer med I/O eller noe som helst. Hvis man da tar noe alá en md5-sum fra en fil, kanskje sammen med filstørrelsen og slikt (husker ikke om det er inkludert i checksummen) så kan jo maskinen i teorien bruteforce seg fram til orginalfila?

[bkvaloy]

Hmm... burde kanskje ikke blande meg, men den raskeste overføringa får du hvis du samler alle oppskriftene over og flytter til Stavanger. Deretter installerer du Lyse, optisk bredbånd 10/10 MB og kjører på

Eller ennå enklere: Skaffe deg raskere linje der du allerede bor.

 

(Det er mange plasser i Norge der det tilbys både 10 Mbit/s og høyere. Flytter man f.eks til en av studentbyene i trondheim og blir student så kan man få 100 Mbit/s for 100kr/mnd)

Hmm... godt poeng..

[inaktiv000]

Nå har jeg bare skumlest side 2, men hva med at man har en teoretisk uendelig CPU-kraft tilgjengelig. Ingen problemer med I/O eller noe som helst. Hvis man da tar noe alá en md5-sum fra en fil, kanskje sammen med filstørrelsen og slikt (husker ikke om det er inkludert i checksummen) så kan jo maskinen i teorien bruteforce seg fram til orginalfila?

Først tenkte jeg nei. Det vil jo være flere ulike filkombinasjoner som gir én MD5 sum. Men tanken er jo interessant, og hvis en baker inn noe kjent data i filen man lager summen av bør jo den "rette" filen kunne skilles ut fra de ulike resultatene?

 

Et problem er jo at det vil være et uendelig antall filer, ettersom man bare kan øke lengden. Men hvis man sammen med md5 summen har den rette filstørrelsen samt eventuelt den kjente teksten, så bør dette fungere Eller?

 

HVIS dette går an kan man jo "bare" lage en enorm database med ulike filkombinasjoner og MD5 summen av disse, for så å slå opp i denne...

 

Endret 27. mai 2004 av cecolon

[ATWindsor]

Hmm... burde kanskje ikke blande meg, men den raskeste overføringa får du hvis du samler alle oppskriftene over og flytter til Stavanger. Deretter installerer du Lyse, optisk bredbånd 10/10 MB og kjører på

Eller ennå enklere: Skaffe deg raskere linje der du allerede bor.

 

(Det er mange plasser i Norge der det tilbys både 10 Mbit/s og høyere. Flytter man f.eks til en av studentbyene i trondheim og blir student så kan man få 100 Mbit/s for 100kr/mnd)

Lurer på om det ikke er 130 kr det har blitt nå (er ikke helt sikker, betaler ikke selv).

 

AtW

[ATWindsor]

Nå har jeg bare skumlest side 2, men hva med at man har en teoretisk uendelig CPU-kraft tilgjengelig. Ingen problemer med I/O eller noe som helst. Hvis man da tar noe alá en md5-sum fra en fil, kanskje sammen med filstørrelsen og slikt (husker ikke om det er inkludert i checksummen) så kan jo maskinen i teorien bruteforce seg fram til orginalfila?

Først tenkte jeg nei. Det vil jo være flere ulike filkombinasjoner som gir én MD5 sum. Men tanken er jo interessant, og hvis en baker inn noe kjent data i filen man lager summen av bør jo den "rette" filen kunne skilles ut fra de ulike resultatene?

 

Et problem er jo at det vil være et uendelig antall filer, ettersom man bare kan øke lengden. Men hvis man sammen med md5 summen har den rette filstørrelsen samt eventuelt den kjente teksten, så bør dette fungere Eller?

 

HVIS dette går an kan man jo "bare" lage en enorm database med ulike filkombinasjoner og MD5 summen av disse, for så å slå opp i denne...

 

MD5-summer er ikke unik for hver enkelt fil, det finnes mange filer som kan danne samme md5-sum (sier seg egentlig selv, en md5-sum har færre bytes en orginalfila, det er per def færre mulig kombinasjoner av få bytes en av mange, derfor må samme sum dekke flere filer), når det er sagt kan man sikkert ta noe kvalifisert gjetning, om man vet hva slags type fil det skal være osv, men dette vil jo ikke være lossless.

 

Du kan skape data ut av "ingenting", men da må du gjette deg til masse.

 

AtW

Endret 27. mai 2004 av ATWindsor

[inaktiv000]

Les det jeg skrev da Man bør vel kunne legge noe informasjon til den summen som gjør at det må bli unikt.

 

Hvis ikke: hva med en algoritme som lager en 32 bytes streng av en tekst opp til x gigabytes. Flere tekster kan få samme streng, men to tekster av nøyaktig samme størrelse. Sammen med strengen sendes størrelsen på originalfilen, så si at det aller meste da kan komprimeres til 64 bytes? Motbevis gjerne

[356speedster]

Noen som har testet FastSend ?

Endret 27. mai 2004 av 356speedster

[_Xorcist]

I Software Engineering faget har jeg lært at gode ideèr er veldig bra. Dårlige ideèr er også helt fint. De ideène som er problematiske er de halvgode ideène som virker fornuftige, men som etter en del ressurser er brukt opp viser seg å være helt på trynet..

[Os|r|s]

FLAC (Free Lossless Audio Codec) er også ganske stilig.. Komprimerer ned mot 50% (kommer veldig an på musikken). Les mer her

[delfin]

Kort om JPEG:

 

Si du har et bilde på 720*480. Først kjører du RGB verdiene gjennom en matrise slik at du får gjort om til YUV colorspace (Y = Luminance, U = Chroma Blue, V = Chroma Red). JPEG bruker YUV 4:2:2 som betyr at Y bruker dobbelt så mange bytes som U og V. Dette gjøres ved å kun sample annenhver verdi av U og V, slik at du lar pixel 1 og 2 dele på samme Cb og Cr verdi. Dette fordi øyet som tidligere nevnt er lite følsomt for farger. Vi sitter nå med en 720*480 Y komponent, samt en 360*480 U komponent og tilsvarende for V. Dette tilsvarer 2/3 av den originale størrelsen ((720*480+360*480+360*480)/(3*720*480)). Vi har nå krympet størrelsen fra 24 bits/px til 16 bits/px.

 

Neste steg er å dele inn i blokker på 8x8 pixler, så trekkes 128 fra hver pixelverdi.

 

Så brukes Discrete Cosine Transform (DCT) til å gjøre om 8x8 bitenes verdier til enklere verdier å overføre. Så kommer quantization, som er viktig for encodingen. Til slutt pakkes det hele pent inn med huffman kode og interleaves til en .jpg fil...sånn omtrent (kan gjøres VELDIG avansert om man går inn for det, men jeg er trøtt)

[Hoax]

Noen som har testet FastSend ?

Kan teste det om noen dager, skal se hvor lenge PC'n kan stå på før den begynner å finne på tull hehe

 

Operating System Properties

OS Name Microsoft Windows XP Professional

OS Code Name Whistler

OS Language English (United States)

OS Kernel Type Uniprocessor Free

OS Version 5.1.2600 (WinXP Retail)

OS Service Pack Service Pack 2, v.2096

OS Installation Date 22/03/2004

 

UpTime: 1079706 sec (12 days, 11 hours, 55 min, 6 sec)

 

Problems & Suggestions

Problem: Windows is now running for more than 10 days. Restart may improve performance.

[ATWindsor]

Les det jeg skrev da Man bør vel kunne legge noe informasjon til den summen som gjør at det må bli unikt.

 

Hvis ikke: hva med en algoritme som lager en 32 bytes streng av en tekst opp til x gigabytes. Flere tekster kan få samme streng, men to tekster av nøyaktig samme størrelse. Sammen med strengen sendes størrelsen på originalfilen, så si at det aller meste da kan komprimeres til 64 bytes?    Motbevis gjerne

Hehe, takk det samme, jeg leste hva du skrev, og kom med en innvending, la oss si filen allerede er komprimert ned så mye det kan vanlig, og fortsatt tar en kilobit (valgt ett lite tall her, bare for å vise hvor fort denne metoden vil knele). Det er 10^3 bits, hver av disse bitsene kan ha verdien 0 eller 1, det betyr at man har 2^1000= 1.07*10^301 unike kombinasjoner av akkurat 1000 bits. La oss si man bruker 64 kilobits til md5-summen (vet du sa bytes, men jeg bruker bits her for å gjøre det enkelt). Det er 1,84*10^18 kombinasjoner. det betyr at det må gå ca 10^280 unike filkombinasjoner per md5-sum, selv om man vet hvor stor fila er, det er ufattelig mange. (tera er 10^12).

 

Som sagt før, så kan man ta visse antakelser, jeg er ikke sikker på hvordan filer er bygd opp, men om du feks sender med filendelsen, så er sikkert begynnelsen og slutten av fila bygd opp på en fast måte, men antallet mulige kombinasjoner er så ufattelig mange, at jeg har vanskelig for å tro at man kan elimenere alle uten å komme med noen kraftige gjetninger.

 

Hvorfor bruker man da md5 kan man spørre seg, om en sum må dekke så ufattelig mange filer? jo som du ser så er det veldig mange kombinasjoner også av md5, om man går utifra 64 kilobyte så er det, 1.34*10^154 mulige kombinasjoner av bits i 64 bytes, så det er veldig liten sannynlighet for at akkurat din fil skal treffe den samme som en annen fil.

 

AtW

Endret 28. mai 2004 av ATWindsor

[ATWindsor]

FLAC (Free Lossless Audio Codec) er også ganske stilig.. Komprimerer ned mot 50% (kommer veldig an på musikken). Les mer her

Ja, flac er en bra codec, veldig bra allrounder, men det er mange samples på den siden som lar seg komprimere veldig godt, kan nok gi ett noe misvisende bilde, det pleier å ligge på 70% av filstørrelsen (sånn ca da) i gjennomsnitt, det er ihvertfall mitt inntrykk.

 

AtW

[Spydz]

I Software Engineering faget har jeg lært at gode ideèr er veldig bra. Dårlige ideèr er også helt fint. De ideène som er problematiske er de halvgode ideène som virker fornuftige, men som etter en del ressurser er brukt opp viser seg å være helt på trynet..

Tror du er inne på noe veldi vesentlig der!!!

 

[ATWindsor]

For å komme med ett litt mindre tekniske og kanskje oppklarende tankeekspriment til md5-ideen.

 

Jeg tenker på ett tisifret tall, tversummen er 39, hvilket tall tenker jeg på?

 

AtW

[Simen1]

For å komme med ett litt mindre tekniske og kanskje oppklarende tankeekspriment til md5-ideen.

 

Jeg tenker på ett tisifret tall, tversummen er 39, hvilket tall tenker jeg på?

 

AtW

Veldig beskrivende og bra tankeeksperiment. (jeg her helt med på det)

 

Men jeg begynner å lure litt: Er det noen som klarer å regne ut hvor mange forskjellige tisifrede tallkombinasjoner som gir tverrsummen 39?

 

Kanskje noen som vil lage en "liten" løkke som finner dette ut med brute force? Bør ikke ta mer enn noen få minutter dersom den er kompilert effektivt.

 

For å spore ennå mer av: Jeg tenkte her om dagen på om det går an å lage et program som regner ut hvilken strategi i yatsee som gir best vinnersjanse. Regner ut sansyynlighet for yatzee, 4 like, 3 like osv ved et gitt terningkast og ut fra det kan gi råd om hvilke terninger det er lurt å satse på for å ha best mulig poeng-sjanser.

[kenny]

Men jeg begynner å lure litt: Er det noen som klarer å regne ut hvor mange forskjellige tisifrede tallkombinasjoner som gir tverrsummen 39?

351 966 340 (tok ca. 4 timer på en A64 3200++)

[Simen1]

Men jeg begynner å lure litt: Er det noen som klarer å regne ut hvor mange forskjellige tisifrede tallkombinasjoner som gir tverrsummen 39?

351 966 340 (tok ca. 4 timer på en A64 3200++)

Hmm... Det var jammen lang beregningstid. Hvordan lagde du algoritmen?

 

Beregningstiden :

En slik løkke lages enkelt ved å lage 10 løkker inni hverandre. For hver løkke har man en variabel (A-J) som settes til 0-9. Inni den innerste løkka summerer man SUM=A+B+C+...+J og sjekker den mot tallet 39. Hvis svaret er 39 så Setter man antall=antall+1. I den nest innerste løkka kan man ha en løkke som sjekker om tverrsummen av de første sifrene er mellom 30 og 39. Hvis ikke så kan ikke den innerste løkka bli 39, og man kan heller bare skippe 10 runder med den innerste løkka. Det samme kan man gjøre med ennå en løkke utenfor, og sjekke om tallet er mellom 21 og 39, og en kløkke utenfor ved å sjekke om tallet er mellom 12 og 39, og løkka utenfor 3-39 og resten av løkkene utenfor: om summen allerede er over 39.

 

Hvis vi sier at en summering av 10 sifre + sjekking mot variabelen 39 + eventuell økning av variabelen antall + å gå til neste trinn i løkka tar 20 sykluser (det er vel realistisk?) så bør altså hele utregninga ta 20* 10 000 000 000 sykluser. (og langt mindre om man har sjekkpunker innenfor hver eneste løkke.) Med en prosessor på 2GHz (= 2 000 000 000 sykluser per sekund) så skal altså hele beregningen ta 100 sekunder. (og ennå mindre med den sjekk i alle løkker). Dermed synes jeg 4 timer høres mye ut.

 

Antall treff :

. . 351 966 340 delt på

10 000 000 000

= ca 3,5%.

Høyeste tverrsum = 90 og laveste = 0. Gjennomsnittlig tverrsum = 45. Vi kan anta at fordelingen av resultater er sentrert rundt gjennomsnittet (45) med symmestisk fordeling oppover og nedover. Ja, resultatet på ca 3,5% høres sansynlig ut. Gratulerer!

[kenny]

Med en prosessor på 2GHz (= 2 000 000 000 sykluser per sekund) så skal altså hele beregningen ta 100 sekunder.

67 sekunder (fortsatt 351 966 340) med den nye algoritmen (2.2GHz, A64 3200++) Rimlig nærme dine forutsigelser altså, ikke verst. Den forrige algiritmen kjørte bare to løkker (nøstet), og brukte string-manipulasjon i stedet for..

[Simen1]

Med en prosessor på 2GHz (= 2 000 000 000 sykluser per sekund) så skal altså hele beregningen ta 100 sekunder.

67 sekunder (fortsatt 351 966 340) med den nye algoritmen (2.2GHz, A64 3200++) Rimlig nærme dine forutsigelser altså, ikke verst. Den forrige algiritmen kjørte bare to løkker (nøstet), og brukte string-manipulasjon i stedet for..

Wow! Snakk om speedup (215x speedup). Kanskje jeg skulle satse på å bli programmerer i stedet for å være Siv.ing? neida Jeg drev litt med programmering for 8-9 år siden men har glemt det meste siden da. Du har gjort en god jobb!

 

Trodde egentig at det skulle bli ennå kortere tid med sjekk i alle løkkene, men det var kanskje å håpe litt mye. Også overvurderte jeg kanskje IPC'en til kompilert programvare (1 per syklus er kanskje litt drøyt). Hadde det bare vært håndprogrammert maskinkode så hadde jeg tippet rundt 1 sekund.

Endret 29. mai 2004 av Simen1