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: 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: 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: 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: DRM for batteries
http://www.intersil.com/cda/deviceinfo/0,1477,ISL6296,0.html "A 32-Bit CRC-based hash engine (FlexiHashTM) calculates the authentication result immediately after receiving a 32-Bit random challenge code." huh? heh! - 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: Trillian Secure IM
I found those threads: http://forums.ceruleanstudios.com/showthread.php?t=53433 http://forums.ceruleanstudios.com/showthread.php?t=56207 As you can see from the last post in the second thread, ultimately they agreed that 128-bit DH is secure and that I am just some crazy guy trying to scare them. Ruptor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Trillian Secure IM
If that's DH exchange, then it's 128 bit one. Fertile ground for some interesting speculation, don't you think ? There is no speculation. It is 128-bit DH. I have reported over three years ago to the Trillian forum that they are using 128-bit DH and that it is not secure. You can look up my messages about it and how much I got abused for it by everyone trying to explain to me that 1) it IS secure and 2) no one cares anyway. They did not change it since then although they promised to. I'd also made an open-source replacement DLL back then with 512-bit ECDH, which also supported their 128-bit DH clients if they initiated secure communication first, but it may have some compatibility issues with later versions of Trillian. It's supposed to display the common key fingerprint, not sure if it works now. Feel free to correct it and to improve it, but Cerulean Studios won't pay for it. It's still on http://cryptolib.com/ruptor/ Marcos el Ruptor PS: There was also a buffer overflow in their original DLL if you send a very long key. I don't know if they have fixed it or not. I haven't used Trillian since I bought a Mac. - 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: Cracking the code?
My questions are: A) is this as vulnerable as it seems at first blush? B) how many password/hex pairs would be needed to deduce the underlying algorithm?, C) If one could deduce the algorithm, could the attack be generalized so that it could be used against other enterprises that use the same software? (It is very(!) widely deployed), and D) am I missing something in my thinking? A) yes it is vulnerable. B) none - it would take no time to reverse engineer the entire algorithm out of the executable. C) yes of course. D) just how bad this is. Ruptor - 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: handling weak keys using random selection and CSPRNGs
The only things that it usually passes as good are for-purpose random number generators' or ciphers' outputs. Everything else (including a terabyte of RC4 output, executables, zip archives, jpegs, mpegs, mp3s, ...) that I've pointed it at, fails one or more of the tests. Have you tried removing the headers and trailing data? True random-looking-ness is hard to find... :-) Since when? There are plenty of easy ways to generate it. Many compressed files will also pass your randomness tests if you test only the compressed data itself, not the whole files. 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. [*] 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%3D1&langpair=zh-CN%7Cen&hl=en&ie=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: 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: Status of attacks on AES?
Right. But can you explain *why* you strongly believe in it? In the last 10 years it never failed to tell the difference between good and bad ciphers. The only thing that makes it controversial is its ability to detect flaws in ciphers believed to be strong simply because no attacks against them are found yet. We do not believe in the approach "if no one broke it in N years, then accept it as secure until they do" alone. We believe in combining it with studying algebraic structure of the resulting functions from every angle with automated tools, and if they display obvious sparsity or patterns in the distribution of monomials of any algebraic degree, or if the size/output or size/security proportions are too low, or if too many rounds are required for a change to make those functions different in a way indistinguishable from random (slow avalanche of change as we see it), the cipher should be discarded even if no one can find a way to break it. Here's an example: replace XOR with ADD in RC5 and try to attack it by any means other than the Mod N attack found years after RC5... But our tests immediately show that the cipher is easily breakable. They also immediately show weakness of the first two bytes in RC4 and breakability of such ciphers as A5, LILI, etc. The list can go on and on. Often there is no explanation for years until an attack is found, but our tests help us detect presence of flaws in seemingly strong ciphers in a matter of minutes. I personally do not bother analysing ciphers that fail our tests - someone else will break them sooner or later anyway. I immediately discard them as breakable and concentrate on the hard ones to see if the cipher structure needs to be addressed. But if the cipher doesn't have any odd components that it relies on and that can be attacked individually and if its proportions are chosen correctly, I accept it as secure. The fact that Rijndael fails our tests so terribly prohibits me personally from trusting it even though no attack breaking it has been published. I would use Twofish or RC6 instead. Passing our tests combined with years of public scrutiny makes me believe that Twofish and RC6 can be trusted. Rijndael cannot. Ruptor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of attacks on AES?
http://defectoscopy.com/forum/viewtopic.php?t=3 http://defectoscopy.com/results.html and http://defectoscopy.com/background.html Are there any peer-reviewed descriptions of your technique? Right now, all that site seems to have -- and forgive me if I've missed a link -- is a set of simple assertions about various ciphers, plus a fairly vague background page. Put another way, and I hate to be this blunt, is there any reason to think your results are correct and/or meaningful? Good, bad, right, wrong, correct, incorrect, meaningful, meaningless... Who knows? Don't ask us. We are simply trying to contribute something new that we strongly believe in, that may not be much, but that may also turn out to be great. It's a very new site with too few results and is too early to judge. It seems that some people liked our project and decided to advertise it already and are showing some interest in it. We did not expect it to attract any attention just yet and we did not want to promote it until there were results for a few more dozen ciphers and hash functions. I am sure there will be as many opinions as there are assholes as Klint Eastwood says, but it doesn't change the facts about our tests. As we say on the web site, if you want proofs, send us your challenge ciphers. We love them. But we are very reluctant to participate in polemic debates. Our tests are controversial enough and their results speak for themselves. Wait till we publish our results for a few more ciphers and soon you'll see how all the new designs measure up way before any attacks breaking them are found. We are not academics struggling to prove their academic qualification and not a corporation struggling to market its product, so if you don't mind, we'll leave you believing whatever you want to believe and just get back to work. Ruptor PS: Constructive productive positive contributions are also welcome. [Moderator's note: Marcos el Ruptor perhaps does not understand the concept of peer review and may be unfamiliar with the fact that there is a large existing literature in the field. Perhaps that should say something in itself. --Perry] - 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]