[OT] Secure storage

[Rhino]

I'm wondering if anyone here can recommend a secure way to store a list of
user names and passwords on a Windows XP computer?

I'm looking for an application that will store the data in a way that isn't
readily decipherable by a hacker who gets on to the system or even a snoopy
visitor to my house who happens to use the computer.

I'm just trying to find a good way to store my various usernames and
passwords for the gazillions of accounts that I have in one place or
another....

I used to have a nifty little app on my PDA called Memorizer (?) which used
a non-conventional access method - you had to click on the correct surfaces
in a complex shape to get in; once you were in, you simply have a nice text
file that lets you write whatever you want, including usernames and
passwords. That was handy because if I ever lost my PDA, I knew that no one
would be able to look at my secret stuff. I'm looking for something similar
on the PC.

Any ideas?

 

[markspace]

I'm wondering if anyone here can recommend a secure way to store a list of
user names and passwords on a Windows XP computer?

The first thing I'd look into is creating a separate account for the
password list or database, and then be sure that account is adequately
password protected and secure. I don't know details about Windows, I'm
more familiar with the in-and-outs of *nix. I'd get a good reference on
Windows security and bone up if I had to do this, not trust random
Usenet opinions.

I'm looking for an application that will store the data in a way that isn't
readily decipherable by a hacker who gets on to the system or even a snoopy
visitor to my house who happens to use the computer.

Physical security is the first step. However, if this is just casual
snooping then the seperate account mentioned above with a separate,
secure password will keep out most folks.

I'm just trying to find a good way to store my various usernames and
passwords for the gazillions of accounts that I have in one place or
another....

All that said, the usual method is to store the MD5 sum or some other
hash, not the password itself. Then even if a hacker gets your password
file it's of limited value.

Design the app so that password is sent over a secure, private transport
like SSL. When your app gets the password, take the MD5 sum and check
it against the database. Do not transmit the MD5 sum to the app and
then just check it, you won't be sure that way. A hacker could just
intercept the MD5 sum and then use that himself, it's as good as having
the password itself at that point.

I used to have a nifty little app on my PDA called Memorizer (?) which used
a non-conventional access method - you had to click on the correct surfaces
in a complex shape to get in; once you were in, you simply have a nice text
file that lets you write whatever you want, including usernames and
passwords. That was handy because if I ever lost my PDA, I knew that no one
would be able to look at my secret stuff. I'm looking for something similar
on the PC.

No ideas on an app that'll do this, but there are plenty of encryption
methods that are available. Even Zip with a password would keep out
most folks. I'll leave the gesture system up to you.

 

[Arne Vajhøj]

I'm wondering if anyone here can recommend a secure way to store a list of
user names and passwords on a Windows XP computer?

I'm looking for an application that will store the data in a way that isn't
readily decipherable by a hacker who gets on to the system or even a snoopy
visitor to my house who happens to use the computer.

I'm just trying to find a good way to store my various usernames and
passwords for the gazillions of accounts that I have in one place or
another....

I used to have a nifty little app on my PDA called Memorizer (?) which used
a non-conventional access method - you had to click on the correct surfaces
in a complex shape to get in; once you were in, you simply have a nice text
file that lets you write whatever you want, including usernames and
passwords. That was handy because if I ever lost my PDA, I knew that no one
would be able to look at my secret stuff. I'm looking for something similar
on the PC.

It should be relative trivial to write a little Swing app
that stores the passwords in a file using 256 bit AES and
can display the passwords when a passphrase is entered.

Arne

 

[Nigel Wade]

I'm wondering if anyone here can recommend a secure way to store a list
of user names and passwords on a Windows XP computer?

I'm looking for an application that will store the data in a way that
isn't readily decipherable by a hacker who gets on to the system or even
a snoopy visitor to my house who happens to use the computer.

I'm just trying to find a good way to store my various usernames and
passwords for the gazillions of accounts that I have in one place or
another....

I used to have a nifty little app on my PDA called Memorizer (?) which
used a non-conventional access method - you had to click on the correct
surfaces in a complex shape to get in; once you were in, you simply have
a nice text file that lets you write whatever you want, including
usernames and passwords. That was handy because if I ever lost my PDA, I
knew that no one would be able to look at my secret stuff. I'm looking
for something similar on the PC.

