elFarto

Members
  • Content count

    201
  • Joined

  • Last visited

Community Reputation

206 Neutral

About elFarto

  • Rank
    Member
  1. Arrays versus Linked Lists

    Don't use .obj files, they're a pain. I use a custom format that basically resembles the format I need for the GPU with all the information needed for the draw calls, I then mmap the file in and upload the relevant bits to the GPU. I have about 120 lines of code to import an obj/mtl file, and 14 lines to load my own custom format (4 more lines of code to upload it to the GPU). So, my suggestion, move the conversion of the model to an offline process, then you don't have to worry about how fast it is. Regards elFarto
  2. UDP Multicasting

    Quote:Original post by hplus0603 This is a section ripe for DOS attacks. Oh hell yeah. All the multicast stuff is from time where the internet was full of fluffy bunny rabbits and folks greeting you with "Good day kind sir", now it's more burnt out cars and "Gimme all your money". Regards elFarto
  3. UDP Multicasting

    Quote:Original post by hplus0603 ...this means that every router on the internet must know about your multicast group (and all multicast groups)... With IPv6 Embedded RP (RFC3956) this is no longer true. Of course it still won't work over the internet as we don't really have IPv6 yet. Regards elFarto
  4. [java] Java socket problems

    I've found that available() is not a particularly reliable method. The simplest method for you would probably be to use a separate thread to receive data from the socket. You would just need to do something like this when you create your client: Thread t = new Thread(new Runnable() { public void run() { while(true) { String message = m_input.readLine(); System.out.println("Message From server: " + message); CommunicationProtocol(message); } } }); t.start(); This will allow the socket to block, but not prevent your main loop from being blocked by it. This, of course, opens you up to synchronisation issues, since CommunicationProtocol can now be called at any time. You could modify the above method to, instead of calling CommunicationProtocol directly, it could place the message in a Queue (either an ArrayBlockingQueue or LinkedBlockingQueue would do) and process that queue in your main loop. Regards elFarto
  5. Here's a link to a presentation on [PROTOTYPE]'s entity system (I've not seen it posted before). http://cmpmedia.vo.llnwd.net/o1/vault/gdccanada09/slides/marcinchadyGDCCanada.ppt Rather than just having components, they have attributes and behaviours. Regards elFarto
  6. Quote:Original post by XTAL256 Firstly, I should apologise for my incorrect usage of the term "relative addressing". What i mean was that the generated release assembly was using call instructions like this (where i assume 43B148h is a function address): call dword ptr ds:[43B148h] But the debug assembly was correctly using the function address that is either loaded or passed into the remote function: call edx This is not relative addressing but it is not absolute addressing, i should have been more clear about that. My bad. I believe it is referred to as an indirect call (the call edx version) and direct call (the call dword version). Regards elFarto
  7. Replace message.capacity() with message.remaining() in receivedMessage. Regards elFarto
  8. username and password encryption

    Quote:Original post by Antheus Quote:Original post by elFarto Users have been conditioned to type in the password when ever asked, without too much thought given to whom they are giving it to. Better to give them something they can't give away easily, like a certificate. A former bank of mine, many years ago, would do this. No password, install software, it installs and validates the certificate and voila - from then on, whenever you log in, certificate ensures authenticity. A few weeks back I had to set up the system for same bank again - despite their software still being documented using win98 screens, uses same authentication system. In other words - anyone that opens a browser on that computer has access to entire bank account - no password, nothing. As mentioned above, you need to password protect the certificate to stop people just stealing that. Quote:Original post by Antheus Quote:Original post by elFarto Hmmm...fingerprints would be quite good. You can't really give them to anyone, it's quite noticeable if they are stolen and the user can never forget them. The readers are a little more common nowadays but you'd still have to make that method optional. An acquaintance of mine had their office broken into. They stole PC + card reader + authentication card. Fortunately, the password wasn't written down anywhere, so by the next morning, the perps could not have either contacted support or find it out otherwise. The measly 12345 password (or whatever it was) saved the account. I'm not entirely sure on your point here, other than to say 2-factor authentication is better than 1..? Hardware tokens must have their PIN/password set otherwise it makes them just as bad as passwords. Regards elFarto
  9. username and password encryption

    Quote:Original post by hplus0603 Quote:"Hello this is the Citehbank, I need to know username and password and 3 TANs for check all money still there". Speaking of which: Any good, peer-reviewed, secure solutions to that problem? That, I would be seriously interested in (and impressed by)! Easy, don't give them a password :) A password protected/encrypted private key/certificate should work quite well. Bonus points for using it to establish the SSL/TLS session. I think it's been proven by the amount of scams/phishing attempts we see, that passwords are just not very good mechanisms for security by themselves. Users have been conditioned to type in the password when ever asked, without too much thought given to whom they are giving it to. Better to give them something they can't give away easily, like a certificate. Initial distribution of the certificate could be an issue. Perhaps we need a hardware token to make it secure? I wonder if an actual fingerprint would work...? Hmmm...fingerprints would be quite good. You can't really give them to anyone, it's quite noticeable if they are stolen and the user can never forget them. The readers are a little more common nowadays but you'd still have to make that method optional. Food for thought anyway. Regards elFarto
  10. username and password encryption

    Quote:Original post by hplus0603That makes HASH(PASS) be the new secret. Someone can pretend to be the authorized client by only knowing HASH(PASS) and not knowing PASS. Thus, storing HASH(PASS) is no safer than storing PASS; if the table is compromised, users can be impersonated. True, but if your servers get compromised you're pretty screwed anyway. Regards elFarto
  11. username and password encryption

    If you hash a password with say, SHA-1 or SHA-256, the output will be the size of an AES key (128-bit or 256-bit). You can then generate a random AES key and encrypt it with the first one. If you were using prime numbers, then you were doing asymmetric encryption such as RSA, AES is a symmetric block-cipher. Wikipedia has a good page on AES. Regards elFarto
  12. username and password encryption

    The method is based on Kerberos (at least, my understanding of it). Step 2 in your sequence is wrong, it should look something like this: 1. The client sends username to server. 2. Server encrypts a randomly generated session key with the user's hashed password. 3. Server sends the encrypted session key to the client. 4. Client decrypts the encrypted session key with the hashed password. 5. Server and client communicate with the session key The server doesn't directly authenticate the client, but by encrypting the session key with the hashed password, it means that only someone who knows the password can decrypt the key and continue to communicate with the server. The password is a shared secret, both parties already know it, there's no need to send it anywhere. Just create a problem which can only be solved with the password. Here is a good overview of Kerberos. Regards elFarto
  13. byte swapping optimization

    Isn't the XOR swap method slower on modern CPUs, due to the dependency created between the instructions forcing it to execute them in order. Regards elFarto
  14. username and password encryption

    Another way of doing it is to have the client send the username to the server (unencrypted) and have the server respond with a random session key encrypted using the clients hashed password. The session key can then be used for all future communication. This way the password never leaves the clients machine, cannot be intercepted, and the database stores HASH(PASS). Regards elFarto
  15. The usual way to store tile data is something like: int WIDTH = 2048 int HEIGHT = 2048; int world[] = new int[WIDTH * HEIGHT]; int tile = world[y * WIDTH + x]; You're probably better off creating a Tile class instead of using an int. Regards elFarto