Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
Is Serpent-256 better than Rijndael-256 in terms of security? (speed doesn't matter)
Would Serpent encryption combined with SHA-512 be enough to safeguard sensitive data?
And to what extent? (SECRET, TOP SECRET, CLASSIFIED etc.)
Moreover, Rijndael has a max of 16 rounds. Serpent has 32 rounds, so it must be more secure.
As I've read that the Rijndael cipher is cryptographically broken, why isn't Serpent
adopted more widely? Would it be that slow if implemented on hardware?
Any other technical specifications about Serpent that you can link me to, I would be very grateful.
Thank you.
The number of rounds, by itself, doesn't determine the security of a cipher. You need to take the round function into account before the number of rounds means anything.
Nonetheless, I'd agree that there's a pretty decent chance that Serpent is more secure than AES. There are attacks currently known against AES that reduce the complexity by a factor of approximately 4 compared to a pure brute-force attack.
Cryptographers count that as a successful attack--but from a practical viewpoint, it's of precisely zero consequence. Even if you restrict yourself to AES-128, it's basically reducing complexity from 16 times the estimated life of the universe to only 4 times the estimated life of the universe (I'm sort of making up numbers here, but you get the general idea). With AES-256, the number is so much larger the factor of four shrinks to a new level of utterly meaningless insignificance.
Until/unless a dramatically better attack is found, real security is completely unaffected. In essentially every case, the problems you need to deal with and worry about are in how the cipher is used, how keys are generated, stored, and exchanged, etc. Changing from AES to Serpent (or Mars, Twofish, etc.) is extremely unlikely to improve your security (or anybody else's).
I should probably add: I'm probably as strong an advocate as anybody of having more cipher algorithms available and standardized. If you do a little looking, you can find where I'm cited in the papers submitted to NIST during AES standardization on that subject, giving use cases where including more than one algorithm in the standard would have been useful. Nonetheless, I have to admit that no (publicly known) current attack even comes close to giving a real reason to choose a different cipher algorithm.
I am looking for ideas for algorithms and data structures for representing volumetric objects. I am working on a sculpting system, like sculptrix or mudbox, and want to find a good implementation strategy.
I currently have a very nice dynamic halfedge mesh system to collapse/subdivide faces. It works very well and is incredibly fast, but since it is a surface algorithm, it is not easy to robustly change topology.
So I want to go back to the drawingboard and implement a proper volumetric system. My first idea was some kind of octtree representation for the volume and marching cubes to polygonise it.
However, I have a few problems with this. First, marching cubes often produces small or thin triangles, something that is highly undesirable (reason why later). Second, I want to polygonise the volume only in the area of editing, and at different levels of detail. For example, I may want a low res sphere, but with a few tiny high res bumps. I can easily get that kind of subdivision behaviour with my current surface based sustem, but I can't envision how I could do it robustly with marching cubes.
Another problem is that the actual trianglular mesh is further subdivided on the gpu for smooth surfaces, so I need neighbourhood information too. Again, I already have this with the current half-edge system, but with a volume polygonisation system, I imagine it taking a lot of extra processing to find the extra connectivity information. This is the reason thin triangles are bad.
So I have a lot of constraints, and I am asking this community for ideas or pertinent papers to read. I was thinking about surfacenets to avoid the small/thin triangle problem. Also, I have a feeling kd-trees may be better for storing multiresolution volumes since they seem more flexible then octtrees.
Anyway, any ideas/suggestions very welcome.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Could you recommend some good articles/notes/tutorials on finite element method (FEM)? I don't deal with advanced math every day, so a tutorial that introduces me to math needed to understand FEM will be great.
My goal is to write my own simulation of deformable bodies (+plasticity). I must use FEM, but it will be good if I will know BEM (Boundary element method) and FDM (Finite difference method) too.
Really understanding Finite Element Methods requires quite a bit of fairly advanced mathematics; unless you have a few years to devote to the cause, let's leave that aside for now.
That said, the basic ideas underlying FEM are fairly simple if you have some experience with ODE solvers. Can you tell us some more about your background and what you really want to learn so that we can suggest some appropriate resources? Do you want to learn the underlying mathematics, or do you just want to learn some cookbook recipes for applying FEM to a certain class of problem?
Your question is unclear. I don't know what you want to know, because it's impossible to tell what you're ignorant of here.
You don't deal with advanced math every day. What do you know about the finite element method? Here are topics you'll need to know:
Statics and dynamics; how to draw free body diagrams
Solid mechanics - strength of materials, elasticity,
Continuum mechanics for large strain models: Lagrangian and Eulerian formulations
Material models - elasticity and plasticity
Partial differential equations
Method of weighted residuals and integral equations
Linear algebra
Numerical methods
Geometric modeling - CAD for geometry and meshing for FEA models
Commercial or open source packages
You don't say whether you want to use a commercial package (ANSYS, NASTRAN, ABAQUS) or something that you'll write.
As far as references go, there are lots of books available now, but they aren't easy to read or absorb. I'd recommend T.J.R. Hughes' Dover book on the subject. It's cheap and good.
But it's not easy.
I just skimmed through the paper. It looks like a survey article, with nothing new to contribute to the state of the art. It covers a lot more than just small strain plasticity of metals. I see fabric models, large strain problems, etc.
It also mentions boundary element methods and finite difference methods. Do you want to know about those, too? Boundary element methods are completely different from finite elements. The former are based on Green's function formulations; the latter use method of weighted residuals.
The paper doesn't have a great deal of depth to it, but it's very broad. What do you want to know?
I don't think it's possible for someone with so little background to write their own. A better place to start would be FENICS.
I can recommend Introduction to Finite Element Methods by Carlos A. Felippa. It is relativly easy to read.
You can find it here, the Chapters are linked on the main page.
Only the direct stiffness method is covered, think of deformations of trusses without time considerations.
It follows a very nice 'hands-on' approach with examples in Mathematica which are well suited for developer folks.
A really good introduction to FEA for beginners is "Practical Stress Analysis with Finite Elements" by Bryan J Mac Donald. This concentrates on stress analysis but shows you how the method works from both a practical and a theoretical point of view. Unlike a lot of other books it is not specific to any particular software and it is written in plain, easy-to-understand language.
I am creating a game where I want to determine the intersection of a single line. For example if I create a circle on the screen I want to determine when I have closed the circle and figure out the points that exist within the area.
Edit: Ok to clarify I am attempting to create a lasso in a game and I am attempting to figure out how I can tell if the lasso's loop is closed. Is there any nice algorithm for doing this? I heard that there is one but I have not found any references searching on my own.
Edit: Adding more detail
I am working with an array of points. These points happen to wrap around and close. I am trying to figure out a good way of testing for this.
Thanks for the help.
Thoughts?
Your question has been addressed many times in the game development literature. It falls under the broad category of "collision detection." If you are interested in understanding the underlying algorithms, the field of computational geometry is what you want.
Bounding rectangle collision detection in Java
Collision detection on Stack Overflow
Circle collision detection in C#
Collision detection algorithms
Detailed explanation of collision detection algorithms
Game development books will also describe collision detection algorithms. One book of this sort is Game Physics by Eberly.
CAPTCHAs that ask users to read distorted text are fine for sighted people, but a terrible barrier for those who are blind or have other disabilities. Audio alternatives are occasionally available but still don't help those who are both deaf and blind and can be hard to use with a screenreader (which is already reading words to you).
There exist a couple of solutions that use humans to solve the CAPTCHA on behalf of the user, such as WebVisium and Solona, but these rely on the availability of volunteer operators (for example, Solona apparently has just one volunteer so you have to hope he is awake when you want help).
It occurs to me that the volume of CAPTCHA solutions needed by blind people is very low - I'd guess less than a few hundred per day in a populous country like the UK. This means that unlike the bad folks who want to perform an action many times in a short period, a CAPTCHA assistance service for blind people could afford to devote considerable computational resource - for example, a cloud of computers in Amazon EC2 - to identifying the presented text.
My question is this: assuming you don't care about speed very much, and you have lots of computers available, are there algorithms that let you solve the text-distortion CAPTCHAs that are common today, such as those used by reCaptcha? Or are these problems really intractable even with lots of resource and time?
A few notes:
At this point, my question is just theoretical, but clearly any such service would have to carefully control access to keep spammers out. Perhaps only registered blind people would be allowed to use it.
I am aware that an old Yahoo CAPTCHA was broken a few years ago using an algorithm that runs in seconds on a single computer. I am asking whether modern CAPTCHAs can be broken, perhaps more slowly and with more resource.
I am aware that some new CAPTCHA types are appearing, which ask users to identify kittens or orient a picture. These aren't widespread yet, so I'm just asking about text-distortion for now.
Basically solving a text distortion CAPTCHA consists of three individual steps:
Find out where the interesting parts are
Segment the text into individual letters
Recognize the letters
The only problem that's left which is pretty hard for computers is the second one. The first usually isn't very hard, unless you happen to stumble upon the CAPTCHA from hell. And the third gets solved by computers with a much better success rate than by humans.
An interesting site for learning how CAPTCHAs are broken is the one by the OCR Research Team.
CAPTCHA has been created to avoid machines from detecting the words. It's meant to be read by humans only. Making it more readable for blind/deaf people adds a risk of machines being able to understand them again, thus nullifying their effect.
Spammers did find a very effective way to break the more popular CAPTCHA's though. They just hire cheap labourers to read them, in return for a few cents per working account. As a result, there's a small industry around breaking CAPTCHA's to create millions of accounts that can then be used to send more spam. Compared to the amount gained by the spammers, the costs is almost none. A similar solution could be used by blind/deaf people, who would send the CAPTCHA image to some cheap labourer in China or wherever, where they will reply with the correct words and the blind/deaf person will be able to proceed. Unfortunately, blind people only need this service only a few times while spammers need a continuous flow, thus those labourers will prefer to work for spammers instead. (The pay is better.) Still, the best solution would be to send the CAPTCHA to some friend, let them read and/or decipher it and return the answer.
The ReCAPTCHA style also reads out the words. A simple speech recognition application might be able to recognise whatever is said, although speech recognition still needs more optimizations. Still, you might want to work from that angle, getting the application to listen to the sound byte instead.
When it is possible to break CAPTCHA's, they will just think of better CAPTCHA-like methods. OCR techniques are still improving thus more work will be done to make CAPTCHA's harder. That is, until OCR has become as good as the human eye at recognizing words...
An algorithm could be created, although slow. With 26 lowercase and 26 uppercase letters and 10 digits, it should not be too difficult to come up with an algorithm. With Serif and Sans-serif fonts, the number of combinations would need to be doubled, though. Still, if you try to curve all letters in a similar way as the letter in the CAPTCHA, you should be able to detect a letter which gets covered by the CAPTCHA letter the most. And that would be the most likely candidate. Still needs you to clear lines, dirt and other artefacts from the image that the human eye has less trouble to recognise than a computer. You'd need the following steps:
Clean up the image.
Detect the locations of the letters.
For every letter
3a. Determine the curve of the letter by checking the left side.
3b. Do an overlay of every possible letter/digit to find the one that covers it the best. (That's the most likely letter.)
Once you've found the word, do a dictionary check to make sure it's a real word. (Unless the CAPTCHA doesn't use real words.)
Even though they can twist the letters in the CAPTCHA's, it should be possible to detect the twist rotation that they used simply by looking at the left side of every letter and then trying to apply the same curve to every letter. (52 combinations, plus 10 digits, if digits are also used.) Basically, you'd try to put a box around every letter, then check which letter will contain the least amount of white space. That's the most likely letter.
The main reason why this isn't often used for OCR is basically the need for speed. Step 3a/b tends to be slow, especially if you have to take font style in consideration.
Making this answer bigger but in reply to one of the comments:
There are several ways to cleanup an image. You'd need some color filtering, noise reduction and an algorithm that's able to recognise the noisy lines through an image. The DEFCON slideshow that you've pointed to shows a few simple techniques to filter away some of the noise. It shows that a basic image processing tool can already make an image a lot clearer for a machine to read. A simple blur will clean up random dots and thin lines while color filters would filter away the noisy colours. A next step would be to try to put a box around every letter in the CAPTCHA, hoping the system is able to recognise their locations. I don't know any practical algorithms for this but there should be ways to recognise them. There's software that can create vector images from bitmaps, thus there should be software that's able to calculate a box around a letter.
It is likely that this box won't have rectangular corners, thus you would have to distort all 52 letters to match the same box. Italic or bold shouldn't make much of a difference since these styles are just additional distortions. Serif or Sans-serif does make a difference, though. Serif fonts tend to have a few more spikes and ornaments. Fortunately, there are algorithms that can transform a box to any other figure with four corners.
Regular OCR applications will assume that letters are mostly straight and will just check a few hotspots to find a match. Thus, they sometimes get it wrong because of noise. To crack CAPTCHA, you would need a more sensitive match, preferably "XOR-ing" the CAPTCHA letter image with an image of one of the 52 letters, then counting the number of black and white spots to calculate the ratio. Assuming white=1 and black=0, the result of the XOR should be almost black for the best match.
I think several spammers have already found some useful algorithms to crack CAPTCHA's but for them, keeping these algorithms a secret just keeps them in business.
Another comment, more text. :-)
Segmentation would be a problem, but it's not impossible to solve. It's just extremely complex. But when you've cleaned the image, it should be possible to calculate two lines. One line that touches the bottom of every letter and a second line that touches the top. However, good CAPTCHA's won't put letters on the same lines any more, but those not-so-good ones could be cracked by just following the lines. (Guess? ReCAPTCHA puts letters between two lines!) With two lines, you know the first letter will start at the left, thus you can try overlaying all 52 possibilities there until you've found a match. When you found one, move to the right for the second one. And further until you've read all letters. With two lines to guide you, you don't need a complete box.
Letters tend to use a constant ratio between width and height. With two lines, you can calculate the height of the complete letter and thus get a good estimation of the matching width.
Still, working out the correct algorithm to calculate this all is a bit too much for my poor math skills. You'd need an expert mathematician to crack this algorithm.
My answer to your question "are these problems really intractable even with lots of resource and time?" is to point out that this is the very reason that CAPTCHAs work.
My understanding is that the purpose of a CAPTCHA is to prove that you are human rather than a spam bot. reCAPTCHAs are a novel take on this theme because they take images that represent text that cannot be resolved by OCR (optical character recognition) engines. The difference between a person and a machine in this instance is that specialized algorithm(s) has tried to interpret this image and failed while a "normal" person has the intrinsic ability to interpret the text in a consistently human way. That being said, in the future we hope that someone will come up with better OCR engines so that there needs to be less human intervention in digitizing the worlds information. We hope that someone will come up with an tractable solution to this particular problem.
From your point of view of trying to make CAPTCHAs more accessible to blind people -- who still need to prove that they're people rather than spam bots -- the community needs to become aware of this issue and find a way to identify people in a less vision centric way.
The introduction of CAPTCHA has certainly made the web less accessible to the visually impaired, and I agree with you in citing this as a significant problem that deserves more attention and concern. However, while CAPTCHA can be and has been inconsistently bypassed on popular web sites, I don't think this is a viable long-term solution for those in need. Indeed, the day that the CAPTCHA variants currently present on sites like Facebook, Google, MySpace etc. can be reliably and consistently broken is the day they will become obsolete and abandoned for either stronger variants of the same or an entirely new solution (as you implied, distinguishing cats from dogs in pictures has been a popular alternative trend).
When it comes to online accessibility, what I think those with disabilities need most right now is advocacy. The more people contact software companies, open source groups, and standards bodies and speak out about this need, the more awareness will be raised and that will (hopefully) lead to more action on behalf of the development community. Ultimately, it would be great to see sites like Google or Facebook offering alternative access methods just for their visually impaired users.
Idealism aside, I think it is productive to pursue other avenues like you mentioned with the CAPTCHA volunteer network, possibly even the development of something like OpenID for those with relevant disabilities as a universal form validation pass.
As for the technical aspect of your question, I don't think the availability of additional processing power alone will allow you to reliably and consistently break CAPTCHA. There is A LOT of money in spam, and you can be sure that shady SEO companies and Spammers alike have a great number of servers at their disposal. As Johannes Rössel mentioned, if you want to learn more about how this is done and where the technical difficulty lies, research Optical Character Recognition (OCR) and look at the wide variety of number/letter skewing that occurs on high traffic sites.
This related SO question has a number of good ideas in it, including a DEFCON talk that claims using multiple OCRs and voting breaks many simple CAPTCHAs. This suggests a candidate solution method: distribute the problem over several servers, each of which runs one or more OCR tools in parallel, collect the results, and take the most popular answer. Comments welcome.