Re: [Cryptography] PRISM-Proofing and PRISM-Hardening
On 19 Sep 2013 19:11, "Bill Frantz" wrote: > > On 9/19/13 at 5:26 AM, rs...@akamai.com (Salz, Rich) wrote: > >>> I know I would be a lot more comfortable with a way to check the mail against a piece of paper I >> >> received directly from my bank. >> >> I would say this puts you in the sub 1% of the populace. Most people want to do things online because it is much easier and "gets rid of paper." Those are the systems we need to secure. Perhaps another way to look at it: how can we make out-of-band verification simpler? > > > Do you have any evidence to support this contention? Remember we're talking about money, not just social networks. > > I can support mine. ;-) > > If organizations like Consumers Union say that you should take that number from the bank paperwork you got when you signed up for an account, or signed up for online banking, or got with your monthly statement, or got as a special security mailing and enter it into your email client, I suspect a reasonable percentage of people would do it. It is, after all a one time operation. As with other themes though, one size does not fit all. The funny thing being that banks are actually extremely adept at doing out of band paper verification. Secure printing is born out of financial transactions, everything from cheques to cash to PIN notification. I think it was Phillip who said that other trust models need to be developed. I'm not as down on the Web of trust as others are but I strongly believe that there has to be an ordered set of priorities. Usability has to be right up there as a near-peer with overall system security. Otherwise as we've seen a real attack in this context is simply to dissuade people to use it and developers, especially of security oriented systems can do that of their own accord. If you want to get your systems users to help with out of band verification get them 'talking' to each other. Perry said that our social networks are great for keeping spam out of our mailboxes yet were busy trying to cut out the technology that's driven all of this. Out of band for your banking might mean security printing techniques and securing your email, phoning your friends. > > Cheers - Bill > > --- > Bill Frantz| If the site is supported by | Periwinkle > (408)356-8506 | ads, you are the product.| 16345 Englewood Ave > www.pwpconsult.com | | Los Gatos, CA 95032 > > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On 18 Sep 2013 07:44, "Christoph Gruber" wrote: > > On 2013-09-17 Max Kington wrote: > > > [snip] > > Hence, store in the clear, keep safe at rest using today's archival mechanism and when that starts to get dated move onto the next one en-masse, for all your media not just emails. > [snip] > > I would tend to agree for environments with very high regulations, where the need to comply with regulations is more important than the need to keep data confidential. > I would suggest to balance that for every organisation. The risk to disclosure is much higher if data is stored unprotected. Any admin with access to the file system is able to read it. > Maybe this could be a cultural difference between US and Europe, the regulative pressure in US is higher, in Europe the privacy is more important or more protected. > I agree that both ways may be the right implementation for an organisation, but this has to be a management decision, balancing the needs. I was referring to the UK :-) I'm not saying it isn't important to consider how data is made available in the cases where you have end to end security but a future standard wants to be permissive of a solution even if it's out of scope for the RFC rather than prohibitive by including it as mandatory, could/can vs should/must. That said now there appears to be evidence that side channel attacks that force lesser security where it's an option are being actively exploited. Previously we'd have all assumed that the main benefit of those was in interoperability but now not so much. So there is an argument to use 'must' more in standards concerning security. By making archival a separate concern you also reduce the complexity of many deployments. As you say, for environments with very high regulation, my personal mailbox, isn't, my work one, is. Max > > Best regards > > -- > Christoph Gruber > "If privacy is outlawed, only outlaws will have privacy." Phil Zimmermann > ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] End to end
On 17 Sep 2013 15:47, "Christoph Gruber" wrote: > > On 2013-09-16 Phillip Hallam-Baker wrote: > [snip] >> >> If people are sending email through the corporate email system then in many cases the corporation has a need/right to see what they are sending/receiving. > > [snip] > > Even if an organisation has a need/right to look into people's email, it is necessary to protect the communication on transport and storage. Of course a certain way of key recovery has to be in place. > > Just my 2 cents I intend to reply in more detail to the draft there's lots of very interesting work there. The most common approach to ILM for email in highly regulated sectors I've seen is to divorce the storage and transport mechanism and associated security from the long term storage. In a corporate environment the message is captured pre encryption and transmission and stored. Whilst key escrow mechanisms do exist the risk is that what gets escrowed isn't what was sent if you maliciously want to tunnel data (imagine not being able to decrypt a message at the request of the SEC or FSA because the key you were sent is wrong by the desktop app, or conversely having to decrypt everything first to check). You have the added issue of having to store all the associated keys and in 7 years (the typical retention period over here for business now regarded as complete, let alone long running contracts still in play) still have software to decrypt it. Hence, store in the clear, keep safe at rest using today's archival mechanism and when that starts to get dated move onto the next one en-masse, for all your media not just emails. Hence for the purposes of your RFC perhaps view that as a problem that doesn't require detailed specification. M > >> -- >> Website: http://hallambaker.com/ >> >> ___ >> The cryptography mailing list >> cryptography@metzdowd.com >> http://www.metzdowd.com/mailman/listinfo/cryptography > > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] prism proof email, namespaces, and anonymity
On Fri, Sep 13, 2013 at 10:12 PM, Perry E. Metzger wrote: > On Fri, 13 Sep 2013 16:55:05 -0400 John Kelsey > wrote: > > Everyone, > > > > The more I think about it, the more important it seems that any > > anonymous email like communications system *not* include people who > > don't want to be part of it, and have lots of defenses to prevent > > its anonymous communications from becoming a nightmare for its > > participants. If the goal is to make PRISM stop working and make > > the email part of the internet go dark for spies (which definitely > > includes a lot more than just US spies!), then this system has to > > be something that lots of people will want to use. > > > > There should be multiple defenses against spam and phishing and > > other nasty things being sent in this system, with enough > > designed-in flexibility to deal with changes in attacker behavior > > over tome. > > Indeed. As I said in the message I just pointed Nico at: > http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html > > Quoting myself: > >Spam might be a terrible, terrible problem in such a network since >it could not easily be traced to a sender and thus not easily >blocked, but there's an obvious solution to that. I've been using >Jabber, Facebook and other services where all or essentially all >communications require a bi-directional decision to enable messages >for years now, and there is virtually no spam in such systems >because of it. So, require such bi-directional "friending" within >our postulated new messaging network -- authentication is handled >by the public keys of course. > The keys. This to me is the critical point for widespread adoption, key management. How do you do this in a way that doesn't put people off immediately. There are two new efforts I'm aware if trying to solve this in a user friendly way are https://parley.co/#how-it-works and http://mailpile.is. Parley's approach does at least deal with the longevity of the private key although it does boil security down to a password, if I can obtain their packet and the salt I can probably brute force the password. I've exchanged mails with the mailpile.is guys and I think they're still looking at the options. Max ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Summary of the discussion so far
egal assistance treaty and they're signed with an awesome number of countries. They only enable cooperation to the extent that local law allows and have different rules about support that allows evidence that can be admissible in court and other kinds of support. So it comes back to what you're worried about, it doesn't have to be about absolutes Max > > I'd love to be disabused of the above though. > > Nico > -- > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Books on modern cryptanalysis
On 11 Sep 2013 18:37, "Bernie Cosell" wrote: > > The recent flood of discussions has touched on many modern attacks on > cryptosystems. I'm long out of the crypto world [I last had a crypto > clearance *before* differential cryptanalysys was public info!]. Attacks > that leak a bit at a time strike me as amazing. I remember reading about > attacks that involved running chips at lower voltage than they were > supposed to have and that somehow allowed them to be compromised, etc. > > Anyhow, are there any (not *too* technical) books on the modern > techniques for attacking cryptosystems? How modern is modern? :-) I have modern cryptanalysys by Christopher Swenson (or at least did have before it was loaned and I moved) and it was an excellent book and crucially was very accessible. Also available in kindle format now. It is 5 years old now though. Regards Max > > Thanks. /bernie\ > > -- > Bernie Cosell Fantasy Farm Fibers > mailto:ber...@fantasyfarm.com Pearisburg, VA > --> Too many people, too few sheep <-- > > > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] SPDZ, a practical protocol for Multi-Party Computation
On 11 Sep 2013 18:01, "Eugen Leitl" wrote: > > > http://www.mathbulletin.com/research/Breakthrough_in_cryptography_could_result_in_more_secure_computing.asp > > Breakthrough in cryptography could result in more secure computing > (9/10/2013) > > Tags: computer science, research, security, cryptography > > Nigel Smart, Professor of Cryptology > > New research to be presented at the 18th European Symposium on Research in > Computer Security (ESORICS 2013) this week could result in a sea change in > how to secure computations. > > The collaborative work between the University of Bristol and Aarhus > University (Denmark) will be presented by Bristol PhD student Peter Scholl > from the Department of Computer Science. > > The paper, entitled 'Practical covertly secure MPC for dishonest majority - > or: Breaking the SPDZ limits', builds upon earlier joint work between Bristol > and Aarhus and fills in the missing pieces of the jigsaw from the groups > prior work that was presented at the CRYPTO conference in Santa Barbara last > year. > > The SPDZ protocol (pronounced "Speedz") is a co-development between Bristol > and Aarhus and provides the fastest protocol known to implement a theoretical > idea called "Multi-Party Computation". > > The idea behind Multi-Party Computation is that it should enable two or more > people to compute any function of their choosing on their secret inputs, > without revealing their inputs to either party. One example is an election, > voters want their vote to be counted but they do not want their vote made > public. > > The protocol developed by the universities turns Multi-Party Computation from > a theoretical tool into a practical reality. Using the SPDZ protocol the team > can now compute complex functions in a secure manner, enabling possible > applications in the finance, drugs and chemical industries where computation > often needs to be performed on secret data. > > Nigel Smart, Professor of Cryptology in the University of Bristol's > Department of Computer Science and leader on the project, said: "We have > demonstrated our protocol to various groups and organisations across the > world, and everyone is impressed by how fast we can actually perform secure > computations. > > "Only a few years ago such a theoretical idea becoming reality was considered > Alice in Wonderland style over ambitious hope. However, we in Bristol > realised around five years ago that a number of advances in different areas > would enable the pipe dream to be achieved. It is great that we have been > able to demonstrate our foresight was correct." > > The University of Bristol is now starting to consider commercialising the > protocol via a company Dyadic Security Limited, co-founded by Professor Smart > and Professor Yehuda Lindell from Bar-Ilan University in Israel. A colleague is looking into this venture. I gave him a synopsis of their additions to SPDZ. There is a white paper describing their technology at their website which talks about the other two related protocols, Yao and Tiny-OT. One interesting use that occurred to me was the ability to split the two nodes in their implementation across jurisdictions. Especially those who are unlikely to ever collaborate. That giving you an advantage over a typical HSM which could live in a jurisdiction that could be seized. The wp and associated bibliography is available at http://www.dyadicsec.com/SiteAssets/resources1/DyadicWhitePaper.pdf Max > > Note: This story has been adapted from a news release issued by the > University of Bristol > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Usage models (was Re: In the face of "cooperative" end-points, PFS doesn't help)
On 10 Sep 2013, at 17:07, Walter van Holst wrote: > On 08/09/2013 21:51, Perry E. Metzger wrote: >> On Sun, 8 Sep 2013 14:50:07 -0400 Jerry Leichter >> wrote: >>> Even for one-to-one discussions, these days, people want >>> transparent movement across their hardware. If I'm in a chat >>> session on my laptop and leave the house, I'd like to be able to >>> continue on my phone. How do I hand off the conversation - and the >>> keys? >> >> I wrote about this a couple of weeks ago, see: >> >> http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html > > Which is pretty spot-on and one of my biggest gripes about OTR. It just > doesn't mesh at all with user's expectations. > >> In summary, it would appear that the most viable solution is to make >> the end-to-end encryption endpoint a piece of hardware the user owns >> (say the oft mentioned $50 Raspberry Pi class machine on their home >> net) and let the user interact with it over an encrypted connection >> (say running a normal protocol like Jabber client to server >> protocol over TLS, or IMAP over TLS, or https: and a web client.) > > Sounds like another Freedom Box... > > Anyway, if we consider each device an end-point to a group-chat that has > to be verified at least once by another end-point (and that is a > somewhat doable thing, e.g. the socialist millionaire's problem), what > about having end-points being able to vouch for other end-points? It's not a dumb idea at all but getting the 'introduction' mechanism right is tricky. I've implemented something similar where we 'trust' the first endpoint and then allow that well verified device to be bound to other entities. The mechanism I built was that each one gets its own identity and can be peer'ed into a conversation and that the group can in fact decide if it wants to allow the arrival of 'Walter on his Tablet' or 'Walter on his phone' depending on your level of paranoia or that of the group. I don't mind Walter on his PC at work but I don't like sending these messages to Walter on his phone especially when I know he has a habit of leaving his phone on the bus. > > For example if I introduce my smartphone to an already existing instant > messaging chat, I can vouch for it through my PC and if other end-points > already trust my PC, there is no reason not to trust my smartphone either. I've implemented the primary notion around a phone because it's a simple identity, it doesn't change much and it has multiple an out-of-band delivery channels which lends itself to multiple authentication factors. > > If this is a dumb idea, feel free to point it out. It allows other possibilities too, for instance, you can nominate the in-use end point and temporarily suspend others or even kick them out by refusing to complete an MPC protocol with them, exchange new keys and carry on the discussion. The idea of multiple sub-idenities lends itself well to keys which have different lifecycles. So chat for example, where a transient set of keys which, if lost isn't a massive problem but email for instance where loosing them and having stacks of encrypted email in your inbox which is now useless is unhelpful. I'm literally just in the process of building the master entity as a smart card component which can be used to 'introduce' the first device on an NFC capable android platform. From there you can bootstrap the other devices. What I don't know the answer to yet is if material changes need to be notionally signed by the master entity or if introductions can be done by devices as peers. Of course, compromise one device and it winds up with peer introducing rights. There is a usability trade off and I suspect until I've actually tried using it the answer is non obvious. Regards, Max > > ___ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] In the face of "cooperative" end-points, PFS doesn't help
This space is of particular interest to me. I implemented just one of these and published the protocol (rather than pimp my blog if anyone wants to read up on the protocol description feel free to email me and I'll send you a link). The system itself was built around a fairly simple PKI which then allowed people to build end-to-end channels. You hit the nail on the head though, control of the keys. If you can game the PKI you can replace someone's public key and execute a MITM attack. The approach I took to this was that the PKI publishes peoples public keys but then allows other users to verify your public key. A MITM attack is possible but as soon as your public key is rotated this is detected and the client itself asks if you'd like to verify if out of band (this was for mobile devices so it lends itself to having other channels to check keys via, like phone your friend and ask them). The much more likely thing is where someone tries to do a MITM attack for just a particular user but as the channels are tunnelled end to end they need to essentially ask the PKI to publish two duff keys, i.e. one in each direction, Alice's key as far as Bob is concerned and Bob's key as far as alice is concerned.. In turn the two people who's traffic the attacker is trying to obtain can in turn ask someone else to double check their. It means that you need to publish an entirely fake PKI directory to just two users. The idea was the alarm bells go off when it transpires that every person you want to get a proxy verification of a public key via has 'all of a sudden' changed their public key too. It's a hybrid model, a PKI to make life easy for the users to bootstrap but which uses a web of trust to detect when the PKI (or your local directory) has been attacked. Relationships become 'public' knowledge at least in so far as you ask others in your address book to verify peoples public keys (all be it via uuids, you could still find out if your mate Bill had 'John's' public key in his address book because he's asked you to verify it for him). So for those who want to protect the conversational meta data it's already orthogonal to that. Group chat semantics are quite feasible in that all users are peers but you run into difficulty when it comes to signing your own messages, not that you can't sign them but that's computationally expensive and the eats battery life. Again, you are right though, what do you want to achieve? I certainly built a protocol that answered the main questions I was asking! As for multiple devices, the trick was always usability. How do you securely move an identity token of some description from one node to another. I settled on every device having its own key pair but you still need an 'owning' identity and a way to 'enrol' a new key pair because if that got broken the attacked just enrols their own 'device' surreptitiously. You then get into the realms of passwords through salted hashing algorithms but then you're back to the security of a password being brute forced. If you were really paranoid I proposed a smart card mechanism but I've yet to implement that (how closed a world are smart cards with decent protection specifications?! but that's another conversation), the idea being that you decrypt your device key pair using the smart card and ditch the smart card if needs be, through a typical office shredder. Silent Circle was one of the most analogous systems but I'm an amateur compared to those chaps. As interesting as it was building, it kept boiling down to one thing: Assuming I'd done a good job all I had done was shift the target from the protocol to the device. If I really wanted to get the data I'd attack the onscreen software keyboard and leave everything else alone. Max On Sun, Sep 8, 2013 at 7:50 PM, Jerry Leichter wrote: > On Sep 7, 2013, at 11:16 PM, Marcus D. Leech wrote: > > Jeff Schiller pointed out a little while ago that the crypto-engineering > community have largely failed to make end-to-end encryption easy to use. > There are reasons for that, some technical, some political, but it is > absolutely true that end-to-end encryption, for those cases where "end to > end" is the obvious and natural model, has not significantly materialized > on the Internet. Relatively speaking, a handful of crypto-nerds use > end-to-end schemes for e-mail and chat clients, and so on, but the vast > majority of the Internet user-space? Not so much. > I agree, but the situation is complicated. Consider chat. If it's > one-to-one, end-to-end encryption is pretty simple and could be made simple > to use; but people also want to chat rooms, which are a much more > complicated key management problem - unless you let the server do the > encryption. Do you enabl
Discrete logarithms modulo 530-bit prime
Thorsten Kleinjung reports recent success on computing discrete logarithms modulo 530-bit (160 decimal digits) prime: http://listserv.nodak.edu/cgi-bin/wa.exe?A2=ind0702&L=nmbrthry&T=0&P=194 Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
A security bug in PGP products?
Hello! Could anybody familiar with PGP products look at the following page and explain in brief what it is about and what are consequences of the described bug? http://www.safehack.com/Advisory/pgp/PGPcrack.html The text there looks to me rather obscure with a lot of unrelated stuff. Thanks, Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: NIST recommendations for PRNGs
On 6/14/06, Perry E. Metzger <[EMAIL PROTECTED]> wrote: via Bruce Schneier's blog: http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90_DRBG_June2006.pdf It was updated June 30 to the "final" version: http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90_DRBG-June2006-final.pdf Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Factorization polynomially reducible to discrete log - known fact or not?
On 7/9/06, Ondrej Mikle <[EMAIL PROTECTED]> wrote: I believe I have the proof that factorization of N=p*q (p, q prime) is polynomially reducible to discrete logarithm problem. Is it a known fact or not? I searched for such proof, but only found that the two problems are believed to be equivalent (i.e. no proof). Take a look at this paper: http://portal.acm.org/citation.cfm?id=894497 Eric Bach "Discrete Logarithms and Factoring" ABSTRACT: "This note discusses the relationship between the two problems of the title. We present probabilistic polynomial-time reduction that show: 1) To factor n, it suffices to be able to compute discrete logarithms modulo n. 2) To compute a discrete logarithm modulo a prime power p^E, it suffices to know It mod p. 3) To compute a discrete logarithm modulo any n, it suffices to be able to factor and compute discrete logarithms modulo primes. To summarize: solving the discrete logarithm problem for a composite modulus is exactly as hard as factoring and solving it modulo primes." Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: classical crypto programmatic aids
Travis, Take a look at http://www.cryptool.com/ Regards, Max On 6/27/06, Travis H. <[EMAIL PROTECTED]> wrote: Hi folks, Does anyone here know of any computer-based aids for breaking classical cryptosystems? I'm thinking in particular of the ones in "Body of Secrets", which are so short that I really hope they're monoalphabetic substitutions. But I'm interested in these sorts of programs more generally. I could use paper, but it'd be nice if a computer could keep track of what I've tried and otherwise ruled out. I am aware of the "crypt breaker's workbench", but that's specific to classic Unix crypt(3). What else is there? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of attacks on AES?
On 6/8/06, Steven M. Bellovin <[EMAIL PROTECTED]> wrote: You say you have a method to evaluate ciphers. Without full details, no one can form their own judgment if it's valid or not. (My "proposal" clearly isn't valid.) You say you've evaluated AES and other ciphers. Without full details, we don't know if your evaluation is correct. I think they can prove their evaluation without publishing all the details. What they need is just to provide an access to their distinguisher in the form of blackbox. To prove its meaningfulness, the distinguisher must show consistent results in distinguishing AES-encrypted data (say, for a fixed plaintext without repeating blocks on their choice) from random data. Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: U. Washington Crypto Course Available Online For Free
I do not understand why this course got so much attention. What is special about it (besides available video lectures)? I have a whole collection of links to similar courses. Please take a look at http://www-cse.ucsd.edu/users/maxal/e-books.html Just as an example, I can mention UCSD based course "Introduction to Modern Cryptography" by Mihir Bellare and Phillip Rogaway available at http://www-cse.ucsd.edu/users/mihir/cse207/classnotes.html Talking about video lectures, I was impressed by Workshop in Algorithmic Number Theory and Workshop in Number-Theoretic Cryptography at Clay Mathematics Institute: http://www.msri.org/publications/video/index01.html Max P.S. If you know other good courses/lectures on the topic missing in the collection, please share. On 6/6/06, Udhay Shankar N <[EMAIL PROTECTED]> wrote: http://it.slashdot.org/article.pl?sid=06/06/04/1311243 -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is AES better than RC4
On 5/23/06, James A. Donald <[EMAIL PROTECTED]> wrote: AES is new, and people keep claiming progress towards breaking it, without however, so far producing any breaks. RC4 is old and has numerous known weaknesses, which are tricky to code around, and have caught many an implementor - notice for example Wifi. But these are known weaknesses, and no new ones have turned up for some time, nor does it seem likely that they will. I'm confused. AES is a _block_ cipher while RC4 is a _stream_ cipher. How are you going to compare them? It is makes much more sense to compare AES to RC6 block cipher (if you like something from the RC-family of ciphers) but that was already done by the AES standard committee. RC6 became one of the five finalists but then lost the race to Rijndael. Look at the details of AES selection process if interested. Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of attacks on AES?
On 5/3/06, Joachim Strombergson <[EMAIL PROTECTED]> wrote: 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? It worths to look at Nicolas T. Courtois' page: http://www.cryptosystem.net/aes/ Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: RNG quality verification
Similar site aiming to detect defects in various ciphers and hashes: http://defectoscopy.com/ "...where block ciphers can be compared against stream ciphers, asymmetric ciphers and hash functions in their quality determined by the security of each individual component as well as their combination." "We aim to collect all the existing block ciphers, stream ciphers, asymmetric ciphers and hash functions under one roof, proving Shannon's 1949 definition of cipher security to be correct. We also want to show that cryptanalytic progress of the past few decades has enabled automated detection of flaws in cryptographic primitives, thus significantly reducing the amount of time required to determine security or insecurity of a given cryptographic primitive." Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: is breaking RSA at least as hard as factoring or vice-versa?
Yet another paper on the topic: Deterministic Polynomial Time Equivalence of Computing the RSA Secret Key and Factoring by Jean-Sebastien Coron and Alexander May http://eprint.iacr.org/2004/208 Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: MD5 collisions in one minute
On 3/17/06, Weger, B.M.M. de <[EMAIL PROTECTED]> wrote: > You might be interested in knowing that my MSc student > Marc Stevens has found a considerable speedup of MD5 > collision generation. His improvements of Wang's method > enables one to make MD5 collisions typically in one > minute on a PC; sometimes it takes a few minutes, and > sometimes only a few seconds. > His paper (shortly to appear on the Cryptology ePrint > Archive) can be found on http://www.win.tue.nl/hashclash/, > where we've also made his software available (source code > and a Win32 executable). Thanks for interesting info! btw, do you aware of another MD5 Collisions generating software (requiring ~45 minutes per collision) available at http://www.stachliu.com/collisions.html I did not find any references to it in Marc's website/paper. Max - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: jointly create a random value for corrupted party
Anna Rikova wrote:
maybe this is a silly question, but at the moment I
don't know how to solve it. Assume there are 4 partys
A,B,C,D. Now the parties B,C,D want to create a random
value r for A, so that each party B,C,D can verify
afterwards, that A uses indeed the random value r, but
doesn't know the value of r.
I thought of the following solution, but it has a
problem:
Each party I \in{B,C,D} broadcasts a value g^{r_i} mod
p, where r_i is random, p is a large prime and g is a
generator. After that each party sends to A the value
r_i secretly. Aftern that A can compute:
r= r_B + r_C + r_D. If A then uses this value in the
form of g^r everyone can verify that A uses every r_i
in g^r.
What does it mean "A uses this value in the form of g^r"?
A uses r not g^r, doesn't it?
This is a weak point: from A's use of r every party should be able to compute
g^r mod p with no knowledge of r.
I assume you know how to organize that.
This scheme has one problem (at least I think so): The
partys B,C wait till D braodcasts her value g^{r_D}.
Then they choose their values r_B and r_C so that g^r
has a special characteristic e.g. the last bit of g^r
is zero. Then r is not randomly disributed in Z_p,
cause only values are allowed for r, which yield to
g^r with last bit zero.
What's about the following modification?
Each party i\in{B,C,D} sends to A the value of r_i secretly.
Upon receiving all three values A broadcasts
q_1=g^{r_B} mod p, q_2=g^{r_C} mod p, q_3=g^{r_D} mod p.
The party i then verifies that the value r_i was used to produce one of q_1,
q_2, q_3.
From A's use of r every party computes g^r mod p and verifies that g^r=q1*q2*q3.
Max
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