Any ideas?

I use eWallet for logon details, and other personal info.

It's built on 256bit AES encryption. Not the most secure, but secure
enough to defeat most attacks. It has the advantage that it comes in both
desktop and mobile varieties, so you can sync between your desktop and
PDA/phone (although the iPhone sync is severely nobbled by stupid Apple
restrictions).

 

[RedGrittyBrick]

I'm wondering if anyone here can recommend a secure way to store a list of
user names and passwords on a Windows XP computer?

I'm looking for an application that will store the data in a way that isn't
readily decipherable by a hacker who gets on to the system or even a snoopy
visitor to my house who happens to use the computer.

I'm just trying to find a good way to store my various usernames and
passwords for the gazillions of accounts that I have in one place or
another....

I used to have a nifty little app on my PDA called Memorizer (?) which used
a non-conventional access method - you had to click on the correct surfaces
in a complex shape to get in; once you were in, you simply have a nice text
file that lets you write whatever you want, including usernames and
passwords. That was handy because if I ever lost my PDA, I knew that no one
would be able to look at my secret stuff. I'm looking for something similar
on the PC.

Any ideas?

http://passwordsafe.sourceforge.net/

 

[Jean-Baptiste Nizet]

Rhino a écrit :

I'm wondering if anyone here can recommend a secure way to store a list of
user names and passwords on a Windows XP computer?

I'm looking for an application that will store the data in a way that isn't
readily decipherable by a hacker who gets on to the system or even a snoopy
visitor to my house who happens to use the computer.

I'm just trying to find a good way to store my various usernames and
passwords for the gazillions of accounts that I have in one place or
another....

This might look like an ad, but I have just developed an online web app
these last weeks to store accounts/passwords securely. It's free, as in
beer and as in speech, and it won't annoy you with any ad. I developed
it as a hobby, to discover some technologies and frameworks I didn't
know yet.
Try it at https://memwords.appspot.com/Index.action if you like. Note
that, since it's deployed on Google App Engine and I am the only user of
the app at this time, it's a little slow to start.
The explanations about the way information is secured is available at
http://code.google.com/p/memwords/wiki/Security

Hope it helps.

JB.

 

[Arne Vajhøj]

I use eWallet for logon details, and other personal info.

It's built on 256bit AES encryption. Not the most secure, but secure
enough to defeat most attacks.

AES 256 bit is supposed to defeat any attacks.

Do you know about a vulnerability?

Arne

 

[Tom Anderson]

http://passwordsafe.sourceforge.net/

Is the right answer.

tom

 

[Lew]

The assumption is that this is "ultimately optimistic". There may well be
much more efficient mechanisms and/or algorithms that either don't need to
test all keys, or somehow test multiple keys simultaneously with less energy
than required to "bump a single electron".

