Re: Ransomware
On 12 Jun 2008, at 03:05, James Muir wrote: Just curious -- where were you able to download the virus from? www.offensivecomputing.net Just be careful. Do not run it. It does not spread itself, but it will encrypt all the sensitive files on all the drives and then self- destruct. If you want a disarmed harmless one to play with, I can e- mail you my decrypted and patched up variant. Marcos el Ruptor http://www.enrupt.com/ - Raising the bar. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ransomware
On 11 Jun 2008, at 20:13, Dave Howe wrote: This would seem to imply they already verified the public key was constant in the trojan and didn't differ between machines (or that I'm giving Kaspersky's team too much credit with my assumptions). I've just looked at the virus. Upon invocation, it generates a random 128-bit RC4 key with CryptGenKey, then for each file it generates a random IV with a very weak generator only capable of producing 256 different 128-bit values for 99.9% of the files, prepends each file with its IV, then it encrypts that IV with the main RC4 key, hashes that with MD5 and that hash becomes the 128-bit RC4 encryption key for each file. It encrypts all the potentially valuable files like that while deleting the originals, then it encrypts the main RC4 key with one of its two hard-coded 1024-bit RSA public keys and saves it with one of the 4 e-mail addresses it comes with to contact the asshole who did this to you: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Not much can be done at this point as the executable terminates itself creating a script that deletes it and congratulates the user. It's not very different from the 90's hard drive formatting viruses except for the bold extortion that comes with it. A regular backup is your best friend. The only thing that could probably be done by the most desperate would be to find the largest files with known plaintext and for all the encrypted files with the same first 16 bytes (roughly 1/256 of them), the keystream will match. No cryptography to implement, only XOR. Good luck! Best regards, Marcos el Ruptor http://www.enrupt.com/ - Raising the bar. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: survey of instant messaging privacy
Interesting. Of course, with the possible exception of Skype, only the over-the-network part of the communication is protected. The IM providers can still give the contents of your communications to third parties. As far as I can tell after having reverse engineered its protocol, Skype is actually very well made with a few exceptions that would still be next to impossible to exploit for a street hacker (and with only one suspicious thing that looks like a backdoor exploitable only by the server and only by whoever knows the preimages to some hard- coded MD5 values - it looks like a backdoor, it smells like a backdoor, it gotta be a duck). Other than that, peer-to-peer AES-256 with randomly generated RSA keys is good enough for me. As OTR has shown, it's not hard to do end-to-end crypto even if you don't have direct client connectivity. Makes one wonder why the default clients don't have the functionality :) Way too much hassle for them having to deal with the government agencies demanding access to intercepted communications. It goes for all the products developed by large corporations. The general attitude is honest people have nothing to hide aggravated by the encryption export controls and the Wassenaar Arrangement. While Skype was made by Estonians who simply didn't care about any such nonsense. So the cheapest way for the NSA to obtain all the Skype's secret keys giving them at least some access to the servers and traffic obfuscation algorithms was to have a US company pay $4bln for it... Well done! Marcos el Ruptor http://www.enrupt.com/ - Raising the bar. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: skype claims they have no technical means to assist wiretapping
In any event, because of Skype's peer-to-peer architecture and encryption techniques, Skype would not be able to comply with such a request. Well... Total BS and we all know it. 1. Skype servers transparently report the last few known IP addresses to any client requesting them. Just try running two or three Skype clients on different computers - they will all be receiving copies of your messages. While it may not work as an interception tool as it is, because every client will send back acknowledgements, but those can be switched off and such ghost clients can simply monitor all your conversations. It is especially easy to do if you control the server. It can make any client forward several copies of all its packets to other IP addresses. If I have scared anyone, don't worry. Just type /debugchain in your chat window and you will see who is listening [no it won't cure your paranoia, I lied]. 2. Skype can download and install updates automatically without the user's knowledge. Those can be tailor-made for the user with all kinds of additional features like sending all the logs back to the server. 3. Have I mentioned a few things in it that look and smell like server-controlled backdoors? They emit the same foul odour as the 10..1 prime numbers provided by NIST for our elliptic curves, but presented in the standards in random-looking decimal form for extra subtlety... Of course they *are* able to comply with such requests. They just either won't or just won't tell us. Best regards, Marcos el Ruptor http://www.enrupt.com/ - Raising the bar [and disabling Skype SuperNode]. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSparc -- the open source chip (except for the crypto parts)
To be sure that implementation does not contain back-doors, one needs not only some source code but also a proof that the source code one has is the source of the implementation. Nonsense. Total nonsense. A half-decent reverse engineer does not need the source code and can easily determine the exact operation of all the security-related components from the compiled executables, extracted ROM/EPROM code or reversed FPGA/ASIC layout (see the recent Karsten Nohl's extraction of Crypto-1 code for example). All this open-source promotion is a huge waste of time. Us crackers know exactly how all the executables we care about (especially all the crypto and security related programs) work. We do not always publish our results, but look, somehow RC4, SecurID, DST40, KeeLoq, Crypto1, Hitag2, etc. all got reverse engineered and published when people actually cared to do it. A lot more other closed-code ciphers, random number generators and other components have been reverse- engineered and thoroughly analysed without publishing the results just because those results were not interesting, could do more harm than good if published or if keeping them secret could benefit the cracker. As a reverse engineer with over 20 years of experience, I can guarantee everyone on this list who is not familiar with this process that from the security evaluation point of view there is ABSOLUTELY NO BENEFIT in the open-source concept. It is actually much much easier to hide a backdoor in the C or especially C++ code from anyone reading it than it is in the compiled assembly code from a reverse engineer, even if it is highly obfuscated like Skype. High-level languages offer enough opportunities to hide and cover up some sneaky behind-the-scenes magic that no one will notice for years or ever at all unless they know exactly what to look for and where. I always compile the open-source code, then reverse engineer it and see what it is actually doing. If you want a guarantee or a proof, better ask all the reverse engineers you know to take a closer look at the program and tell you if there is a backdoor, anything malicious or anything sneaky or suspicious. Don't trust your own eyes. I've seen too many open-source applications with well-concealed backdoors or unnoticeable security holes. Linux's endless exploitable vulnerabilities should be enough of a proof of that. Best regards, Marcos el Ruptor http://www.enrupt.com/ - Raising the bar. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Philips/NXP/Mifare CRYPTO1 mostly reverse-engineered
The 48-bit Philips Hitag2 algorithm has been completely reverse- engineered a long time ago: http://cryptolib.com/ciphers/hitag2/ Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: debunking snake oil
I didn't realise the current SecurID tokens had been broken. A quick Google doesn't show anything, but I'm probably using the wrong terms. Do you have references for this that I could have a look at? http://eprint.iacr.org/2003/162.pdf This attack may not be as practical as an algebraic attack would be, but it shows that SecurID keyed hash function is in fact weaker than what its claimed 64-bit security level demands. AFAIK, algebraic cryptanalysis of the RSA SecurID keyed hash function by the academic sector hasn't even been performed yet. Their new tokens use AES-128. Maybe they do learn after all... Ruptor http://defectoscopy.com/ - There is no need to design weak ciphers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: debunking snake oil
I'd like to start with the really simple stuff; classical cryptography, systems with clean and obvious breaks. You can start with RSA SecurID, Texas Instruments DST40, Microchip Technologies KeeLoq, Philips/NXP Hitag2, WEP RC4, Bluetooth E0, GSM A5... It's much harder to find a product or technology that implements proper ciphers, proper hashes, proper RNGs or proper protocols. And I don't mean small mistakes like in SSH1 or SSL. I mean look at all those proprietary weak ciphers sold for millions! Will they ever learn? Ruptor http://defectoscopy.com/ - There is no need to design weak ciphers. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
Compared to AES-128, AES-256 is 140% of the rounds to encrypt 200% as much data. So when implemented in hardware, AES-256 is substantially faster. Excuse me, AES-256 has the same block size as AES-128, that is 128 bits. It's in fact slower, not faster, and in hardware it also occupies a substantially larger area. If you are talking about Rijndael with 256-bit blocks, that's not AES and its variant with 256-bit keys would still be slower and would also occupy a substantially larger area in hardware than its counterpart with 128-bit keys. Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: handling weak keys using random selection and CSPRNGs
Now, you said compressed files and you might not have meant pictures, but note that L-Z style compressed files don't really have much in the way of headers. If the headers were a problem, you'd expect longer files to bury any deviation in the noise, but it doesn't. The longer the files I test the more certainly non-random they are. I stand by my statements. Greg. Hello, Greg! I did not say anything about pictures. I only said that it's not that hard to find a compression algorithm or a source of randomness or a simple PRNG that will pass all kinds of randomness tests. You said it's hard, I said it wasn't. Maybe you want to try testing something packed with WinRK or Durilca for example. You could probably even test the whole files packed with them... Although I totally agree with you that JPEG or ZIP (Deflate) or LZ compressed data could only pass randomness tests if the data was random to begin with. But come on, such weak ancient algorithms hardly qualify as randomness benchmarks. Modern decent compression algorithms like those used in Stuffit or Allume reduce JPEGs by about 25% or so (losslessly). No wonder your tests show a bias! On the other hand, maybe you have an amazing brilliant randomness test there that fails all the compressed files and makes diehard look like a baby's rattle... If that is the case, do share! ;-) Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: skype not so anonymous...
One thing is possible with Skype: any user can easily obtain any other user's IP address (actually both internal and external IPs). Those users don't even need to be on his contact list. Of course one would need cracking tools or a decrypted patched Skype executable with all the 288 integrity checks removed to make Skype spit out its debugging logs, unless one knows the right values for the HKCU\Software\Skype\Phone\UI\General\Logging and Logging2 registry keys that Skype checks comparing their MD5 hashes. There is not much else that can be done, but that is one possibility. Of course, if a direct connection is established, any TCP/IP monitoring tool would show all the contacted IPs. Although in this case it's obviously the man's stupidity using an instant messenger with his old virtual identity that got him tracked down. No one stopped him from registering a different Skype account to contact whoever he trusted if he didn't want to be found. But I have to agree that Skype could be made anonymous and is not anonymous at all. It's much harder to obtain someone's IP address in other instant messengers where users can disallow direct connections and thus remain anonymous at least to other users. Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypto to defend chip IP: snake oil or good idea?
You can use cryptography to protect IP and to prevent cloning of microchips even if they get reverse-engineered, but the cipher would have to possess special properties similar to those of VEST ciphers (see http://www.ecrypt.eu.org/stream/vestp2.html), like support family keying to make every ASIC chip implement different secret but secure logic, etc. eBeam, lasers and other technologies are available for that. ECC and other standard ciphers can't possibly do that. Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Chinese WAPI protocol?
unpublished cryptographic algorithms. The specification is secret and confidential. It uses the SMS4 block cipher, which is secret and patented. [*] It's been declassified in January 2006. The SMS4 cipher specification - http://www.oscca.gov.cn/UpFile/200621016423197990.pdf Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Chinese WAPI protocol?
unpublished cryptographic algorithms. The specification is secret and confidential. It uses the SMS4 block cipher, which is secret and patented. [*] http://translate.google.com/translate?u=http%3A%2F%2F72.14.205.104%2Fsearch%3Fq%3Dcache%3Ae2RxJ6kpw4QJ%3Awww.oscca.gov.cn%2FUpFile%2F200621016423197990.pdf%2Bsite%3Awww.oscca.gov.cn%2Bsms4%26hl%3Den%26ct%3Dclnk%26cd%3D1langpair=zh-CN%7Cenhl=enie=UTF8 is a very long link to the google's cached specification paper translated to english. It shouldn't be too hard to understand. ;) Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of attacks on AES?
Can you briefly explain how you determine the PRF rounds value? William Your question belongs in our forums - http://defectoscopy.com/forum/viewforum.php?f=3 where it's already being discussed. Ruptor [Moderator's note: no, actually, if you're going to mention it here, you had better be prepared to explain and defend it here, too. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of attacks on AES?
I skimmed this. The start of the article says that after 3 rounds AES achieves perfect diffusion?! 1. It's complete diffusion, not perfect diffusion. Perfect diffusion is a property meaning something completely different. 2. My post incorrectly stated that cryptographers believed that the AES achieved complete diffusion after 3 rounds. In fact, in Rijndael complete diffusion (every bit influences every bit in the block or state) is achieved by the end of the second round. I have corrected the post. A simple square attack (that I teach in class in about 60 mins) recovers the key of 4-round AES with 256 chosen-plaintexts. The six-round attack isn't too much harder. Isn't what you are referring to called secure number of rounds? In other words the number of rounds after which no known attack exists that can break the cipher faster than brute-forcing the key? It looks like I have no choice but to invent a new term, PRF rounds - the number of rounds after which each function that defines the value of each bit of the block/state/output is a pseudo-random function (PRF) of all the bits of the block/state/key/input, in other words a function indistinguishable from random by any existing general purpose randomness tests. Of course dedicate randomness tests exploiting the cipher structure and utilising a significant amount of computational resources could be effective in distinguishing a larger number of rounds from random, but that's in the area of the secure number of rounds research. PRF rounds is usually larger than the complete diffusion rounds. For most good ciphers it's usually somewhere between the complete diffusion rounds and the secure rounds, but for some ciphers it's either way over the secure rounds or it never happens at all (LILI, KeeLoq, Trivium, etc). Some ciphers maintain sparcity of their functions or their distinguishability from random even if iterated perpetually. I have corrected all the articles: http://defectoscopy.com/forum/viewtopic.php?t=3 http://defectoscopy.com/results.html and http://defectoscopy.com/background.html Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of attacks on AES?
On Wed, 10 May 2006 10:01:57 -0600, John R. Black wrote On Thu, May 04, 2006 at 10:30:40AM -0500, Marcos el Ruptor wrote: http://defectoscopy.com/forum/viewtopic.php?t=3 Expect new attacks soon enough. I skimmed this. The start of the article says that after 3 rounds AES achieves perfect diffusion?! It doesn't say that. Obviously you didn't read the article. It says that the current version of our general purpose automated black-box tests can easily distinguish 4 rounds of the AES from random and it says that *if* the AES achieved complete diffusion [in the context of automated cryptanalysis] in 3 rounds [as Whirlpool does for example], then maybe 10 rounds could suffice against most attacks although we would advise 12. But with 5 rounds required to pass our tests we have serious reasons to believe that the AES will be broken in the near future and that at least 20 rounds are required for it to be secure. Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of attacks on AES?
Aloha! Just out of curiosity I tried to Google around for recent papers on attacks against AES/Rijndael. I found the usual suspects with XLS attacks and DJBs timing attack. But what is the current status of attacks, anything new and exciting? http://defectoscopy.com/forum/viewtopic.php?t=3 Expect new attacks soon enough. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Not everyone knows about strong crypto...
The recently arrested boss of bosses of the Sicilian Mafia, Bernardo Provenzano, wrote notes using an encryption scheme similar to the one used by Julius Caesar more than 2,000 years ago, according to a biography of Italy's most wanted man. Sicilian mafia also uses mobile phones that change their IMEI numbers on every call (like it really does something)... and they paid a lot of money for them too. Apparently they don't believe in encryption. Ruptor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
