Crack a Password, Save Norwegian History 589
Christian writes "With the death of the only person who knew the password to an archive held at a museum in Norway, suddenly the data became inaccessible. The result? A nationwide radio appeal asking for "hackers" to volunteer to help solve the problem! The
Norway Post has the story." I wonder if they looked under his keyboard yet..
Love all round... (Score:2, Funny)
Meseum: (in sync) Ahhh, he was a lovely fellow, never bothered a soul... wonderful guy... absolutely great...
Mesenger 2: He was the only one who knew the password to the history archive!
Mesuem: That F&%cker! How dare he die... mother f%#cking asshole!
Messenger 2: Hey... don't kill the messenger!
Slashdoted Text (Score:5, Informative)
Hackers respond to password challenge
Hackers have responded in large numbers to an appeal from the director of a culture center and literary museum on the west coast of Norway.
The password to one of their library archive systems is missing.
The museum built in honour of the famous Norwegian linguist Ivar Aasen received a gift of more than 1600 books and documents which had been catalogued and registered in a national data bank, which researchers and interested people may access.
Only trouble was that the expert who had helped the donor with the archiving work had died, and had failed to pass on the password.
In order to get access to the data base, Director Ottar Grepstad appealed on nationwide radio for help to solve the problem.
The response was above expectations, and the director is now busy chosing the expert most likely to solve the problem.
(NRK)
(this loaded very slow, but I got it.)
Re:Slashdoted Text (Score:5, Funny)
Heh. The director's got two Unix utilities in his name and he *still* can't hack the system.
I'm sure there's a joke in there somewhere.
Re:Slashdoted Text (Score:5, Funny)
If only his name was John Libcrypt...
I see 5: (Score:5, Interesting)
1) tar
2) ar
3) grep
4) ps
and not so common
5) rep (well its installed on my system, but I'd never heard of it, further investigation reveals it to be a standalone lisp interpretter from the librep package (see "info librep", I am indeed learning something new every day))
Re:Slashdoted Text (Score:2, Interesting)
However, 'Grepstad' is a surname derived from the name of a farm. 'stad' means place, so his last name would mean something like 'place of grep'. 'Grep' means several things in norwegian. I believe some farming implement goes by 'grep', but also it could mean to grasp (physically, mainly). Besides, those farm names stem from archaic norwegian, so 'grep' might have meant something else in the past.
And in other news.... (Score:4, Funny)
Re:Slashdoted Text (Score:3, Funny)
Sounds like a job for John Edward [scifi.com], master hacker!
Don't worry, I've already cracked it (Score:4, Funny)
In the year 1005, the 1337 v1k0rs raided the English coast for raping and pillaging...
Re:Don't worry, I've already cracked it (Score:2, Funny)
Username: navne
Password: passord
If I were to pass (Score:2, Insightful)
What's needed is a "dead man's 'bot" (Score:5, Interesting)
A simple program... something to send that important email, decrypt the data that you honestly don't have to safeguard anymore, etc. A program to take action when you haven't proven (password | biometric | whatever...) your continued existance on a pre-arranged schedule.
And wouldn't you know it, one exists!
I caught this discussion [infopop.net] at Ars Technica last month. It refers to a cool-sounding program called "Dead Man's Switch (DMS)", which caught the attention of the New York Times. [nytimes.com]
Just a few issues...
- Don't go on vacation for a longer period of time than you have the 'bot set for
- What happens when you actually do pass on to the great unknown, don't manage to pay your bills, and your (ISP | power company | shell host) kills your service?
- Or, more simply, what if your next of kin just tag the 'ol power switch?
Oh well... no person (or thing!) is perfect. Norway is keenly aware of this right now.(see either link, "If you're reading this, I'm dead!" type goofs have happened!)
Re:What's needed is a "dead man's 'bot" (Score:3, Interesting)
But for a fee it could be something more complicated.
Of course, keeping this site secure would be most interesting once people started using it for self protection blackmail "you'd better not kill me" purposes like what always happens in the movies.
Re:What's needed is a "dead man's 'bot" (Score:2)
Even then, a hosted service could use a war dialer to call up your contact numbers and verify your lack of contactability (hence possible demise) before undertaking the "in case of death" instructions.
These would mostly be notifications of the "we can't find X and our service is setup to notify people of X's possible demise... but we cannot confirm his demise, just his lack of contactability over (some period)." This is better than saying "If you read this, I am dead."
A managed service like this could be called something like the OmegaOption(c.2002 me) and be a service usable by individuals and corporations providing various service levels depending on how much you wanted to spend (from auto mail outs to more complex legal arrangements and multiple verification levels).
Damn! If only it were 2 years ago, this weak (but possibly maybe sometime valuable) business idea could have launched 100M in VC funding and a flurry of exciting reviews in trade periodicals!
Story of my life, good idea, wrong time...
Re:What's needed is a "dead man's 'bot" (Score:2)
Typhoon rips through cemetery; hundreds dead (Score:2, Informative)
As a Swede, all I can say is... (Score:5, Funny)
Re:As a Swede, all I can say is... (Score:5, Funny)
Re:As a Swede, all I can say is... (Score:5, Funny)
As a Dane, all I can say is... (Score:2)
Besides, I'm sure that the password is just a misspelt danish word. I mean, c'mon, if you can't pronounce danish properly, don't go and call it something else, like Swedish or Norwegian...
Re:As a Swede, all I can say is... (Score:5, Funny)
Re:As a Swede, all I can say is... (Score:3, Funny)
In Still Other News (Score:3, Funny)
Re:As a Swede, all I can say is... (Score:3, Funny)
Re:As a Swede, all I can say is... (Score:4, Funny)
Re:And sometimes... (Score:3, Funny)
No. To a European, "America" == North and South America, including Canada, Mexico, USA, Peru, French Guiana, etc.
I love it when a European tells me that an average American is so badly schooled that the average European better knows their American history. After asking them who Malcolm Little is, which they never know, and after patiently listening to how some hollywood movie has history all wrong (what a shocker, that), I usually give them an example of classy European geography like this, and send them on their way.
1) Who is Malcolm Little?
2) It's a matter of perspective, a European considers all of North and South America to be "America", Americans and Canadians consider the USA to be "America".
It's like in Canada, somebody from BC would tell you that the "west" is BC and Alberta, somebody from Alberta will tell you it's BC, Alberta, and maybe Saskatchewan. And somebody from SK will tell you that the "East" is Ontario and Quebec, where somebody from Ontario or Quebec will tell you that they're "Central" Canada, when technically they are not, the centre is in Manitoba.
so.. how are we supposed to store passwords? (Score:5, Interesting)
Re:so.. how are we supposed to store passwords? (Score:2, Interesting)
Re:so.. how are we supposed to store passwords? (Score:2)
> Oh, and in case a manger might need to get in you can number them 1 and 2.
Uhmmm yeah right... If you want that password to appear on a post-it note on a screen in the office, you should do that. And before y'all spout off that there are also competent managers out there: Most manglement type people I worked with are pointy-haired. Yes most. I''ve only known 2 managers in my carreer that were competent hackers (not crackers, mind you)
Escrowing your keys/passwords is a good idea, but please escrow your keys to people who you trust and from which you know that they are competent and can bear the responsibility of knowing that password/passphrase/whatever.
It's good that this is brought up. I need to escrow my keys to some people too before I kick the proverbial bucket. If I decide to leave life as it is and go for the after-life, my sucessor/replacement should be able to administer it.
Re:so.. how are we supposed to store passwords? (Score:2)
Damn preview button :P
s/administer it/administer my systems/
Re:so.. how are we supposed to store passwords? (Score:2)
The only other thing I can think of is to pick one other person whom you trust totally.
Re:so.. how are we supposed to store passwords? (Score:4, Insightful)
You do change them, right?
Or every time you get a password for a new service?
A better idea would be to keep the password to your private key in that bank safe, which decrypts your personal password file that you update regularly.
Re:so.. how are we supposed to store passwords? (Score:5, Interesting)
Hell no.
That is the single most hare-brained bit of common security "wisdom" in the world.
Years ago, I picked a password that's random as hell and was very difficult to remember. No password cracker-- dictionary *or* brute force-- has broken it yet. I use this password on about ten systems.
If I changed those passwords on a regular basis, I'd have to come up with something easier to remember to make up for the decreased learning time. That would likely make my password less secure.
I keep running into admins who-- by hook or by crook-- make their users change passwords periodically. The result? Passwords on Post-It notes; passwords that are the names of pets or wives or firstborn children; sets of passwords that are absurdly simple and that get cycled through.
If they had just let the users keep their original passwords and run a cracker against the shadow file to turn up the overly simple ones, their systems would be a lot more secure. But somebody told them changing passwords frequently was a good idea, and by god their users are going to change passwords frequently.
Re:so.. how are we supposed to store passwords? (Score:2)
At work we have to change one of our passwords every 6 months, and we can not re-use them. So I have had to come up with 9 passwords (oh, and they can only have 6-8 characters. Thanks for flexibility) that I can remember yet are fairly secure. I've been reduced to creating full numerics based on a stupid algorithm I made. Totally sucks.
Re:so.. how are we supposed to store passwords? (Score:3, Insightful)
It's very likely that if someone gained access to my strong password without my knowledge, they'll have access to the next one I choose as well. Weakening the passwords just helps them get that initial foothold.
Re:so.. how are we supposed to store passwords? (Score:5, Funny)
RMN
~~~
Re:so.. how are we supposed to store passwords? (Score:4, Funny)
Re:so.. how are we supposed to store passwords? (Score:2)
That's the accepted practice. If you're sensible you keep those bits of paper in a safe and keep an eye on who opens it.
Re:so.. how are we supposed to store passwords? (Score:2)
most 'minimally skilled IT operators' write passwords to important systems on bits of paper
Yes, I do that, too.
But I can see it now: the social engineering crackers show up to look for a word written down on a piece of paper - in an archive (aka library) with probably O(1e5) volumes!
If I wanted to hide a piece of paper, that's exactly where I'd hide it.
As a youngster, I once hid some paper money in an obscure text in the library and was able to retrieve it a month later.
Give them to the CEO, CTO, etc.... (Score:2)
Re:so.. how are we supposed to store passwords? (Score:3, Interesting)
Lawyers are bound to non-disclosure of an individual's last will and testament, if I am not mistaken. (until death, at which time it is revealed to those individuals referenced therein)
It seems, therefore, that the password (or some part of it at least) should be kept in the will, which should only be accessible once you die. Although this will rely on confidence in the lawyer you choose, their firm, etc.
But generally, seems like it should work.
If necessary, tell the other half to one or two other big-wigs, or stored in a safe. So both your death and the aforementioned access are necessary.
Re:so.. how are we supposed to store passwords? (Score:2)
Re:so.. how are we supposed to store passwords? (Score:5, Informative)
Google for "secret sharing" [google.com] and you'll find plenty of references. Essentially, the secret (i.e. the password) is converted into a value that intercepts an axis of a n-dimensional graph. m points in n-dimensional space are then generated such that they lie in a straight line on a single plane. You can then distribute the values of the m points safe in the knowledge that you need at least n of them in order to calculate the point of interception of the secret.
AFAIK, this is how things like launch codes for nukes are stored and distributed (to counter the twin threats of elimination of keyholders preventing nukes from being launched, and to prevent a single rogue keyholder launching without appropriate authorisation).
Apologies to the maths/crypto purists out there if my description is fuzzy, over-simplified, or plain wrong, but it's been a while... ;-)
Better explanations can be found on RSA's site [rsasecurity.com] and in Ross Anderson's book "Security Engineering" [google.com]
--
Re:so.. how are we supposed to store passwords? (Score:5, Insightful)
Simple, easy.
Re:so.. how are we supposed to store passwords? (Score:5, Informative)
Er, I'm not sure what you're getting at. For example, any set of points (in a space of more than two dimensions) that "lie in a straight line" are necessarily also in a plane and are in fact in infinitely many planes.
Shamir's secret sharing is easy to describe: Any polynomial of degree k-1 can be completely figured out from k points on it but not from k-1 points. So to share a secret among any number of people so that any k of them can figure out the secret and any k-1 of them cannot, you make up a polynomial whose value at x=0 is the secret and you tell each person the value of the polynomial at other points (at x=1, x=2,...).
For example, any 2 points define a line (a polynomial of degree 1). If you tell me where the line is at x=1 and x=2, I can figure out where the line is at x=0. But if you only tell me where the line is at x=1, I haven't got a clue where it is at x=0, because it could still be anywhere. If you gave a million people different values for x=1, x=2,... x=1000000, no one of them would know the value of the line at x=0, but any two of them could figure it out.
Re:so.. how are we supposed to store passwords? (Score:5, Interesting)
* Have a safe, where the president and at least one (but not too many) other executive has the combination for
* Keep a signed and sealed envelope in the safe containing critical system password(s)
* Make sure the executive(s) know that, in case of emergency, give the envelope to your successor
* When you change passwords, update the envelope
This way, while the executives have the ability to compromise the system, they can't do so without breaking the seal or losing the envelope, so you know it was someone with access to the safe.
But I guess there is people around protecting *really* important data, and they do not trust anyone...
In most companies, you *have* to trust the president (even if you really don't trust the president), since he has the authority to do pretty much whatever he wants, whether or not he knows how to.
In those cases where you don't do the above, doing something similar with a safety deposit box, an offsite account, or having a lawyer hold the envelope as if it were in escrow could also work.
If you want to be ultra-secure: two safety deposit boxes in two separate banks, one containing the encrypted password, the other containing the key to decrypt it. Keep the deposit box keys in a personal safe with the directions. Give nobody else the safe combination (if you die, they can pay a locksmith to break it). Ideally, find banks that will do a full audit trail on anyone (you included) accessing the box: have them log time and identification, photograph the person, and notify your office that the box was accessed.
To step up the security another notch or two: make sure the two banks above are at least an hour away from each other. Keep the two keys in a safety deposit box in a third bank (at least an hour from the other two). Have all three banks log the request for entry and immediately notify both your office and a pager you carry personally, and then require the person wait for 24 hours before they grant access, so you have three warnings and 48 hours lead time if someone is trying to gain entry via the stored secret.
The more security you have, the more annoying it is. You can go beyond the above, but if it's that secret it might be safest to have the secret die with you.
Dead Mans switch (Score:2, Interesting)
Re:so.. how are we supposed to store passwords? (Score:2)
Give the envelope to the boss, and or the financial controller, and ask that it be kept in the vault.
Keep up to date as needed for password changes.
For an individual, do the same, and leave it with your will in the save deposit box.
distributed key escrow (Score:2)
A variation is a voting system: Supply each party with enough numbers so that any P parties can combine some numbers to get the key. That helps if one of the parties has died or lost all its data.
Re:so.. how are we supposed to store passwords? (Score:2)
Passwords should always be remembered, and old passwords saved on paper (lock box or something) after they are decommissioned. But more than one person should always know vital info, to account for the "hit by bus" effect.
Re:so.. how are we supposed to store passwords? (Score:5, Insightful)
On the contrary, it's 100%. It's not a question of if, it's of when.
Re:so.. how are we supposed to store passwords? (Score:3, Funny)
So.. hah!
Re:so.. how are we supposed to store passwords? (Score:2)
From Norway? we know what the password is :) (Score:2)
damnitscolduphere
amnitsreallycolduphere
Re:From Norway? we know what the password is :) (Score:2, Informative)
Just my 2 cents and a herring.
Password Selection Rules (Score:3, Funny)
Query Google for "Password Selection Rules 88-570471" [google.de]
Re:Password Selection Rules (Score:5, Informative)
Anyhow, I haven't looked at this specific case, and so it has to come down to the password protection in the database used (DBase 4), which I am not familiar with.
Just a bit of background history: In Norway we have two written languages; nynorsk and bokmaal. The site that's lost their password, fronts the usage of nynorsk, which is a clear minority language. Most people in Norway speak dialects which mostly resembles the written nynorsk, although most write bokmaal.
The lost database contains "16 000 books in nynorsk", but some news sites seem to have gotten this number wrong (namely "1600", dagbladet.no).
To those asking for a translation, I can mention that they (aasentunet.no), have gotten about 20 e-mails and 5-6 phone calls, since it was mentioned on national radio. They've even been contacted by parapsychologists, who wants to crack the password using supernatural powers!
Re:Password Selection Rules (Score:2)
Problem solved? (Score:2, Informative)
Problem solved! (Score:2, Informative)
Re:Problem solved? (Score:5, Informative)
http://www.passwordbusters.com/profile_dbase.ht
dBase
Versions: All known
Recovery time: 1 day
Success Rate: 100%
Price: $29
What we need from you: Your dBase file sent via email.
What we will give you: Your dBase file's missing password.
Notes: dBase features a relatively insecure password protection algorithm.
How we recover the file: We find the password information within your file and compare known permanent data against encrypted data in the password to decrypt the text of the missing password.
web site of the museum (Score:5, Informative)
The latter has a few links to on-line news as well:
- NRK [www.nrk.no]
-
Dagbladet [dagbladet.no] (headline: "Alle vil hacke for Ivan Aasen"
:) -
TV2 [tv2.no]
-
digi.no [www.digi.no]
Unfortunately, that's all in Norsk. (Any volunteers for translating?)Translation of one article. Probably redundant. (Score:4, Informative)
-
bokmaal = the most popular form of written Norwegian. It has been severely corrupted by Danish.
- nynorsk = new Norwegian. A written language constructed by I. Aasen based on non-corrupted Norwegian dialects.
- Yes, I am bored, and that is the only reason I am translating this.
Bokmaal users want to find the password. Bokmaal users in line to help the New Norwegian.- The bokmaal users are standing in line to help the New Norwegian cultural centre break the codes for a database, and we are glad about all the good tips we have received. This says library leader Kirsti Langstøyl at the Ivar Aasen Centre in Sunnmøre in a comment to the case that the whole computing community in Norway has been engaged by the last few days.
Nine years ago, 11,000 books from a major book collection were registered in a DB program that now is outdated. The data are both compressed, encrypted and password-protected. He who did the work died before the collection and database arrived at the Ivar Aasen centre in Ørsta, and he left no information that may have helped solve the problem.
After "Her og nå" (Here and Now, radio show) in NRK P1 Friday, May 31st mentioned the case, the New Norwegian Cultural Centre has received more than 80 e-mails and phone calls from people and companies that want to help. Major web news pages and central web sites mention the case, and the jungle telegraph is sounding amongst cr-/hackers and security companies. Many would like to try the challenge for no fee, one person wanted NOK 890 per hour (about USD 110/h), and one wanted NOK 10,000 (USD 1,200), and claimed he would solve the case in a day or two. The offers came both from within Norway, and from abroad, and most of the offers come from bokmaal users, who would be happy to help/promote Ivar Aasen. Only an anonymous person with a forged email address hoped that the effort will fail, so that New Norwegian may lose ground.
-We have hired a computer consultant to go through all the offers, and siphon out those that look the most interesting. The chances are good for the case now being solve, says Kirsti Langstøyl.
Screw it, now my boredom suddenly seems all the much more fun. Til dere nordmenn der ute som synes oversettelsen er kjempeteit: Værsegod å oversette restenRe:Translation of one article. Probably redundant. (Score:2, Informative)
This is the translation of the article at: http://webon.prodat.no/wsp/aasentunet/webon.wsp?f
The first part (down to "Bakgrunn om Djupedal-samlinga") is translated above, this is the rest of it:
---
Background on the Djupedal-collection
Culturehistorian, linguist and Aasen-knower Reidar Djupedal's (1921-89) book-collection consisting of some 14 000 books (the numbers vary from 12 000 to 15 000 titles i the Ivar Aasen-museum's years report for the years 1993 to 1994) is a gift to the Ivar Aasen-museum. The collection consists of books, magazines and prints on several subjects, focusing on litterature and language sciences, in at least 15 different languages, mainly norwegian, danish, swedish, icelandic, faereyic and frisic.
The collection consists of some 14 000 titles. In the beginning of the 1990s a large portion of these were registrered in a database, probably by persons in the Djupedal-family. The database is made by using dBase IV. It should contain 11 000 records. This means that part of the collection (probably about 2000 titles in faereyic, icelandic og frisic) is not registered.
It is difficult to say anything about the quality of the database. The software is no longer for sale so it is not possible to open the database that way. We have 18 binders with hardcopy of all the records in the database. The hardcopy is not organized alphabeticly but by record number. Since the books are not marked wether they are registered or not it is impossible to have a system without actually handling the individual documents.
There is three floppy disks where the collection is registered. The 21st of december 2000 they were sent to BIBSYS in Trondheim, but they have given up . The IT-department of Volda university has tried to open the database. The format has so far given problems, for example because the files are password-encrypted.
---
Many times the english excuse. Translation difficult is.
- SOR -
In case someone's interested in helping out... (Score:5, Informative)
The username and password system is really used for encryption, not for preventing access. Remember: This database was made in the days where multiuser systems were unknown to most people.
Re:In case someone's interested in helping out... (Score:2, Interesting)
I believe there are serveral apps that do this.
Re:In case someone's interested in helping out... (Score:5, Funny)
More info (Score:5, Informative)
The database is from Dbase 4, I don't know how the security is on that format. It contains data about the norwegian linguist Ivar Aasen. For those interested in giving it a try, just search on norwegian pages to find the directors email address (name in another post). He's received quite a few emails already... (No, won't give the address here, pity the one who gets his email published on Slashdot).
Please excuse crappy english, save your grammatic flames.
Slashdotted, what did you expect... (Score:2, Insightful)
The site www.norwaypost.com is running Microsoft-IIS/4.0 on NT4/Windows 98.
Sad, isn't it?
Anyway, two ways to attack this problem: brute force it or be clever and see if this can be done by social engineering. If there are any people that know him well enough they might. Otoh, the way I choose passwords it might be tough even when people know me.
I remember this story about a similar incident a long while back. Somebody encrypted a file using a new algorithm and couldn't believe how fast that went. To verify the speed he then proceeded to encrypt the backup too and forgot _both_ passwords. This was a long time ago and to this day I don't believe it but the moral of the story is: keep an unecrypted version in an off-line, off-site backup medium in a vault for digital media in duplicate.
Sorry, can't help... (Score:5, Funny)
Actually, we need more challenges like this (Score:2)
Anyway, in this particular case, and 99% of others, the password is "IAmGod"
Re:Actually, we need more challenges like this (Score:2)
Ahem, I meant RC5-64 ofcourse. I quess I am stuck in a time continuum
A common problem (Score:2)
Twice in recent years I've had the unhappy task of attempting to recover password protected personal files created by friends who have died. In each case the files contained financial information that the next of kin needed.
While password security is undoubtedly a good thing, it goes a bit beyond its remit if it locks out the wrong people. In most jobs I've had it has been common practice to keep hardcopies of passwords in sealed and signed envelopes placed in safes. While this is probably overkill for home users it's worth considering doing something like this for your family or friends and letting them know about it. Especially if you're someone I know. I really, really don't want to have to go through this again.
Someone Should Be Sure To Remind Them... (Score:2)
Of course, I am sure those in charge would happily my exceptions to this rule when it suits them. Still, this could be a great opportunity to speak out against such legislature.
Irony of Ironies (Score:2, Interesting)
Public access? (Score:5, Funny)
They are lucky! (Score:2, Interesting)
Re:They are lucky! (Score:2)
Re:They are lucky! (Score:2)
Raises a serious point (Score:4, Insightful)
The ISP I once working for nearly went out of business several years back because the only tech with high level access was in a serious car accident and out of action for a month or so.
Its all very well not writing down passwords, and saying that nothing is going to happen to you, but in the real world, people get ill, run over, fall down etc. - In large companies its more then likely not a problem, but in a small company that has only one tech person doing everything, people need to make sure there is a plan of action for if that person becomes unreachable for any reason.
Heard in Court (Score:2)
Information on Aasen, the Aasen museum and nynorsk (Score:4, Informative)
The National Centre of the New Norwegian Language and Culture
The New Norwegian Language
Ivar Aasen
oh-oh (Score:2, Informative)
Good thing it wasn't the US.... (Score:2)
Of course, then the RIAA would sue them, just because they can.
Quick! (Score:2)
What's norwegian for "password"?
blahblah Lameness filter is itself lame... ironic...
How about the spaceballs approach (Score:2)
"That's the combination for my luggage!"
How to avoid the problem? (Score:2)
My first instinct is the really low-tech alternative: hire a lawyer to deal with your confidential information when you die. Just like any other "unsolved business" with your state, your passwords,etc. would be given to someone you deem capable of dealing with the issue...
But almost no one prepares for death that way either, so what are the technical alternatives?
- A cron job of sorts? Would depend on the server running indefinitely until some stipulated date when it would release the information... if it used some distributed system, it could avoid the vulnerabilities that come to mind at first sight. But a system that requires you to identify yourself and register would require almost as much preparation as the lawyer, and an anonymous system would be too open to abuse (heck, the first too).
- Some kind of "degrading cryptography"?
It may seem like defeating the purpose of cryptography in the first place, but assume that we don't want to keep the information secret forever, just for some years... not only do we not care if the information is revealed then, we DEMAND it is revealed at a particular point in time.
Is there some way to encrypt data such that it can demonstrably be decrypted only after X amount of time?
I imagine it would be extremely hard to figure out something like that, but maybe someone already has. I can only think of three approaches to not-depend on processor power, both perhaps impossible:
i) A method that collects information from some constant (data is reliable and at a constant rate) source of information (solar flares?) and needs to collect X amount of information before decrypting the key and revealing it.
The problem is that in order to ensure this information will make the decryption possible you have to be able to anticipate it. Then anyone can simulate the information at an accelerated pace and get to the key...
Maybe if we can use the key to select which information to process, and use a source of massive amounts of data, we can make unfeasible to accurately simulate all the data. But that would be trusting our current technical limitations to hold, wouldn't it? Unless we can prove simulating the source is an NP problem...
ii) Having a system that creates a unique algorithm for the key that needs to be run for X time in order to "degrade" to the key. The idea would be to escape the dependence on external information of the first problem. But even if it's possible, we would need to depend on an external source for a trusted "beacon" or "ticker" that tells how much time has passed.
iii) Perhaps the only sensible solution (and the last I thought of, obviously): Would it be useful to have digitally signed time measurement on the Internet? An atomic clock owned some trusted government or international entity that officially tells you "today is time X"?
You encrypt the key to be decrypted only when a message digitally signed by agency Y confirms a certain date has been reached. When agency Y makes the message "today is time X" public on the Internet, your boss gives that message to the system and the system pops out the password you need. "time X" and "agency Y" could (and would) be made public to all interested parties, but unless "agency Y" cheats, no one can do much about it.
This could also provide an automated means to publish confidential material whose confidentiality has an expiration date. Declassification would then not require too much work on the part of agencies that have no great interest in declassifying in the first place: once the time is reached, the keys are available and people can decrypt it.
Re:How to avoid the problem? (Score:2)
as the computational power doubles every 18 months, every 18 months teh price and effort required to break older cryptography halves.
tell me, would you trust enigma to safeguard your information ? or 48 bit cyphers ?
enigma was unbreakable by the technology existent (paper and pencil) when it was invented, but the british came with a primitive computer that done the job. 48 bit cyphers probably were incredibly safe 15/20 years ago, now any script kidie with a 1 GHz+ athlon can break it.
call this "cypher rotting" if you want.
Re:How to avoid the problem? (Score:2)
- You cannot predict "when" is your cryptography going to be broken, unless you make it breakable (for someone with enough horsepower) in the present.
Since your original purpose was to make it unbreakable in the present, you're not going to do that.
But if you make it strong enough to be confident it's presently secure, you lose the certainty it will be crackable in, say, 20 years or less. Sure, quantum computing may prove to be practical and available... or not. Maybe Moore's Law will allow traditional computing to break it... if the factor suddenly increases by 10.
Enigma was considered "improbable to be broken", not "unbreakable". The same can be said of 48-bit ciphers. We know better than that now.
We can have confidence, based on mathematical theorems, that a particular code cannot be broken unless we try all the alternatives... and that will be a fact until either the theorem is disproved, or something makes it incredibly cheap to compute the alternatives. By increasing the key's length, we can make the second factor irrelevant taking into account the Moore's Law (we're still vulnerable to breakthroughs like quantum computing, but they cannot be predicted... and yes, we can make algorithms hard to break for quantum computing). Then the system rests on the theorem's security, and mathematics is notoriously slow in developing revolutions.
So no, I'm afraid trusting the "no encryption is secure, someone will be able to break it in the future" doesn't work. It's as blind as the "no system is completely secure" and has the same problem: they only apply if the system/algorithm was designed or used under ignorant and unrealistic expectations of what "secure" is. Both are trivially true for most cases, but fail to understand the problem and are false for the important cases.
We would have more success trusting the bug rate than Moore's Law for this case. Most vulnerabilities in properply designed, analyzed and tested algorithms are in the implementation.
Maybe if we calculate some statistics on the bug rate of encryption software, we can predict that some vulnerability will probably be found in X program by Y time that will allow the recovery of the key, and trust the statistics.
The password is BOSCO (Score:2)
This is not troll, I am a human and make funny jokes, haha.
Hypocrisy (Score:2, Troll)
This sort of thing works both ways and the powers that be aren't going to learn that if you come to their rescue. They'll eventually figure out the password, but if you let them do it on their own, and you tell them why you aren't going to assist them then maybe, just maybe, they'll learn a lesson. Something about doing to others as you would have them do to you.
Info desired to crack the password... (Score:5, Interesting)
The following info would help:
Combine that with the dictionary, mix well, apply cracking script and, most likely, open sesame.
As Richard Feynman used to say about safes, 99.9% of what keeps people from getting in is the perception of security, not real security. This from a guy who used to sneak in & out of Los Alamos at will during the Manhattan project.
Should have had a risk management plan for this (Score:3, Insightful)
In reality, this situation is almost the same as if a fire had destroyed the building along with the data, or even as if the person responsible for the data intended for it to die with him. There is a chance, however large or small, that the data will be recovered, but from a business perspective, an appropriate response would be to consider it a loss, start collecting the data again, and learn from the experience. Retrieving the data from the encrypted file is an interesting exercise, but one with uncertain results. Push the file into an academic circle and hope for the best.
In this case, having the file is misleading a management decision, because it appears as if they still have the data. In reality, they do not, unless an unlikely contingency occurs where someone can retrieve it. Since nobody seems to be able to put a delivery date on that retrieval, or even state the degree of cetrainty with which it can be retrieved, the correct business decision would probably be to consider it lost.
I'm guessing it's a loss not covered by their insurance.
This is a harsh assessment of the situation, and I'm only making it because I'm not the one with the data that needs to be recovered
Another thing I notice is that the party responsible for the data seems interested in limiting the number of people who will get the opportunity to try to crack this, as opposed to just posting the thing to the world as a challenge, perhaps with a reward to the first person to break it. Remember the King Arthur legend -- Arthur wasn't authorized to try for Excalibur!
The details in the article are sketchy. The title of the Slashdot article seems to be pretty misleading. The file in question doesn't contin the historical documents themselves, but an index to them?
I'm sorry to hear that a researcher has died in Norway.
Re:I wonder.... (Score:2, Informative)
I wonder if they've tried that already...
History? You mean "last week"...? (Score:2)
RMN
~~~
Posting links (Score:2)
<A HREF="http://slashdot.org/">this is a link</A>
...becomes
this is a link [slashdot.org]
RMN
~~~
Re:this dosn't make sense. (Score:5, Funny)
Get a cable modem, go to jail. [slashdot.org].
What kind of crazy backwards world are we living in?
Ladies and Gentlemen of slashdot it does not make sense. If Chewbacca lives on Endor you must acquit.
Re:What I've been saying all along (Score:2)
Simple! (Score:2)
If dogs name does not work use "Override".
Re:It's probably just ... (Score:2)
lol. literally. caught me off guard. we used that for a domain admin pwd at a former employer during one rotation period.