scenario of being able to test a key with as little energy as needed
to bump a single electron between two successive energy levels, and
assuming that you are able to channel the whole energy produced by
the Sun for the rest of its life (that's about 5 billion years), then
exploring a 256-bit key space will still require a few billion stars
-- i.e. an entire galaxy. Seems expensive.

This basically shows that the current rate of computer advancement
cannot plausibly be maintained for the next two hundred years. [...]

I admit to not being fully versed in the theory involved. But the
Wikipedia article points out that the analysis to which you refer makes
an assumption about the computations that turns out to not be true.
Specifically, there are more efficient ways to do the computation,
obviating the theoretical energy requirements according to analysis
you're talking about.

Lasers passed through holograms are able to elicit correlations in a massively
parallel fashion. I'm sure they currently use far more energy than Thomas's
"ultimately optimistic" projection, but one can imagine ways in which the
massively parallel action surpasses the ratio of one key per electron "bump".
One can also envision the use of currently impractical physics, such as
string theory or tachyon transitions, to augment quantum effects in such a way
as to exceed Thomas's "optimism".

History shows us that it's dangerous to predict the impossibility of future
advances. That by itself doesn't mean Thomas is wrong, only that it's
dangerous to predict ultimate impossibility.

 

[Tom Anderson]

The assumption is that this is "ultimately optimistic". There may well be
much more efficient mechanisms and/or algorithms that either don't need to
test all keys, or somehow test multiple keys simultaneously with less energy
than required to "bump a single electron".

scenario of being able to test a key with as little energy as needed
to bump a single electron between two successive energy levels, and
assuming that you are able to channel the whole energy produced by
the Sun for the rest of its life (that's about 5 billion years), then
exploring a 256-bit key space will still require a few billion stars
-- i.e. an entire galaxy. Seems expensive.

This basically shows that the current rate of computer advancement
cannot plausibly be maintained for the next two hundred years. [...]

I admit to not being fully versed in the theory involved. But the
Wikipedia article points out that the analysis to which you refer makes an
assumption about the computations that turns out to not be true.
Specifically, there are more efficient ways to do the computation,
obviating the theoretical energy requirements according to analysis you're
talking about.

Lasers passed through holograms are able to elicit correlations in a
massively parallel fashion. I'm sure they currently use far more energy than
Thomas's "ultimately optimistic" projection, but one can imagine ways in
which the massively parallel action surpasses the ratio of one key per
electron "bump". One can also envision the use of currently impractical
physics, such as string theory or tachyon transitions, to augment quantum
effects in such a way as to exceed Thomas's "optimism".

History shows us that it's dangerous to predict the impossibility of future
advances. That by itself doesn't mean Thomas is wrong, only that it's
dangerous to predict ultimate impossibility.

Clarke's first law:

When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong.

The correctness of Thomas's argument thus hinges on whether he is elderly .

tom

 

[Rhino]

Is the right answer.

Agreed. I downloaded and installed this, poked around with it a bit, and I'm
satisfied that this will meet my needs. Or at least my needs at home. I do
want to have a look at the web based solution that Jean-Baptiste Nizet
mention. I could see that being very handy when I travel and then need to
sign into one of my various infrequently used accounts....

 

[Rhino]

The assumption is that this is "ultimately optimistic". There may well be
much more efficient mechanisms and/or algorithms that either don't need to
test all keys, or somehow test multiple keys simultaneously with less
energy than required to "bump a single electron".

scenario of being able to test a key with as little energy as needed
to bump a single electron between two successive energy levels, and
assuming that you are able to channel the whole energy produced by
the Sun for the rest of its life (that's about 5 billion years), then
exploring a 256-bit key space will still require a few billion stars
-- i.e. an entire galaxy. Seems expensive.

This basically shows that the current rate of computer advancement
cannot plausibly be maintained for the next two hundred years. [...]

I admit to not being fully versed in the theory involved. But the
Wikipedia article points out that the analysis to which you refer makes
an assumption about the computations that turns out to not be true.
Specifically, there are more efficient ways to do the computation,
obviating the theoretical energy requirements according to analysis
you're talking about.

Lasers passed through holograms are able to elicit correlations in a
massively parallel fashion. I'm sure they currently use far more energy
than Thomas's "ultimately optimistic" projection, but one can imagine ways
in which the massively parallel action surpasses the ratio of one key per
electron "bump". One can also envision the use of currently impractical
physics, such as string theory or tachyon transitions, to augment quantum
effects in such a way as to exceed Thomas's "optimism".

History shows us that it's dangerous to predict the impossibility of
future advances. That by itself doesn't mean Thomas is wrong, only that
it's dangerous to predict ultimate impossibility.

One of the more interesting illustrations of Lew's point is Enigma, the
system used by German cryptographers during WW II. When Enigma was devised
in the late 1930s, Germany cryptographer's calculated that it was such a
difficult cypher that it would take 15,000 years to crack. They were
satisfied that this was an extremely secure cypher and had every confidence
that it would remain unbroken for a VERY long time. As it turned out, the
folks at Bletchley Park had at least partially cracked it - to the point
that they were able to read parts of the Enigma traffic - in just 9 MONTHS!
Of course, the Germans probably hadn't expected the first primitive
computers to come in handy for this problem.....

 

[Roedy Green]

user names and passwords on a Windows XP computer?

I'm looking for an application that will store the data in a way that isn't
readily decipherable by a hacker who gets on to the system or even a snoopy
visitor to my house who happens to use the computer.

See http://mindprod.com/jgloss/password.html

In the links section are links to several such products. I use a free
program called Software safe.
--
Roedy Green Canadian Mind Products
http://mindprod.com

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)

 

[Nigel Wade]

AES 256 bit is supposed to defeat any attacks.

Sorry, I did not intend to cause any confusion or concern. I am not an
expert on encryption, but I think there are more secure encryption
methods than 256bit AES. That's all I meant by "not the most secure". I
concede that that expression can also have other connotations - I did not
mean to imply that.

Do you know about a vulnerability?

No. But then again, that doesn't preclude there being one in this
product. It's quite surprising how many encryption algorithms, which in
theory are uncrackable, turn out to be severely compromised by their
practical implementation.

 

[Martin Gregorie]

Here's an article that suggests that, at the current rate of
computer power advancement, in a couple hundred years, someone will
be able to easily get through 256-bit AES

It can also easily be shown that even in the ultimately optimistic

The assumption is that this is "ultimately optimistic". There may well
be much more efficient mechanisms and/or algorithms that either don't
need to test all keys, or somehow test multiple keys simultaneously
with less energy than required to "bump a single electron".

scenario of being able to test a key with as little energy as needed
to bump a single electron between two successive energy levels, and
assuming that you are able to channel the whole energy produced by
the Sun for the rest of its life (that's about 5 billion years), then
exploring a 256-bit key space will still require a few billion stars
-- i.e. an entire galaxy. Seems expensive.

This basically shows that the current rate of computer advancement
cannot plausibly be maintained for the next two hundred years. [...]

I admit to not being fully versed in the theory involved. But the
Wikipedia article points out that the analysis to which you refer
makes an assumption about the computations that turns out to not be
true. Specifically, there are more efficient ways to do the
computation, obviating the theoretical energy requirements according
to analysis you're talking about.

Lasers passed through holograms are able to elicit correlations in a
massively parallel fashion. I'm sure they currently use far more
energy than Thomas's "ultimately optimistic" projection, but one can
imagine ways in which the massively parallel action surpasses the ratio
of one key per electron "bump". One can also envision the use of
currently impractical physics, such as string theory or tachyon
transitions, to augment quantum effects in such a way as to exceed
Thomas's "optimism".

History shows us that it's dangerous to predict the impossibility of
future advances. That by itself doesn't mean Thomas is wrong, only
that it's dangerous to predict ultimate impossibility.

One of the more interesting illustrations of Lew's point is Enigma, the
system used by German cryptographers during WW II. When Enigma was
devised in the late 1930s, Germany cryptographer's calculated that it
was such a difficult cypher that it would take 15,000 years to crack.
They were satisfied that this was an extremely secure cypher and had
every confidence that it would remain unbroken for a VERY long time. As
it turned out, the folks at Bletchley Park had at least partially
cracked it - to the point that they were able to read parts of the
Enigma traffic - in just 9 MONTHS! Of course, the Germans probably
hadn't expected the first primitive computers to come in handy for this
problem.....

Minor correction: Colossus, the first electronic computer (yes, it
preceded ENIAC), was used to crack Ultra, not the Enigma code.

Enigma was routinely broken by the Turing Bombe, an electromechanical
monster that was effectively 12 Enigma machines running in parallel plus
some clever wiring and relays that stopped it when a possible setting had
been found. However, Enigma was initially cracked by a small group of
Polish mathematicians around the outbreak of war. The Bombe came later
and turned the Enigma crack into a production line process.

 

[Arne Vajhøj]

Sorry, I did not intend to cause any confusion or concern. I am not an
expert on encryption, but I think there are more secure encryption
methods than 256bit AES. That's all I meant by "not the most secure". I
concede that that expression can also have other connotations - I did not
mean to imply that.

What encryption methods ?

AFAIK then AES is consider the most secure among the widely used
algorithms.

And it is approved by NSA for "top secret" data.

No. But then again, that doesn't preclude there being one in this
product. It's quite surprising how many encryption algorithms, which in
theory are uncrackable, turn out to be severely compromised by their
practical implementation.

With brute force impossible and no known mathematical attack angels,
then implementation disasters is what is left to hope for.

Arne

 

[Tom Anderson]

Peter Duniho wrote:
Here's an article that suggests that, at the current rate of
computer power advancement, in a couple hundred years, someone will
be able to easily get through 256-bit AES

Thomas Pornin wrote:
It can also easily be shown that even in the ultimately optimistic

The assumption is that this is "ultimately optimistic". There may well
be much more efficient mechanisms and/or algorithms that either don't
need to test all keys, or somehow test multiple keys simultaneously
with less energy than required to "bump a single electron".

scenario of being able to test a key with as little energy as needed
to bump a single electron between two successive energy levels, and
assuming that you are able to channel the whole energy produced by
the Sun for the rest of its life (that's about 5 billion years), then
exploring a 256-bit key space will still require a few billion stars
-- i.e. an entire galaxy. Seems expensive.

This basically shows that the current rate of computer advancement
cannot plausibly be maintained for the next two hundred years. [...]

Peter Duniho wrote:
I admit to not being fully versed in the theory involved. But the
Wikipedia article points out that the analysis to which you refer
makes an assumption about the computations that turns out to not be
true. Specifically, there are more efficient ways to do the
computation, obviating the theoretical energy requirements according
to analysis you're talking about.

Lasers passed through holograms are able to elicit correlations in a
massively parallel fashion. I'm sure they currently use far more
energy than Thomas's "ultimately optimistic" projection, but one can
imagine ways in which the massively parallel action surpasses the ratio
of one key per electron "bump". One can also envision the use of
currently impractical physics, such as string theory or tachyon
transitions, to augment quantum effects in such a way as to exceed
Thomas's "optimism".

History shows us that it's dangerous to predict the impossibility of
future advances. That by itself doesn't mean Thomas is wrong, only
that it's dangerous to predict ultimate impossibility.

One of the more interesting illustrations of Lew's point is Enigma, the
system used by German cryptographers during WW II. When Enigma was
devised in the late 1930s, Germany cryptographer's calculated that it
was such a difficult cypher that it would take 15,000 years to crack.
They were satisfied that this was an extremely secure cypher and had
every confidence that it would remain unbroken for a VERY long time. As
it turned out, the folks at Bletchley Park had at least partially
cracked it - to the point that they were able to read parts of the
Enigma traffic - in just 9 MONTHS! Of course, the Germans probably
hadn't expected the first primitive computers to come in handy for this
problem.....

Minor correction: Colossus, the first electronic computer

It wasn't a computer. No program.

(yes, it preceded ENIAC),

Which also wasn't a computer - no program, just configuration.

Well, at first. ENIAC became a real computer when they added that kludge
to use the function lookup table as a program store. But they only got
round to that after the Small-Scale Experimental Machine was running in
Manchester. That was a real computer.

was used to crack

The Lorenz cipher (aka Tunny). This was one of the sources of intelligence
stemming from decrypted German traffic, which were collectively known as

Ultra,

Which included that from the Enigma.

not the Enigma code.

Yes! The Enigma code!

Enigma was routinely broken by the Turing Bombe, an electromechanical
monster that was effectively 12 Enigma machines running in parallel plus
some clever wiring and relays that stopped it when a possible setting
had been found.

The clever wiring was some kind of reflecting setup that ran signals
through each Enigma module to encrypt them, then back out to decrypt them.
If the machine was on the right setting, the the output was the same as
the input. If it wasn't, it probably wasn't. Hence, all you had to do was
run through looking for settings like that, and you had candidates. At
least, that's what i remember from a talk on it. It was pretty cool stuff,
whatever it was.

However, Enigma was initially cracked by a small group of Polish
mathematicians around the outbreak of war. The Bombe came later and
turned the Enigma crack into a production line process.

ISTR that the Polish work wasn't a complete solution even in theory -
something like 80% of one. But still, not bad for a few dudes without the
support of one of the world's largest war machines behind them.

tom

 

[Martin Gregorie]

It wasn't a computer. No program.


Which also wasn't a computer - no program, just configuration.

That depends on whether you only call a stored program machine a
'computer'. In the terminology7 of the day they did, right up to the
Univac 1004. There were a lot of plug-board programmed machines in the
early days.

Well, at first. ENIAC became a real computer when they added that kludge
to use the function lookup table as a program store. But they only got
round to that after the Small-Scale Experimental Machine was running in
Manchester. That was a real computer.

AFAIK that never replaced all the plug boards.

A better argument is that both Colossus and ENIAC were built to perform
specified tasks and added a limited amount of programming flexibility via
plug boards and (for Colossus) program selection switches. Colossus was a
5-way parallel code breaking machine just as ENIAC was developed to
calculate artillery firing tables. Neither could have calculated a
payroll or (probably) handled each other's workload regardless of how
their programs were represented or loaded.

And, where does that leave the Zuse machines, which were programmable and
had a random access memory but were entirely electro-mechanical devices?

The Lorenz cipher (aka Tunny). This was one of the sources of
intelligence stemming from decrypted German traffic, which were
collectively known as


Which included that from the Enigma.

Not according to the story told at Bletchley. Colossus was optimised for
large amounts of 5-bit text sent in Baudot code, and basically didn't
work with samples of less that 5K characters while Enigma dealt with
short reports, usually sent in Morse and transcribed that were often
small, e.g a weather report.

ISTR that the Polish work wasn't a complete solution even in theory -
something like 80% of one. But still, not bad for a few dudes without
the support of one of the world's largest war machines behind them.

You may be right, though I thought the Poles could reliably break Enigma
with paper and pencil but it took a long time. IOW the code was
understood. Turing's contribution was to work out the Bombe's operating
principle and create the corresponding logical design once the Enigma
algorithm was understood. That wasn't small - I believe there were nearly
100 Bombes built, so the volume of code they broke each day was
impressive.

BTW, when I visited Bletchley, there was a mysterious device called a
'checker' that told them whether the Bombe had stopped on a false
positive or not. The guide knew what it did but nothing more about it. Do
you know anything about that device?

 

[Tom Anderson]

That depends on whether you only call a stored program machine a
'computer'. In the terminology7 of the day they did, right up to the
Univac 1004.

And before that, a computer was a lady with a slide-rule and a book of
squared paper who did sums. Neither of those machines are what we would
consider a computer today.

To clarify, i consider the essential feature of a computer to be that it
has a program, which is a body of instructions which control both
computations on data and the sequence of instructions executed, which is
stored in the same medium as the data. Something like that, anyway.

There were a lot of plug-board programmed machines in the early days.


AFAIK that never replaced all the plug boards.

A better argument is that both Colossus and ENIAC were built to perform
specified tasks and added a limited amount of programming flexibility
via plug boards and (for Colossus) program selection switches. Colossus
was a 5-way parallel code breaking machine just as ENIAC was developed
to calculate artillery firing tables. Neither could have calculated a
payroll or (probably) handled each other's workload regardless of how
their programs were represented or loaded.

That's a good way of looking at it.

And, where does that leave the Zuse machines, which were programmable
and had a random access memory but were entirely electro-mechanical
devices?

From what i understand, they were as computerlike as ENIAC, if not more
so. I don't think it matters a jot that they were electromechanical - if
the Analytical Engine had been built, that would have been a computer (i
think - but its brazenness would not have debarred it from that status).
Downstream of the instruction despatch mechanism, they were entirely
computerlike - a random-access store with a general set of operations,
controlled by an instruction code. But the instructions came from a fixed
loop, with very limited flow control, and no branches. That makes them
sequence-controlled calculators, not computers.

Not according to the story told at Bletchley. Colossus was optimised for
large amounts of 5-bit text sent in Baudot code, and basically didn't
work with samples of less that 5K characters while Enigma dealt with
short reports, usually sent in Morse and transcribed that were often
small, e.g a weather report.

Yes, sorry, i wasn't clear - Colossus and the Bombe cracked different
codes, but all the intelligence from decrypted traffic was called ULTRA. I
think. ICBW.

You may be right, though I thought the Poles could reliably break Enigma
with paper and pencil but it took a long time. IOW the code was
understood.

Okay, then perhaps i'm wrong. Then again, that may have been an earlier,
simpler version of the Enigma (fewer wheels, no steckerboard, etc), and
ISTR that the quantitative increases in the Enigma's complexity required
qualitative changes in methods to crack.

Turing's contribution was to work out the Bombe's operating principle
and create the corresponding logical design once the Enigma algorithm
was understood. That wasn't small - I believe there were nearly 100
Bombes built, so the volume of code they broke each day was impressive.

BTW, when I visited Bletchley, there was a mysterious device called a
'checker' that told them whether the Bombe had stopped on a false
positive or not. The guide knew what it did but nothing more about it.
Do you know anything about that device?

Yes, but if i told you, i'd have to kill you.

I assume it took the candidate position from the Bombe and put a larger
amount of ciphertext through it to see if it came out sensible. That's
purely a guess, though.

tom

 

[Martin Gregorie]

On Mon, 1 Mar 2010, Martin Gregorie wrote:

And before that, a computer was a lady with a slide-rule and a book of
squared paper who did sums. Neither of those machines are what we would
consider a computer today.

I think that job title lasted into the days on hand-wound and
electrically driven mechanical calculators - Monromatics (sp?), Fridens
and Facits. I remember using them for physical chemistry calculations.

To clarify, i consider the essential feature of a computer to be that it
has a program, which is a body of instructions which control both
computations on data and the sequence of instructions executed, which is
stored in the same medium as the data. Something like that, anyway.

That's certainly the current view, but as you said, it didn't happen
before Baby used a Williamson tube (modified CRT) to store program and
data.

However, there were a number of computers sold before that. I must admit,
though, that IBM spent a lot of time (and made a lot of money) selling
stored-program computers that emulated those early machines. Think of any
small business machine (S/34, S/36, S3) with its data files on cards and
running RPG. They were alive and well until well into the late 1970s.

From what i understand, they were as computerlike as ENIAC, if not more
so. I don't think it matters a jot that they were electromechanical

Agreed, though I can't remember whether they were programmed with a
plugboard or whether the program was one of those sliding plate memory
stacks.

the Analytical Engine had been built, that would have been a computer (i
think - but its brazenness would not have debarred it from that status).
Downstream of the instruction despatch mechanism, they were entirely
computerlike - a random-access store with a general set of operations,
controlled by an instruction code. But the instructions came from a
fixed loop, with very limited flow control, and no branches. That makes
them sequence-controlled calculators, not computers.

That seems correct from the limited amount I've seen about them. I've
seen a bit about the arithmetic unit and almost nothing about the
instruction set - only that the instruction feed used essentially the
same mechanism as a Jacquard Loom.

Okay, then perhaps i'm wrong. Then again, that may have been an earlier,
simpler version of the Enigma (fewer wheels, no steckerboard, etc), and
ISTR that the quantitative increases in the Enigma's complexity required
qualitative changes in methods to crack.

The steckerboard and reflector disk was there on all the Whermacht's 4
disk machines, but I thought the 5 disk version only appeared quite late
in the war.

If I understand the layout of the rebuilt Bombe, it has the possibility
of using 6 disks - at least it has six rows of 12 disks spindles on its
face. I don't remember hearing an explanation of how these mapped onto
the disks, reflector and steckerboard in an Enigma machine - just assumed
that each column represented an Enigma machine so it could run the
problem in 12-way parallel

Yes, but if i told you, i'd have to kill you.

were you ever at GCHQ? A friend who was used to say that a lot.

I assume it took the candidate position from the Bombe and put a larger
amount of ciphertext through it to see if it came out sensible. That's
purely a guess, though.

Using it was described as keying each letter of the alphabet in turn and
seeing if the same letter appeared on the output lamps. If that worked,
they put the settings into a British cypher machine that had been rewired
to emulate an Enigma machine and typed the first sentence or so of the
cyphertext into that. If good German came out, they passed the settings
and cyphertext on to the analysts and reset the Bombe for the next
problem.

Bletchley Park is well worth a visit. I had pretty high hopes of it, but
even so it was a lot more interesting than I expected, not least because
that have a good collection of working Enigma and Lorenz machines. I'd
hoped to see the Bombe running, but it wasn't run the day I was there,
however, Colossus was up and running.