This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - quasi_Phthalo
31
« on: July 10, 2010, 02:40:24 pm »
hey, on a side note, think of how famous the ti-community would be if we factored ANY 2048 bit key, not specifically the nspire's. so, ponder this: if you multiply two 2048 bit keys together, and try to factor that, you now have to locate one of 4 possible prime numbers in a field that is no larger than if you were factoring a single key alone. you've just doubled your chances, which halves the amount of time it takes to do it! with 4 keys together, you could factor one of them in 1/4 the time!!!! actually, its a little longer than that because you're working with a bigger number, but still!!!! ok, so we won't be able to factor the specific key we want, necessarily, but we'll still be famous for being the first people to factor a 2048 bit RSA key!!!
32
« on: July 09, 2010, 11:02:13 pm »
you could always throw in some algorithms to test if a ray intersects a particular plane defined by 3 points within that triangular (or rectangular if 4 pts) boundary defined by those points. Then you have 3d models of whatever you want (within the computational feasibility of the nspire). Ex: a tall pyramid atop a tall rectangular prism for DJ's tree. 
33
« on: July 09, 2010, 11:45:03 am »
French dancing is really.....hmm.....shall i say....interesting? (no offense to all the french guys on here)
34
« on: July 06, 2010, 11:15:27 pm »
did you use the appropriate 8xp files for your specific calculator? iirc, the process was a bit complicated; are you sure you did exactly what the readme said? *TIP* check the BAOS source code for a certain file *cough* clean.rom*cough*, i think its 83PSE. Who said that? (looks around innocently) 
35
« on: July 06, 2010, 12:31:45 pm »
wait, TASM works fine for me on 64-bit windows 7.... but, yeah, it was so silly to make devpac8x a com file instead of exe, otherwise we wouldn't have this problem you mean wabbitemu? i don't think it packs 8xp files if all else fails, look up the 8xp file schematics and write your own program to pack it (that's what i did)
36
« on: July 01, 2010, 02:38:58 pm »
have you ever wondered if the government (or RSA Laboratories) has a list of all these factors for all these keys somewhere for security purposes?
37
« on: June 30, 2010, 04:35:55 pm »
it essentially lets us *cough*hack*cough* the nspire, write custom OSes for it, etc.
and GNFS (general number field sieve) is the 'sophisticated' part of the guess and check system
38
« on: June 30, 2010, 04:28:37 pm »
well, you could try the wikipedia page on rsa keys
basically, we've got this number n, and we know that it is the product of two VERY LARGE prime numbers p and q. And there's this other number d that we really want to have, but the only way to get it is to break into TI headquarters, or figure out what p and q are. The only way to do that is with a sophisticated 'guess and check' system that would possibly take years
39
« on: June 30, 2010, 04:20:48 pm »
If you write a program that starts with three wouldn't it be best to start at sqrt(n) and work either up or down (both if adventuresome) because don't the factors usually have about half as many digits as n? so, they'd be closer to sqrt(n) than 3 or n/3
40
« on: June 30, 2010, 02:42:45 pm »
i was messing around with really smalls keys just for the fun of it, and sometimes my d would come out negative and i'd have to add phiPQ to it
41
« on: June 30, 2010, 10:17:51 am »
really, the chances of us solving this before we can make a quantum computer to do it don't look too go. we should wait until then 
42
« on: June 28, 2010, 11:17:45 pm »
what would happen if, instead of this:
set output high
wait 2 ms
set output low
wait 2 ms
repeatyou did this:
set output high
wait 1 ms
set output low
wait 3 ms
repeat
what kind of sound would the second one make?
43
« on: June 28, 2010, 10:37:24 pm »
ok, so i've made it so that it re-seeks on the reads that would carry the seek pointer to the third byte as a temporary work around. i hope this can be fixed eventually, because the seek delay every 33ish frames starts to get really annoying towards the end when it's the longest
44
« on: June 27, 2010, 02:26:33 pm »
you could change the seek pointer yourself i've tried that (See one of my earlier code postings) and it works for the most part (sometimes a single frame will be half garbage) except, since the file i'm using is large, the seek time gets longer and longer the farther you go, until it's eventually impractical to try to play a movie. i've editted an earlier post. the garbage was actually happening when the seek pointer carried to the THIRD byte, not second
45
« on: June 27, 2010, 02:18:08 pm »
Why doesn't your code have $BB, $6D at the start? Nothing else jumps out at me at first glance. i'm a purist: i don't want to mar my program with a TI token. i let my 8xp packer to do that for me. so, i took your advice, and watched the file handle. I HIGHLY doubt that it's coincidence that the garbage data comes in on the very frame at which the seek pointer carries to the second third byte (editted). Also, the 'type' of garbage changes at every carry. and i took you other advice to only read 512 at a time: same issue in the same place editted
|
Show Posts