• Crack C Map Charts Free Download
• C-map Charts For Sale
• C Map Charts Crack

There are also crack groups who work together in order to crack software, games, etc. If you search for 'free c map charts crack', you will often see the word crack amongst the results, which implies it is the full version of the product. The C-Map Marine Web Store supports browsers from the following versions: Internet Explorer 9, Chrome 32, Firefox 29 for Windows Safari 6, Chrome 32, Firefox 29 for iOS Safari 6, Chrome 32, Firefox 29 for OS X. C-MAP MAX - GPS Maps & Software, Electronic Charts, C-map Charts, C-MAP MAX. Home About Us Help Center Advice & Tips. Account Login Cart Checkout. The C-MAP Chart Catalog allows you to view, navigate, select and order C-MAP electronic charts, or various weather options, in an interactive way. After selection of required items is completed, simply press the 'E-mail order' button, and enter the address of your local C-MAP distributor.

OpenCPN is a free, open-source navigation program (CPN stands for Chart Plotter Navigator) that's been in active development for several years. You can freely download versions for Windows (all versions, including XP, Vista, and Win7/8), Macintosh, and even several flavors of Unix. It reads and displays several different chart formats, both vector and raster, including the CM93 chart database (v2, but not v3 as of 2015) that covers the whole world. You can annotate charts with new or additional information, lay tracks of where you go, import tracks from other cruisers, plan routes, display GRIB weather data, upload routes to your GPS and/or autopilot, etc. It does a wonderful job with AIS, as the alarms can be extensively programmed.

Much of this page describes interfacing OpenCPN with Google Earth (GE) using the GE plugin for OpenCPN. For using GE to generate KAP files that OpenCPN can read, see our KAP Files page. For now we've provided info on the following topics:

What we do on Ocelot
We've been using OpenCPN since 2010 (when they added Chart Quilting) and are very happy with it. It is constantly under development so new features are being added by a dedicated team, many of whom are also cruisers. Features can be requested and all such requests are seriously considered. There are several active discussions on Cruisers Forum where features and/or problems are discussed and solved (the developers respond personally). New releases come out once or twice a year and since the software is 'open source' all new versions are also free. In fact, you are free to download the source code and add new features yourself if you want to.

While we used to use the Google Earth (GE) cache and the GE plugin for OpenCPN (described on this page) we now tend to use GE2KAP to make a series of KAP files (KAPs) from GE and display those in OpenCPN. GE2KAP now makes the process pretty easy and automatic, and the resulting KAPs are both permanent and sharable with other cruisers (although usually too large to post on the internet). We describe the process of making and using KAPs from GE on our KAP Files page.

Raster Charts vs. Vector Charts:
Electronic charts usually come as either Raster charts or Vector charts, and most navigation programs can use both types. But there are some significant differences and limitations with each chart type.

Google Earth and OpenCPN:
One of the best aspects of OpenCPN (IMHO) is its tie‑in with Google Earth (GE). GE is an amazing system. Google has put satellite photos of almost the entire land surface of the earth online, and accessing it is free! Users can view, annotate, and even download the images, all for free.

OpenCPN now has a plug‑in for Google Earth that is well worthwhile, and you do not have to be online to use it for navigation! Electronic charts are usually fairly accurate, but are often displaced from where they should be by significant distances (sometimes miles). We don't know how they do it, but GE is spot‑on accurate. Our GPSs are repeatable to 3‑6 feet (1‑2m) and accurate to perhaps 30' (9m). Everywhere we've checked, GE is at least as accurate as our GPSs, and MUCH more accurate than our charts. The main problem with GE is that it does not include accurate depth information or other aids to navigation (like lights), and while it often shows shallow underwater features (if the water is clear) it doesn't always show, for instance, that sunken rock that you need to avoid when entering the bay. So the trick is to be able to see both GE and your charts, either side‑by‑side or overlaid, and this is what the GE plug‑in for OpenCPN lets you do. Unfortunately, as of 2015, the GE plugin for OpenCPN is only available for Windows operating systems, not Mac or Linux. (Note that KAP files created from GE imageryare transportable across different operating systems, but as of 2015, those KAP files may have to be created using a Windows computer.)

Crack C Map Charts Free Download

