Re: 2048-bit RSA keys
Paul Hoffman wrote: You are under the wrong impression, unless you are reading vastly different crypto literature than the rest of us are. RSA-1024 *might* be possible to break in public at some point in the next decade, and RSA-2048 is a few orders of magnitude harder than that. Just out of curiosity, assuming the optimal use of today's best of breed factoring algorithms - will there be enough energy in our solar system to factorize a 2048-bit RSA integer? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Symmetric ciphers as hash functions
Hi all, How does one properly use a symmetric cipher as a cryptographic hash function? I seem to be going around in circles. Initially I thought you choose some known key and encrypt the data with the key, using either the encrypted text or the internal state of the cipher as the hash value, turns out all one needs to do to break it, is decrypt the hash value with the "known" key and you get a value which will produce the same hash value. Reversing the situation (using the data as the key and a known plain- text) makes a plaintext attack seem like a joy etc.. Are there any papers/books/etc that explain the implementation/use of symmetric ciphers (particularly AES) as cryptographic hash functions? btw I know that hash functions and symmetric ciphers share the same structural heritage (feistel rounds etc...), I just don't seem to be making the usage link at this point in time... :D Any help would be very much appreciated. Kind regards Arash Partow Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Query about hash function capability
Hi all, My question relates to hash functions in general and not specifically cryptographic hashes. I was wondering if there exists a group of hash function(s) that will return an identical result for sequentially similar yet rotate/shift wise dissimilar input: ie: input1 : abcdefg -> h(abcdefg) = 123 input2 : gabcdef -> h(gabcdef) = 123 input3 : fgabcde -> h(fgabcde) = 123 Here a,b,c,d,e,f,g represent symbols (ie: groups of bits with equivalent group sizes etc...) I know that one simple hash method would be to add the symbols together, but the results would also be equivalent if say the symbols were in any order, also collisions would occur with other totally dissimilar sequences that happen to have the same sum as the sequence. Is there anything out there research/papers etc, or is this a meaningless avenue of enquiry? any help would be very much appreciated. Arash Partow __ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Encryption Software Infers Guilt
OK, the subject was a little exaggerated. But in anycase feel free to read the following article: http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-1030_3-5718978.html Regards Arash Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: I'll show you mine if you show me, er, mine
Reading the description from http://www.stealth-attacks.info/, it seems that Peter might be right. I think this is just a re-hash of already well established ideas. In the case of a sending the password back to B, its a very similar scenario to scene III where Athena suggests to Euripides that the ticket life-time be once off (once use), Euripides goes "it would make using services on the network too difficult why not give it a time stamp for the duration of the person's work day" - a ticket generating ticket. The play goes on from there, in the end "Charon" which is then quickly renamed "Kerberos" is made. Then 1988 now 2005, I would say thats about 13 years... :) Name of play is "Designing An Authentication System: A Dialogue In Four Scence" by Bill Bryant Arash Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: How thorough are the hash breaks, anyway?
Hello, NO sorry I can't understand the logic here, I think I understand the maths behind message digests pretty well and to that point I don't see how the recent results diminish the current crypto grade hash functions in the least. The researchers have brought about an obscure plain text and provided another text that produces the same hash values But in reality, what people (i.e.: attackers) want is something like this: Attack at 1pm to become Attack at 3pm with common hash values and not something like this: AtTaZk @ Epn Even if it did pass the crypto test i.e.: message digest, the literal acceptance by a person would not pass. Now lets assume the case of binary data, most data nowadays is compressed then encrypted. finding a text which will also be uncompressible-per-compression-algorithm and also pass the message digest for another particular text heck you'd have better luck finding snow in the middle of hell. also nowadays some people tend to use multiple digests of data sort of like pealing the onion, in this case including the compression related difficulties etc it all becomes very very near impossible. Possible but highly improbable To date attacks on crypto (not the software but the algorithms) have been centered around people implementing the algorithms incorrectly i.e.: weak primes etc, in situations where everything is done by the book, only software implementations of the algorithms and also users of the system remain as the weak links in the chain known as a crypto system. In a final word I would like to say thank-you the people that did this research, the results were needed in order to prove a theory. However everything should be taken into context. Arash Partow __ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
Hello, I've had a look at the code, the main problems I see are side-channel attacks. The implementation is pretty standard, strong primes, proper fields etc, however no salt! Key generation, or more so the process of key generation should be unique every time regardless of how unique the parameters being passed into the process are. I think a few months ago a student from the weizmann inst. http://www.wisdom.weizmann.ac.il/~tromer/acoustic/ proposed analysis of cpu noise as a side channel attack, the test code was PGP's key generation. That said acoustic attacks are not the only method for side channel attacks, you have power and timing attacks, in theory if you could sample these 3 channels you could be in much better position than if you were only sampling one of the channels. In short updates should be made to add salt to the calculations, simple random operations being randomly added during the generation process will suffice to eliminate the possibility for any of the above attacks. Other than that PGP is pretty much standard, and unless tomorrow someone comes up some really wacked-out number theory that will prove futile many of the principles of the mathematics behind the crypto systems of today I wouldn't worry too much ;) Arash Partow __ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net Jon Callas wrote: On 10 Aug 2004, at 5:16 AM, John Kelsey wrote: So, how many people on this list have actually looked at the PGP key generation code in any depth? Open source makes it possible for people to look for security holes, but it sure doesn't guarantee that anyone will do so, especially anyone who's at all good at it. <http://www.pgp.com/products/sourcecode.html> The relevant key generation code can be found in: libs2/pgpsdk/priv/crypto/pubkey/ (those are backslashes on Windows, of course). The RSA key generation, for example is in ./pgpRSAKey.c. You might also want to look at .../crypto/bignum and .../crypto/random/ while you're at it. There is also high-level code in .../crypto/keys/pgpKeyMan.c for public key generation. Incidentally, none of the issues that lrk brought up (RSA key being made from an "easy to factor" composite, a symmetric key that is a weak key, etc.) are unique to PGP. This should be obvious, but I have to say it. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