How to use GE when you're offline:
When you go to new places with GE, it has to download the information it displays from the Google servers. These are fairly large graphical files, so it can take some time, even with a broadband internet connection. GE displays a little circle in the lower right corner of the GE window, to show download progress. When the circle completes (and turns color) then you know that the download for a given view has completed, and you can move on to your next view. But to save time (and internet bandwidth) GE caches (saves) this received information on your computer. So going back to somewhere you've already been to displays very quickly, because the information is coming directly from your own hard drive.

So the trick to using GE offline is to use GE to visit those places that you want to go beforehand, while you have an internet connection. Then you save the GE cache files somewhere. When you cruise to those places, copy the cache files back so that GE can use them again.

WARNING: We have noticed that Google updates their database every few weeks. If you then let your GE client connect to its servers, the servers will notify the GE client to only use the new database. This causes the client to ignore any cache files from earlier databases! We find this hugely annoying, as it can take several hours to accumulate a few GE caches. Therefore, once we've accumulated several caches, we don't let our GE client contact its servers (or get on the internet) so it thinks our caches are still valid and it will continue to use them. If anyone has a better solution here, pleasecontact us!

GE and KAP files:
KAP files are one of the chart types that OpenCPN (and many other navigation programs) can read and display. KAP files are raster‑type charts (essentially, a picture of a chart) so they're relatively large files and as you zoom in, features get fuzzy. The software knows nothing about KAP files except how and where to display them.

There are several ways to take a snapshot of a GE image and convert that snapshot into a KAP file. Our KAP Files page shows how to automate this process to produce groups of KAP files (KAPs) with minimal overlap. They can be programmed to follow a coastline, or to cover an area. KAPs have the advantage that you don't need the GE Plugin to display GE data, so they can be displayed on Mac and Unix computers as well as Windows computers (although they may need to be generated initially on a Windows computer). While they're usually too large to put on the internet (several GB) they're relatively easy to share with other cruisers you meet. In our opinion, gathering the GE data into the GE Cache and displaying that info with the GE Plugin is faster and easier, but more delicate (caches can be invalidated too easily) and they're not sharable. While we used to prefer using the GE cache and the GE plugin, we now tend to create KAP files, since the tools to automate this process are now much better, and the resulting KAPs are both stable and sharable.

Setting up to use the Google Earth Plugin:
You should only have to do this stuff once. It looks a bit complicated, but that's mainly because we're trying to explain everything as we go along. This actually happens pretty quickly and easily.

Saving Google Earth information:
You will want to do this for each place that you plan to cruise to where you'll want GE information. This looks complicated, but it really just breaks down to:

• Start GE
• Go to your area of interest
• Clear the GE cache
• Scan the coastline with GE
• Save the cache files for later use.

To start each session (but you don't have to do this for each new area):

• Shut down GE and OpenCPN if either are running
• Start Windows Explorer and go to the storage location you created earlier (ex: My DocumentsOpenCPNGoogle Earth Caches).
• Position this window on the right side of your screen (on Win7 and later, grab the top bar and run it into the right edge of your screen, then let go). This will be referred to as the Right WE Window.
• Right click on the shortcut you created to the GE Cache and select Open in a New Window.
• Position this new window on the left side of your screen, as above (this is the Left WE Window).

For each new area that you want GE information, do the following:

1. Start the Google Earth application.
2. Click on the world and rotate it to the area that you're interested in.
3. If the world tilts (it usually does) then in the upper right, grab the N and move it back to the top of its circle.
4. Zoom in until you're poised above your area of interest.
5. Go to Tools, Options to open the GE Options window.
6. Go to the Cache tab (see image at right).
7. Make sure the Disk Cache Size (MB): is set to 2000 (this should not change).
8. Click the Clear Disk Cache button. It is important to do this before EVERY new area.
9. Click OK to dismiss the GE Options window. (GE will blink here)
10. Continue zooming in to your area of interest.
11. Always make sure the circle in the lower right corner finishes going around and turns color before moving to your next view. This indicates that all data has been downloaded into your cache for this view.
12. Go around all coastlines at about 6,000' (2000m) to get good resolution (these altitudes are only approximate).
13. When you see something of interest (marina, anchorage, rock, bommie, etc) zoom down to about 4000' (1200m) for maximum detail, then zoom back out.
14. Make sure you cover all coastlines and islands in your area of interest.
15. Periodically, go to your Left WE Window, select all the files there (ctrl‑A), right click and select Properties. If the total file size gets close to 2GB, stop and save the cache. Once the cache gets to 2GB, GE will start throwing away data, as the maximum cache size is 2GB. Dismiss the Properties dialog box.
16. Zoom out to get some larger scale views as well.
17. Go back to an area you've already been to and verify that the circle in the corner finishes quickly, indicating that the info is coming from your cache instead of the internet.
18. Close GE to make sure all info is written to the cache.
19. In your Right WE Window, create a folder to hold the info you've just collected (for example: Chagos).
20. Copy (don't move) the shortcut to the GE Cache into this new folder.
21. In your Left WE Window, copy all files and folders to the new folder you created in your Right WE Window. Windows may bring up a warning about dangerous files, but this can be dismissed. Click in the files area, hit CTRL‑A to select all files and folders, right‑click, drag them to your new folder, release your right‑click, and select Copy.
    • Note: Older versions of GE only used the 3 files dbroot_cache, dbCache.dat, and dbCache.dat.index for its cache files, but newer versions of GE have changed their cache configuration. Unfortunately, this means that caches saved with older versions of GE will not work in newer versions of GE...
22. That's it! Go back up to #1 and go to your next area of interest. Do this for each area that you'll be cruising to.

Using the Google Earth info when you're Offline:
This also looks complicated, but it's really just: Copy your saved cache files to the GE Cache, and start the GE Plugin in OpenCPN. Very simple... (but written for non‑computer folks)

When you're out cruising and you want to use some of your saved GE information:

• If you want to preserve your current GE cache info, save it off as described above (#19‑21)
• Start GE, go to File, and select Server Sign Out.
• Go to Tools, Options.... In the dialog box, select the Cache tab, and click the Delete Cache File button. Confirm the deletion.
• Shut down GE (and OpenCPN if it's running)
• Start Windows Explorer and go to the storage location you created earlier (ex: My DocumentsOpenCPNGoogle Earth Caches).
• Go into the folder of the area you're cruising to (ex: Chagos)
• Select all files and folders except the shortcut to your GE Cache.
• Right‑click on the selected files, drag them to the GE Cache shortcut, release your right click, and select Copy here (not Move).
  • Windows will bring up a dialog box because files of the same name exist in the destination folder
  • Check the box at the bottom of the dialog box that says Do this for the next XX conflicts
  • Click on Copy and Replace (usually the top option)
• Close your Windows Explorer window if you want
• Start OpenCPN
• Start the GE Plugin by clicking on the blue and white ball on the OpenCPN toolbar.
• If you're off the internet, wait until GE displays 2 popup dialog boxes:
  • One says Google Earth failed connect to its database. Click OK to dismiss this.
  • One says that GE could not contact its server and asks if you want to run a diagnostic test. Click No to dismiss this and let GE run out of its cache.
  • If the full GE application window has opened, close that as well and wait for the GE Plugin window to appear in OpenCPN.
• We prefer to have the GE window on the left edge of our screen, taking up perhaps 30% of our screen, but setup the GE window as you like it. On Vista and later, grabbing the top of the GE window and running it into the left edge of the screen will make the GE window take up ~25% of the screen, and you can adjust the window sizes by moving the divider between the GE window and the charts.
• Make sure the Connect to Viewport box is checked at the bottom of the GE window.
• Go to the chart window, left‑click, and wiggle your chart a bit to get GE to sync up.
• If the GE Plugin window doesn't seem to be working correctly, close OpenCPN, restart OpenCPN, and try again. Apparently, GE has a problem changing gears from online to offline.
  • Note that GE will put a significant load on your CPU and graphics processor, and OpenCPN also has performance issues. Better to use a more powerful computer and don't have too many other applications running at the same time.

We have found that overlaying the GE window on top of charts doesn't work very well. Since the charts and GE are running at slightly different resolutions, they don't overlay exactly, which makes for a very confusing display. But feel free to play with it if you want. If you open the Toolbox and go to the PlugIns tab and select the GoogleEarth plugin, there's a Preferences button on the left. In there you can futz with the Floating Window Transparency slider until you can see both the GE info and the underlying chart depths. But since the 2 windows are not precisely aligned, this is of limited usefulness.

Checking chart accuracy:
Folks who can overlay their charts on top of their radar display can verify chart accuracy easily, but that usually requires a chart‑plotter. For us, that would require buying charts of the world, which gets expensive, and our computer already has charts of the whole world, in the form of the CM93 chart database. We never trust the accuracy of our electronic charts too much when approaching a new area. For instance, even the 2009 version of the CM93 chart database has all of Tonga displaced by at least 1/4 mile from it's true position! The Komodo/Rinca area of Indonesia was out by 1/4 mile and much of the Philippines are reported to be out by several miles. This can be very unsettling if you're approaching in the dark. But how do you know, when you're just entering a new area, how accurate your charts are?

One way we've found is to use our radar, which is connected to our NMEA bus and therefore gets GPS positional information (our radar is an NMEA receiver, but not a transmitter). In order to use these methods, your radar must receive GPS information, and it must also receive orientation information (which way it's pointed) from a compass (usually the autopilot's fluxgate compass).

One method is to put our radar's cursor on a prominent landmark (like the tip of an island or peninsula), read off the lat/lon, and compare that to our electronic charts. Similar in concept is to put a waypoint on a prominent landmark, like the end of an island or peninsula. We've found that our radar displays waypoints on the screen, so that is another correlation between our charts and reality (as measured by radar). These methods are not super-accurate, but they'll give you a rough idea, which can be immensely reassuring when entering a new anchorage in the dark.

Checking the Dates of your CM93 Chart Database:
For folks using the CM93 chart database, it's sometimes useful to know how new your charts are. Note that you cannot just look at the timestamps for the folders, as that will be the date you installed the charts. Here's a good method to find your chart database date: OpenWindows Explorer and navigate to your CM93 folder. This is usually under either the root of your main drive, under your C‑Map folder (if you've installed C‑Map), or possibly under My Documents. Under your CM93 folder you should see a long list of folders, all with names that are just numbers. Pick any folder, open it, and you should see several folders with names that are just single letters. Open the C folder and set your View toDetails, to see file dates. Click above the Dates column to sort by Dates. The newest file should be the date for your chart database (most of the files should have very similar dates). You can also check other folders to make sure of the individual file dates.

As of 2015 we've seen CM93 chart databases dated 2000, 2002, 2005, 2006, 2008, 2009 and 2010. All of them have noticeable differences over their predecessors, not always good. While we try to have the latest charts, some of the earlier chart databases had more detail in certain areas, although older charts tend to be less accurate. We also carry paper charts for wherever we go, despite having 4 computers on board, all with electronic navigation packages, and despite having 9 GPSs on board.

MaxSea
MaxSea, by the French company I&M, is another navigation program in wide use by cruisers. Many use pirated versions even if they own legitimate licenses, as the licensing mechanism is complicated and prone to failure, and who wants their nav‑program to suddenly fail just when you need it. MaxSea versions 10 and 11 had no AIS alarms to warn you of approaching vessels, and higher versions can't read CM93 charts, severely limiting the program's usefulness. Presumably this is because too many people already have the CM93 chart database and I&M would like to sell their own electronic charts. I&Ms new charts are certainly very nice, but they're also hideously expensive. Their pricing scheme is OK for those who only stay in 1 area, but it's very expensive for us world cruisers who keep needing access to new areas as we cruise around the world. But now that OpenCPN reads and displays the CM93 charts (and does most everything else that we want a navigation program to do) we don't much care about MaxSea.

Equipment Pages:KAP Downloads | KAP Files | OpenCPN | Turnbuckles | LEDs | Anchors | Sail Drives | Epoxy Work | AIS | Solar Panels | Watermakers | 3G Modems

Cruising Info:Up | General Cruising Info | Pacific Ocean Cruising | Indian Ocean Cruising | Provisioning Food & Fuel | Cruising Recipes

Top Level:Home | Destinations | Cruising Info | Underwater | Boat Guests | Ocelot | Sue | Jon | Amanda | Chris | Site Map | Make a Comment

Copyright © 2000‑2020 Contact: Jon and Sue Hacking -- HackingFamily.com, svOcelot.com. All rights reserved.

A rainbow table is a precomputedtable for caching the output of cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering a key derivation function (or credit card numbers, etc.) up to a certain length consisting of a limited set of characters. It is a practical example of a space–time tradeoff, using less computer processing time and more storage than a brute-force attack which calculates a hash on every attempt, but more processing time and less storage than a simple key derivation function with one entry per hash. Use of a key derivation that employs a salt makes this attack infeasible.

Rainbow tables were invented by Philippe Oechslin^[1] as an application of an earlier, simpler algorithm by Martin Hellman.^[2]

Background[edit]

Any computer system that requires password authentication must contain a database of passwords, either in plaintext or hashed in some form; therefore various techniques of password storage exist. Because the tables are vulnerable to theft, storing the plaintext password is dangerous. Most databases, therefore, store a cryptographic hash of a user's password in the database. In such a system, no one – including the authentication system – can determine what a user's password is by merely looking at the value stored in the database. Instead, when a user enters a password for authentication, the system computes the hash value for the provided password, and that hash value is compared to the stored hash for that user. Authentication is successful if the two hashes match.After gathering a password hash, using the said hash as a password would fail since the authentication system would hash it a second time. To learn a user's password, a password that produces the same hashed value must be found, usually through a brute-force or dictionary attack.Rainbow tables are one type of tool that have been developed to derive a password by looking only at a hashed value.Rainbow tables are not always needed as there are more straightforward methods of plaintext recovery available. Brute-force attacks and dictionary attacks are the most straightforward methods available. However, these are not adequate for systems that use long passwords because of the difficulty of storing all the options available and searching through such an extensive database to perform a reverse lookup of a hash.To address this issue of scale, reverse lookup tables were generated that stored only a smaller selection of hashes that when reversed could make long chains of passwords. Although the reverse lookup of a hash in a chained table takes more computational time, the lookup table itself can be much smaller, so hashes of longer passwords can be stored. Rainbow tables are a refinement of this chaining technique and provide a solution to a problem called chain collisions.

Etymology[edit]

The term, 'Rainbow Tables,' was first used in Dr. Oechslin's initial paper. The term refers to the way different reduction functions are used to increase the success rate of the attack. The original method by Hellman uses many small tables with a different reduction function each. Rainbow tables are much bigger and use a different reduction function in each column. When colors are used to represent the reduction functions, a rainbow appears in the rainbow table. Figure 2 of Dr. Oechslin's paper contains a black-and-white graphic that illustrates how these sections are related. For his presentation at the Crypto 2003 conference, Dr. Oechslin added color to the graphic in order to make the rainbow association more clear. The enhanced graphic that was presented at the conference is shown to the right.

Precomputed hash chains[edit]

Suppose we have a password hash function H and a finite set of passwords P. The goal is to precompute a data structure that, given any output h of the hash function, can either locate an element p in P such that H(p) = h, or determine that there is no such p in P. The simplest way to do this is compute H(p) for all p in P, but then storing the table requires Θ(|P|n) bits of space, where |P| is the size of the set P and n is the size of an output of H, which is prohibitive for large |P|.Hash chains are a technique for decreasing this space requirement. The idea is to define a reduction function R that maps hash values back into values in P. Note, however, that the reduction function is not actually an inverse of the hash function, but rather a different function with a swapped domain and codomain of the hash function. By alternating the hash function with the reduction function, chains of alternating passwords and hash values are formed. For example, if P were the set of lowercase alphabetic 6-character passwords, and hash values were 32 bits long, a chain might look like this:

${\displaystyle \mathtt{a}\mathtt{a}\mathtt{a}\mathtt{a}\mathtt{a}\mathtt{a}\underset{H}{\overset{}{\to }}\mathtt{281}\mathtt{D}\mathtt{A}\mathtt{F}\mathtt{40}\underset{R}{\overset{}{\to }}\mathtt{s}\mathtt{g}\mathtt{f}\mathtt{n}\mathtt{y}\mathtt{d}\underset{H}{\overset{}{\to }}\mathtt{920}\mathtt{E}\mathtt{C}\mathtt{F}\mathtt{10}\underset{R}{\overset{}{\to }}\mathtt{k}\mathtt{i}\mathtt{e}\mathtt{b}\mathtt{g}\mathtt{t}}$

The only requirement for the reduction function is to be able to return a 'plain text' value in a specific size.

To generate the table, we choose a random set of initial passwords from P, compute chains of some fixed length k for each one, and store only the first and last password in each chain. The first password is called the starting point and the last one is called the endpoint. In the example chain above, 'aaaaaa' would be the starting point and 'kiebgt' would be the endpoint, and none of the other passwords (or the hash values) would be stored.

Now, given a hash value h that we want to invert (find the corresponding password for), compute a chain starting with h by applying R, then H, then R, and so on. If at any point we observe a value matching one of the endpoints in the table, we get the corresponding starting point and use it to recreate the chain. There's a good chance that this chain will contain the value h, and if so, the immediately preceding value in the chain is the password p that we seek.

For example, if we're given the hash 920ECF10, we would compute its chain by first applying R:

${\displaystyle \mathtt{920}\mathtt{E}\mathtt{C}\mathtt{F}\mathtt{10}\underset{R}{\overset{}{\to }}\mathtt{k}\mathtt{i}\mathtt{e}\mathtt{b}\mathtt{g}\mathtt{t}}$

Since 'kiebgt' is one of the endpoints in our table, we then take the corresponding starting password 'aaaaaa' and follow its chain until 920ECF10 is reached:

${\displaystyle \mathtt{a}\mathtt{a}\mathtt{a}\mathtt{a}\mathtt{a}\mathtt{a}\underset{H}{\overset{}{\to }}\mathtt{281}\mathtt{D}\mathtt{A}\mathtt{F}\mathtt{40}\underset{R}{\overset{}{\to }}\mathtt{s}\mathtt{g}\mathtt{f}\mathtt{n}\mathtt{y}\mathtt{d}\underset{H}{\overset{}{\to }}\mathtt{920}\mathtt{E}\mathtt{C}\mathtt{F}\mathtt{10}}$

Thus, the password is 'sgfnyd' (or a different password that has the same hash value).

Note however that this chain does not always contain the hash value h; it may so happen that the chain starting at h merges with a chain having a different starting point. For example, we may be given a hash value FB107E70, and when we follow its chain, we get kiebgt:

${\displaystyle \mathtt{F}\mathtt{B}\mathtt{107}\mathtt{E}\mathtt{70}\underset{R}{\overset{}{\to }}\mathtt{b}\mathtt{v}\mathtt{t}\mathtt{d}\mathtt{l}\mathtt{l}\underset{H}{\overset{}{\to }}\mathtt{0}\mathtt{E}\mathtt{E}\mathtt{80890}\underset{R}{\overset{}{\to }}\mathtt{k}\mathtt{i}\mathtt{e}\mathtt{b}\mathtt{g}\mathtt{t}}$

But FB107E70 is not in the chain starting at 'aaaaaa'. This is called a false alarm. In this case, we ignore the match and continue to extend the chain of h looking for another match. If the chain of h gets extended to length k with no good matches, then the password was never produced in any of the chains.

The table content does not depend on the hash value to be inverted. It is created once and then repeatedly used for the lookups unmodified. Increasing the length of the chain decreases the size of the table. It also increases the time required to perform lookups, and this is the time-memory trade-off of the rainbow table. In a simple case of one-item chains, the lookup is very fast, but the table is very big. Once chains get longer, the lookup slows, but the table size goes down.

Simple hash chains have several flaws. Most serious if at any point two chains collide (produce the same value), they will merge and consequently the table will not cover as many passwords despite having paid the same computational cost to generate. Because previous chains are not stored in their entirety, this is impossible to detect efficiently. For example, if the third value in chain 3 matches the second value in chain 7, the two chains will cover almost the same sequence of values, but their final values will not be the same. The hash function H is unlikely to produce collisions as it is usually considered an important security feature not to do so, but the reduction function R, because of its need to correctly cover the likely plaintexts, can not be collision resistant.

Other difficulties result from the importance of choosing the correct function for R. Picking R to be the identity is little better than a brute force approach. Only when the attacker has a good idea of what the likely plaintexts will be they can choose a function R that makes sure time and space are only used for likely plaintexts, not the entire space of possible passwords. In effect R shepherds the results of prior hash calculations back to likely plaintexts but this benefit comes with the drawback that R likely won't produce every possible plaintext in the class the attacker wishes to check denying certainty to the attacker that no passwords came from their chosen class. Also it can be difficult to design the function R to match the expected distribution of plaintexts.^[2]

Rainbow tables[edit]

Rainbow tables effectively solve the problem of collisions with ordinary hash chains by replacing the single reduction function R with a sequence of related reduction functions R₁ through R_k. In this way, for two chains to collide and merge they must hit the same value on the same iteration: consequently, the final values in these chain will be identical. A final postprocessing pass can sort the chains in the table and remove any 'duplicate' chains that have the same final values as other chains. New chains are then generated to fill out the table. These chains are not collision-free (they may overlap briefly) but they will not merge, drastically reducing the overall number of collisions.^{[citation needed]}

Using sequences of reduction functions changes how lookup is done: because the hash value of interest may be found at any location in the chain, it's necessary to generate k different chains. The first chain assumes the hash value is in the last hash position and just applies R_k; the next chain assumes the hash value is in the second-to-last hash position and applies R_k−1, then H, then R_k; and so on until the last chain, which applies all the reduction functions, alternating with H. This creates a new way of producing a false alarm: if we 'guess' the position of the hash value wrong, we may needlessly evaluate a chain.

Although rainbow tables have to follow more chains, they make up for this by having fewer tables: simple hash chain tables cannot grow beyond a certain size without rapidly becoming inefficient due to merging chains; to deal with this, they maintain multiple tables, and each lookup must search through each table. Rainbow tables can achieve similar performance with tables that are k times larger, allowing them to perform a factor of k fewer lookups.

Example[edit]

1. Starting from the hash ('re3xes') in the image below, one computes the last reduction used in the table and checks whether the password appears in the last column of the table (step 1).
2. If the test fails (rambo doesn't appear in the table), one computes a chain with the two last reductions (these two reductions are represented at step 2)

   Note: If this new test fails again, one continues with 3 reductions, 4 reductions, etc. until the password is found. If no chain contains the password, then the attack has failed.

3. If this test is positive (step 3, linux23 appears at the end of the chain and in the table), the password is retrieved at the beginning of the chain that produces linux23. Here we find passwd at the beginning of the corresponding chain stored in the table.
4. At this point (step 4), one generates a chain and compares at each iteration the hash with the target hash. The test is valid and we find the hash re3xes in the chain. The current password (culture) is the one that produced the whole chain: the attack is successful.

C-map Charts For Sale

Rainbow tables use a refined algorithm with a different reduction function for each 'link' in a chain, so that when there is a hash collision in two or more chains, the chains will not merge as long as the collision doesn't occur at the same position in each chain. This increases the probability of a correct crack for a given table size, at the cost of squaring the number of steps required per lookup, as the lookup routine now also needs to iterate through the index of the first reduction function used in the chain.^[1]

Rainbow tables are specific to the hash function they were created for e.g., MD5 tables can crack only MD5 hashes. The theory of this technique was invented by Philippe Oechslin^[3] as a fast form of time/memory tradeoff,^[1] which he implemented in the Windowspassword crackerOphcrack. The more powerful RainbowCrack program was later developed that can generate and use rainbow tables for a variety of character sets and hashing algorithms, including LM hash, MD5, and SHA-1.

In the simple case where the reduction function and the hash function have no collision, given a complete rainbow table (one that makes you sure to find the corresponding password given any hash) the size of the password set |P|, the time T that had been needed to compute the table, the length of the table L and the average time t needed to find a password matching a given hash are directly related:^{[citation needed]}

${\displaystyle T=|P|}$

${\displaystyle t=\frac{|P|}{2L}}$

Thus the 8-character lowercase alphanumeric passwords case (|P| ≃ 3×10¹²) would be easily tractable with a personal computer while the 16-character lowercase alphanumeric passwords case (|P| ≃ 10²⁵) would be completely intractable.

Defense against rainbow tables[edit]

A rainbow table is ineffective against one-way hashes that include large salts. For example, consider a password hash that is generated using the following function (where '+' is the concatenation operator):

saltedhash(password) = hash(password + salt)

Or

C Map Charts Crack

saltedhash(password) = hash(hash(password) + salt)

The salt value is not secret and may be generated at random and stored with the password hash. A large salt value prevents precomputation attacks, including rainbow tables, by ensuring that each user's password is hashed uniquely. This means that two users with the same password will have different password hashes (assuming different salts are used). In order to succeed, an attacker needs to precompute tables for each possible salt value. The salt must be large enough, otherwise an attacker can make a table for each salt value. For older Unix passwords which used a 12-bit salt this would require 4096 tables, a significant increase in cost for the attacker, but not impractical with terabyte hard drives. The SHA2-crypt and bcrypt methods—used in Linux, BSD Unixes, and Solaris—have salts of 128 bits.^[4] These larger salt values make precomputation attacks against these systems infeasible for almost any length of a password. Even if the attacker could generate a million tables per second, they would still need billions of years to generate tables for all possible salts.

Another technique that helps prevent precomputation attacks is key stretching. When stretching is used, the salt, password, and some intermediate hash values are run through the underlying hash function multiple times to increase the computation time required to hash each password.^[5] For instance, MD5-Crypt uses a 1000 iteration loop that repeatedly feeds the salt, password, and current intermediate hash value back into the underlying MD5 hash function.^[4] The user's password hash is the concatenation of the salt value (which is not secret) and the final hash. The extra time is not noticeable to users because they have to wait only a fraction of a second each time they log in. On the other hand, stretching reduces the effectiveness of brute-force attacks in proportion to the number of iterations because it reduces the number of attempts an attacker can perform in a given time frame. This principle is applied in MD5-Crypt and in bcrypt.^[6] It also greatly increases the time needed to build a precomputed table, but in the absence of salt, this needs only be done once.

An alternative approach, called key strengthening, extends the key with a random salt, but then (unlike in key stretching) securely deletes the salt. This forces both the attacker and legitimate users to perform a brute-force search for the salt value.^[7] Although the paper that introduced key stretching^[8] referred to this earlier technique and intentionally chose a different name, the term 'key strengthening' is now often (arguably incorrectly) used to refer to key stretching.

Rainbow tables and other precomputation attacks do not work against passwords that contain symbols outside the range presupposed, or that are longer than those precomputed by the attacker. However, tables can be generated that take into account common ways in which users attempt to choose more secure passwords, such as adding a number or special character. Because of the sizable investment in computing processing, rainbow tables beyond fourteen places in length are not yet common. So, choosing a password that is longer than fourteen characters may force an attacker to resort to brute-force methods.^{[citation needed]}

Specific intensive efforts focused on LM hash, an older hash algorithm used by Microsoft, are publicly available. LM hash is particularly vulnerable because passwords longer than 7 characters are broken into two sections, each of which is hashed separately. Choosing a password that is fifteen characters or longer guarantees that an LM hash will not be generated.^[9]

Common uses[edit]

Nearly all distributions and variations of Unix, Linux, and BSD use hashes with salts, though many applications use just a hash (typically MD5) with no salt. The Microsoft Windows NT/2000 family uses the LAN Manager and NT LAN Manager hashing method (based on MD4) and is also unsalted, which makes it one of the most popularly generated tables.

See also[edit]

Notes[edit]

1. ^ ^abcOechslin, P. (2003). 'Making a Faster Cryptanalytic Time-Memory Trade-Off'(PDF). Advances in Cryptology - CRYPTO 2003. LNCS. 2729. pp. 617–630. doi:10.1007/978-3-540-45146-4_36. ISBN978-3-540-40674-7.
2. ^ ^abHellman, M. E. (1980). 'A cryptanalytic time-memory trade-off'(PDF). IEEE Transactions on Information Theory. 26 (4): 401–406. CiteSeerX10.1.1.120.2463. doi:10.1109/TIT.1980.1056220.
3. ^Lasecwww.epfl.ch
4. ^ ^abAlexander, Steven (June 2004). 'Password Protection for Modern Operating Systems'(PDF). Login. USENIX Association. 29 (3).
5. ^Ferguson, Neils; Bruce Schneier (2003). Practical Cryptography. Indianapolis: John Wiley & Sons. ISBN978-0-471-22357-3.
6. ^Provos, Niels; Mazières, David (June 6, 1999). 'A Future-Adaptable Password Scheme'(PDF). Proceedings of the FREENIX Track: 1999 USENIX Annual Technical Conference. Monterey, CA, USA: USENIX Association.
7. ^Manber, U. (1996). 'A simple scheme to make passwords based on one-way functions much harder to crack'(PDF). Computers & Security. 15 (2): 171–176. CiteSeerX10.1.1.102.2597. doi:10.1016/0167-4048(96)00003-X.
8. ^Kelsey, J.; Schneier, B.; Hall, C.; Wagner, D. (1998). 'Secure applications of low-entropy keys'(PDF). Information Security. LNCS. 1396. p. 121. doi:10.1007/BFb0030415. ISBN978-3-540-64382-1.
9. ^How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases, Microsoft

References[edit]

• Oechslin, Philippe (2003-08-17). 'Making a Faster Cryptanalytic Time-Memory Trade-Off'. Making a Faster Cryptanalytical Time-Memory Trade-Off(PDF). Advances in Cryptology: Proceedings of CRYPTO 2003, 23rd Annual International Cryptology Conference. Lecture Notes in Computer Science. 2729. Santa Barbara, California, USA: Springer. pp. 617–630. doi:10.1007/978-3-540-45146-4_36. ISBN978-3-540-40674-7.

External links[edit]