Sending Encrypted Messages

OK, I’ve spent a while looking at things like PGP and GPG and how they integrate with various email programs (and how many integration problems folks have had with emailers and the encryption methods…)

I’m still looking for something reasonably usable that doesn’t require a whole lot of caveats and / or knowing things about the particular operating systems or releases of software used.  While the convenience of automated key rings and public key encryption are large (especially things like avoiding the need for a “code book”) the search so far has involved “trusting” a bit more than I like.

Since we know, for example, that various TLAs have requested large commercial software suppliers to “provide a back door” in their products, I’m a bit leery of trusting such software to be devoid of back doors.

Because of this, I lean toward software that has Source Code available and published.  Even if I have not done the verification personally (which would be ideal) the odds are high that someone else has done it.

In looking at the various options, it looks like encrypting the message prior to sending it has some merit.   First off, the encryption can be done on a system that is NOT the one used for the sending.   Any machine connected to the internet is subject to compromise and could have a key logger or similar snooping tool installed that could read the password / passphrase as it is typed.  By doing the encryption on one machine that is isolated, then passing the file in “write once” media to the sending machine, there is much more protection against those kinds of machine compromise attacks.  

The media could be a CD that is then archived or destroyed, or it could be an SD card that would be formatted after the send – and even formatted again in some other device before being reused on the encrypting machine.   Paranoid?  Well, yes, security is like that…   So personally I would put the SD card in an old camera and tell it to FORMAT.  Any malware trying to crawl up stream ought not to survive something as stupid as a camera doing a format.  ;-)

There were “Active Picture Frames” from China where you plug them into the USB slot and just download a picture jpg into them; that were found to come from the factory with malware pre-installed that would compromise the target and provide access to Chinese hackers. ANY device that is a data store could be so compromised. I always format USB storage chips in a camera first if at all possible. (I like to use SD cards in a USB adapter rather than a “stick” for just that reason.)

So I went looking for a file encryptor. There are a lot of them, but I kind of like AES. It has source code available, works on all of Linux, Mac and Windows including several versions. Free download too.

I’ve given it a bit of a trial run and it worked very easily. The encryptor ends up as an option on a Right-Click of any file.


I have not vetted that site as being secure and valid. It looks like it is, but until vetted: that is just a bit of hope. So before using this for anything that matters, it would be good to “snoop around” and look for validation for the site. (It would be ideal to just download the source code and do a ‘from scratch’ build, then compare the binaries for “oddities” such as significant size difference or highly variable byte patterns. )

With that said, the software was easy to use and did what it claimed to do, near as I could tell from a casual look at the files produced. A brief wandering around the site looked “pretty good” too.

They also have a pretty good description of passwords and how to make a secure one. Oddly, they use as a ‘crackable’ example a method that was common practice about 20 years ago to make a ‘strong enough’ one. A rather dramatic example of how far software and hardware advances in password cracking have gone.

The example used is a combination of a word or two with a number digit. So for example “Give2Me” or “Shoot4Moon”.

Assume also that the number of digits might be 1 or 2. To attack the first form (word + digits + word), the attacker would try (100,000 * 2) * 100 * (100,000 * 2) combinations. That is an impressive 4 trillion combinations, but would take that high-end password cracking machine just 23.81 minutes to crack. Hackers would likely use an even smaller dictionary, too, because most people would only select from a dictionary of commonly-used words that are more likely far less than 5,000 words. If we can assume a 5,000 word dictionary, the same attack would take about 4 seconds.

That kind of attack used to take weeks or months even on a fast machine. We could typically break a Unix password on the Cray in about 10 hours back then. At that time, that was about $15,000 to $60,000 of compute time depending on number of processor used, so not worth doing for most things. Now we’re talking “let the laptop run while you go to bed” and it is cheap enough to do for recreational purposes… IIRC, we used a “large” 10,000 word dictionary then.

At one time the Unix password cryptext was stored in a visible format. We figured out that we could “precompute” all possible password cryptext and just do a “lookup” of the cryptext with 2 TBytes of storage. This was when that was an outrageous size (we had just spent about $250,000 for 1 TB and that was on a tape robot…) Now you can buy it for less than the cost of a dinner at a nice restaurant. (Yes, it was about that time that Unix / Linux stopped storing the encrypted text where it was visible ;-)

This does, though, illustrate one of the major problems of using encryption for security. Someone can always store what is not crackable today and then read it easily a couple of decades later… So a password that takes a “Billion years” to crack can be paranoid overkill, or just be something that is “good for my lifetime”… It is for this reason that I also do things like make “dummy” encrypted boxes that contain nothing, or contain garbage bits, or contain another encrypted file inside of it, or… Things that, when opened, bring doubt or work to break the spirit of an attacker. Having the “file that matters” sent in the middle of 3 or 4 files that have “easter eggs” in them like a text message saying “You wasted all your time to decrypt THIS? Har De Har Har!!” and another that when decrypted looks like it is still a bag of encrypted bits (but is in fact garbage so never can be decrypted) can be a psych out; but at a minimum consumes attacker resources (at low cost to you).

In other words, it can make sense to send encrypted messages even for “stupid” and “innocent” things like saying “Want to get coffee tomorrow?” as it creates a greater burden in the decryption attack and demoralizes.

It also gives you practice with the methodology so you are less likely to “mess up” when it matters AND it makes it hard to figure out “what matters” and can make it hard to see that one person gets “special” messages when compared to other folks.

For folks NOT in the USA, the AES download is illegal. The site claims to try to figure out your location based on your IP address. In theory you could bounce off a USA mirror of some sort, but “that would be wrong” ;-)

Software like The Onion Browser that routes your traffic all over hell and gone MIGHT pop you out at a USA source IP, or might not. It also might “flag” the attempt as being from a known anonymous service and refuse service based on that alone. It would be an interesting thing to try and I might do that a bit later just to see. (The Onion Browser bounces traffic all over through TOR sites and is a bit slower than regular networks, so using it for general downloads is not all that efficient generally…) But if you are in a US location (so doing a legal download) but using TOR, you might well have it fail by thinking you are out of the USA.

As I mentioned before, I tried making a posting via TOR Browser to my own site and the IP number assigned put me in the SPAM queue… BUT I did notice that the kinds of advertizing I got “fingered” to get, were no longer boring ads about things like stoves and bookstores but instead dating sites with pictures of young beautiful people ;-)

At any rate, for generalized anonymous browsing it seemed to work OK (if sometimes a tad slow) and it might well let you seem to come from some other country.

I’d not turn on the ‘let other traffic out my internet connection’ spigot on any system I cared about or for any IP address that might cause police to come talk to me. (At least one guy running a TOR server got a visit from folks in uniforms due to some traffic that originated from “his” site… It took a fair amount of explaining before they found someone bright enough to realize what he was describing was 1) Real. 2) Not illegal. 3) Meant he was not the person they were looking for. So run a TOR server in places and times where there isn’t any direct connection to you or to your important equipment… Only use the client services, not the ‘route other traffic out’; unless you are a died in the wool radical or inherently safe from prosecution. (I did try just turning on server routing briefly to see what happened. It complained about my firewall router being in the way. Nice confirmation of some of my security layers ;-)

FWIW, in a cursory look at TOR it looks like there is a risk of a “man in the middle” attack via a TLA setting up some TOR routers and sniffing the traffic that goes by. I’ve not looked at all the levels of encryption applied, but at some point you have an exit node that knows who you are talking with and at some point you are the last link on the return path. It might require that the TLA be either the first or last node to find things that are “interesting”, even if only a local IP address. The description seemed to say this was unlikely but I’ve not done a close look at it. So I’d only use it for things that were not really serious for now.

And don’t do anything illegal with either one.

I’m still looking for some kind of simple to use, provably secure, open source Public Key Encryption for doing public key based file exchanges. (If nothing else, it makes the first exchange of a Code Book that much easier for future use.)

For real fun, you could encrypt a file with AES and put it inside an encrypted file system made with TrueCrypt. Yes, the AES files could just be uploaded to a site (like we did with the TrueCrypt file system example) and would be much smaller for most individual files. For a multiple file block of information, using a whole TrueCrypt container takes less encryption steps as the whole block gets done in one go. For maximum safety, having many individual files each encrypted with a unique key AND the whole package a TrueCrypt encryption would be very frustrating to an attacker ;-) It would also help to protect against one or the other method having a bug, a vulnerability, or a back door.

Oh, and as AES puts a unique file qualifier on files (.aes), sites like WordPress that only allow specific file formats to be uploaded will not like them. So you would need to know to change it on the upload, then change it back on the download. Putting several of these inside a TrueCrypt volume gets rid of that overhead.

In Conclusion

So far we have a web browsing anonymizer, a decent file system level encryptor, and a very good individual file encryptor. There is a proposed architectural design for a “provably secure system” level (two computers with OS loaded from ROM each boot and some isolation layers between them) and a beginning of the evaluation of software to run on them. Oh, and I’m impatiently waiting for RaspberryPi to catch up with hardware shipments so I can buy one ;-)

I’ve still got to identify a place on the Web where I’m comfortable putting a depot copy of an encrypted file system (though Freenet has some attractions) and I’m still not sure all of the various bits will integrate well. Oh, and every part needs the “check it three times” screen for “issues”… But “so far so good”.

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , . Bookmark the permalink.

55 Responses to Sending Encrypted Messages

  1. Petrossa says:

    I use a L2TP/IPSEC 256 bit SSL tunnel without speed nor bandwidth limit with a semi-private key. Sure, the government could order my tunnel provider to disclose the key, but under the terms of my contract my provider would have to inform me instantly.

    As such i am as sure as a non paranoid person can be my traffic is illegible, my surfing untraceable and my IP never SPAM blocked. Plus i can choose which country i want to geolocate in. All countries have dedicated servers so the only slowing down is due to the hops.

    For example from France my connection is actually faster using the British or even a USA server then the French due France having the most god-awful network.

  2. Hugo M says:

    E.M, I’m not sure about SD cards or CDs, but USB based devices at least had been found to be able to compromise a bunch of different systems by sending a specially crafted device identifier which overflowed a fixed sized kernel buffer. This happened almost instantaneously, long before any mount operation. At the time this neat trick became known, I grepped through the Linux kernel sources for “strcpy” (which actually was the culprit in this case) and got about 12000 hits. Formatting the device would not have helped.

  3. E.M.Smith says:

    @Hugo M:

    The use of SD cards is somewhat different from USB devices. The SD stands for secure digital. (They were intended as a medium for distribution of ‘secure content’ by folks like music vendors). While it is always possible for a hardware device to have malware of some kind inserted at the maker, and it’s also likely that some creative person could find a way for the SD mount process to be compromised; the basic design goal was to make a secure medium; and to get the SD logo you need to meet their standards.

    Yes that is “hoping at the problem” in that it is only a hope that they do enforce decent security requirements at the hardware level and “Hope is not a strategy. -E.M.Smith”… but it is more than you have with USB devices.

    It is also the case that SD cards come, mostly, from a few big name makers. They would be putting a huge profit center at risk if news came out that one of them was making cards with a hack built in. (USB devices are made by all sorts of no-name makers). So I’d expect folks like Kensington and SanDisk to have some fairly decent QA and some sense of security needs.

    Is that enough? No. It would be far better to take a lot of the devices, reverse engineer any code in them, and assure it is ‘provably clean’; but unless you have a large funded lab and an agency behind you, that’s unlikely to happen.

    So I take a modest risk that the major name makers are doing their part of the job. About the same level of risk is involved in the computer itself. (How do you know the bios isn’t hacked? How about the disk firmware? etc.) At some point you have to accept that you are going to be trusting the hardware makers. The best way to do that, IMHO, is use large Names with a whole lot to lose if they get caught, and then “mutate the space” anyway. So do things like reformat the disks and run the machine with a network spigot that shows activity for the first week at least. (So any “phone home” action can be seen. I like to have a network monitor of some kind in any case – even if just the ‘blinky lights’ on my hub / switch / router. Part of why I shut off all the “auto update” things I can find is to prevent unexplained traffic…)

    This hangs on the notion that the easier path to hacked is the most probable one and the hard path is unlikely until the easy one has been exploited. So things like ‘backdoor’ code in the M.S. O/S is more likely from a TLA influence than any broad circulation of an SD hack in the microcode. (Frankly, they don’t have a lot of space in them for code on the controller chips, so it would be a touch hard to do without someone noticing, IMHO. A random USB maker can stick God only knows what in their dongle as they have more space to work with and nobody is looking at the total chips in the package but them… though if you could get to the controller chip fab ‘interesting things’ could be done…)

    So in the long laundry list of ‘risk points’, the SD chip malware approach is harder than getting something in a software distribution ( like the OS and all those auto-updating things …) or to get a “man in the middle” going on those updates via stealing the authentication process, or to get malware into the rest of the hardware, or to get malware into a less controlled (and larger) device that is plugged in (like USB devices), or to get you to click on a trojan on a web site, or…

    Does it have SOME risk so violates my desire for a “provably secure” system? Yes. But not more so than the basic hardware of the system itself. IMHO there is likely to also be a way to test for such malware ( but that’s a future project…) via having a bit of code on a low level card (like a RaspberriPi) that reports the ‘exchange’ with the SD card at insertion. So while not “provably secure” out the gate, it can, IMHO, be made so for selected and tested SD cards by writing such code. Reformatting the card does erase the areas most likely to be used for malware hidden in the storage chip (so any pointer to it hidden in the firmware points to useless bits after the format).

    Which comes to the last point. A kind of of “security of the herd”. Much as Linux benefits from “many hands” and many eyes looking at the source code ( it is hard to hide a hack in that context as someone somewhere will be rebuilding the code from published source and looking to see if it matches the binary download…). So SD cards have drivers that interact with them. The Linux herd likes to port Linux to all sorts of things. Into which SD cards are inserted… So there will be “many hands” and “many eyes” porting SD drivers and looking at the bit level at the interchange between them and the OS and the card. Name Brand cards will be used by some of those folks. While “Joe’s Pretty Good Beijing SD Card” might have malware that could escape this observation point, it is a near certainty that SanDisk cards have been observed in that process of porting. It would be extraordinarily hard to hide the malware handshake in such a way that it was not observed. (You would still be at risk of a TLA making a ‘special’ knock off card that LOOKED right, but was not. If you are buying your SD cards at bulk outlets and are not on a TLA “person of interest” list, the odds that you get a ‘special’ bit of hardware are so close to zero as to be hard to count the decimals…) So how many camera makers and printer makers have guys writing SD card readers and looking at the interaction with the Name Maker chips? Quite a few. Risk of being caught if you inserted malware in the firmware at the point of manufacture are high.

    Compare that with a USB stick where all sorts of Fly By Nights can be cranking them out, there is no USB Security Consortium ensuring that USB Logo can only be used of you have the right Digital Rights enforcement, and once the USB driver is written nearly nobody is likely to look at how it interacts with most of the USB devices made… Oh, and a USB stick is unlikely to be stuck into a non-PC device while most SD cards never see a general purpose computer…

    So while not a perfect security fix, it is, IMHO, way better than the alternatives and a very unlikely attack point. (I’d attack via software first and via PC directed hardware second). For a provably secure system, low level examination of the activity with a particular vendor’s chips (or even of selected individual chips) is an available option as well. If you are worried about security beyond that level, best to build your own computer from scratch parts… which is doable if really needed.

  4. Hugo M says:

    E.M, you’ll remember that this was not the first time that I tried to slow down your enthusiasm regarding the grade of practically obtainable cryptographic security a bit, espescially when it comes to Open Source software. The general idea that a huge number of experts are carefully checking open source code line by line is wishful thinking. There are very few who have the interest, the skills, the necessary documentation, the equipment *and* the time to understand the interactions between devices and any particular piece of software in a detailed manner. Plus any delibaretely planted weakness will come under the disguise of some kind of harmless looking engineering error, much as it was the case when the “dropbear” server generated weak encryption keys due to a typo in a loop control variable. The weakness introduced by this typo lasted for years and affected many different open source routers commonly used as DSL gateways. Certainly it was nothing but a typo in this case, but the incident demonstrated fairly well how a “plausible deniability” scenario would look like.

    Personally, I do trust all this cryptographic stuff as far as it can prevent a malevolent neighbour who somehow gained access to my network from breaking into my private communication. But not much more. This has also to do with the fact that nowadays even scratch parts are black boxes with documentation available only for bulk buyers.

  5. E.M.Smith says:


    Provide a better alternative…

  6. p.g.sharrow says:

    @HugoM; this is more fun then a secret decoder ring! ;-) How useful or needed is secondary at this time. I believe this will be a valuable tool in the future, but for most people probably a waste of time.
    Locks are to keep honest people honest and slow down those that are not. pg

  7. Hugo M says:

    E.M., I can’t provide a practical alternative and do think that most people can’t do either. Certainly P.G. Sharrow put it nicely when saying that a simple lock is better than no lock when the only problem is to keep honest people honest… But the risk comes with people considering a certain lock as being secure enough for their own purpose, because their assessment depends on assumptions they are usuallly not aware of.
    I’m certainly showing my ignorance here when asking P.G. what a “secret decoder ring” might do, but an inconvenient alternative would consist in constructing a random number generator which measures the delays of radioisotope decay. Using the output of such a device and a simple xor-gate encrypts the message in a One Time Pad fashion. However, in the last years a few very interesting papers have been published, which reported that the radioactive decay itself appears to depend on solar distance and also on solar activity in as much that solar flares can be predicted five hours in advance. A mystery, if true! But testable by almost everyone around the globe. I’ve seen that people rip off the sensors from smoke detectors and use the radioisotope contained therein to build random number generators. Correlating the raw output with solar activity should be trivial task.

  8. p.g.sharrow says:

    As in the ancient Celt universities, the people of the Group must be able to communicate without too much trouble and others not in on the “trick” would have great difficulty. If you wish to communicate with me there must be something about you that I know and something about me that you know that must be a part of the cipher creation for encryption and decryption. Suppose “I” send a “file” to “you” and you know that “I x file x you / date of message = encryption then you could decrypt without too much trouble and the needed unique keys would be in plain sight. pg

  9. Hugo – it seems to me that if you encode something using a truly random number, you have to know what that number was in order to decode it. Using a nuclear decay should be pretty random, but even shipping that source/generator to someone will not reproduce the same number sequence. Even a one-time pad has to be produce in duplicate, so that the receiver of the encoded message can decode it.

    There has been some speculation that nuclear decay is triggered by neutrinos ( ) so that the rate will depend on the neutrino flux where you are. Either neutrinos or some other almost-indetectible particle disturbing the stability of a nucleus seems to make sense. If so, then your solar flare/decay rate idea should be easily testable. The interesting corollary to this is that a nuclear-powered interplanetary probe should have distinctly less power available as it gets to interstellar distance. says it’s actually got more power than predicted. Maybe the neutrino flux is higher there?

  10. adolfogiurfa says:

    @P.G.: No encryption needed unless you want to play with those kids. It´s a childish endeavor it has lasted too much: From “Illustration” to “Land grabbing”, form “Egalitè, Fraternitè et Egalitè” to “Global Governance” and “Sustainability”. But there are cycles kids, so now your time is over, playing time has expired.

  11. Hugo M says:

    Simon –

    1.) in my post above I assumed that everyone knows how a one-time pad is used and that a nuclear decay occurs at random points in time and is not repeatable. Clearly one has to provide a secure channel for the key material itself. This isn’t much a problem if you can meet you remote communication partners from time to time personally. On the other hand, since the key can be considered to be pure random, one could perhaps use some PK encryption scheme to transmit it separately? How does a cryptanalyst when finally know that a particular key is the right one when the decrypted material does not contain any predictable plaintext fragment, but only pure random bits?

    2.) A conservative explanation for the longer than expected lifetime of the Voyager RTGs could be that the model contained worst-case assumptions. Regarding nuclear decay and solar distance, there was also an investigation into the conditions of the RTGs of the Galileo (or was it Cassini) probe on its way to Jupiter. This investigation could not confirm any abnormilty related to the increasing solar distance. However, the diagrams shown in the first publication on this matter (using data from the Physikalisch-Technische Bundesanstalt in Braunschweig, Germany) actually showed a phase shift of around 90 degrees, i.e., the maxima and minima in nuclear decay rate were not found at the perihelion and aphelion, but at the vernal and autumnal equinox. That could mean that the decay rate on earth depends on the direction of earth’s velocity vector …

    Interestingly, in the publication you linked above, its author Falkenhein also states that

    The phase of Po (t) is such that the positive peak is around mid February, quite close to the expected positive peak if one assumes that β-decay is caused partially by the periodically varying solar neutrino flux and partially by a supposedly more constant neutrino flux from other sources.


    If there were no other neutrino sources than the sun, then the expected peak amplitude of Po (t) would be approx. ± 3.3%. That is approx. 9 times more than the measured amplitude of ± 0.37%. This implies that the neutrino flux from other sources has an approx. 8 times stronger effect on β-decay than that from the sun.

  12. Hugo – thanks for the explanation – I’ve not had to use cryptography so getting the key to the other party when we don’t meet has always seemed to be a weak point. Decryption of a random sequence would be difficult, as you say. Since I have friends in various countries with infrequent or zero contact, though, that first key may still be difficult to send. A paranoid wouldn’t even post it.

    Also check out for a possible explanation of the ~0.4% variation in decay rate. It’s interesting that something that we “knew” was constant is in fact variable with location/velocity and may be thus better controlled with a bit more research.

  13. p.g.sharrow says:

    Neutrino flux is not the cause of atomic decay, it is the result. Reduced local density of energies causes increased atomic instability. Fission / fusion events cause the thing that is called a neutrino to be released.
    Any encryption needs to be simple enough to use and good enough for the use it is intended for. If it is too difficult to use it won’t be. For the most part anything that is not “in the clear” is good enough, as the trouble involved in digging it out of the data stream and decrypting it is cover enough.
    If someone really wants to get your information they can IF they can afford to crack it after they find it. pg.

  14. pg – what I find interesting is that it looks like neutrinos could be both cause and effect. This may be one of those bits of information that lead in new directions.

    At the moment I haven’t the spare time to dive deep into encryption. I do wonder about the website encryption that we use to pay by credit-card, though. In order to encrypt, data on the key must be passed between my computer and the website. If someone watched all the packets passed, the information to work out the key must be there, thus my ISP should in theory have the ability to decrypt all my encrypted 128-bit data and thus hack my bank account etc.. Passing the key is the weak point, as EM also showed with the Almond Pressed Duck.

  15. Hugo M says:

    Well, to harden this weak point https uses the SSL protocol, which involves a public key encryption scheme to exchange an encrypted session key. The public key is taken from a chain of publicly available, digitally signed certificates. A practically very relevant weakness is that some of the so called “certificate authorities” have become known for issuing certificates to certain client companies, which enabled them to perform man-in-the-middle attacks, posing as, say “*” while in fact they are not. This real world example, the DigiNotar incident, was only the most prominent one. There were others. Such a digitally signed certificates normally enumerates legitimate IP – addresses (or, less secure, DNS names) with the commercial name of the service provider and his legitimate public key. As I said before, the whole procedure may be well suited to keep out some malicious idiots but not the organized crime in the broader sense.

  16. P.G. Sharrow says:

    @Simon; The experiment of EM sending a test to me was a poor example as I have very little experience with encryption use and the manor was unexpected. So I had difficulty setting up the program, finding the password, and determining my errors. You and Paul Hanlon had less information but good memories and you knew what you were doing. You helped me discover my errors much quicker then if I had had to hack my way alone, my usual way of doing things.
    The manor of passing the password and encryption must be understood by both parties before hand. The keys can be in plain sight.

    Over the last 60 years I have been examining the standard theory of physics and its revisions as well as known bits of real data from experiments. Often the data and theory do not fit together well and the real scientists involved admit this and hope to revise the theories at a later date. Einsteins’ E=MC2 is case in point, He knew it was logically wrong but was unable to get a better formula to balance. Mathematicians are sticklers for algebraic balance to their formulas. I prefer the formula to work logically with the facts. To do my experiment it was necessary to write my own theory based on facts as known to me and the mathematicians can write formulas after the fact. this is why I created my own blog to set down my work in one place instead of my usual scattered about organized confusion. pg

  17. Hugo M says:


    thanks for the links! Interestingly, only beta-decays are measurably affected by the the ominous radiation originating from the sun and the center of our galaxy.

    This could explain why the investigation into the RTGs of the Cassini Mission was negative in this respect. Alas this also precludes my idea to use the small amount of radioisotopes built into certain types of smoke sensors, simply because these sensors mostly contain Am-241, which is also an alpha emitter. So where is Olliver Manuel when you need him? Are there “safe” beta isotopes with sufficiently long half-life available for demonstration purposes?

    Anyway, if the modulation caused by distance from the sun is already 0.4%, what if some changes in our sun or galaxy modulate the heat produced by radioactive decay to a far greater extent? Oklo comes into my mind, but also Marc Herndon’s hypothesis, who thinks that earth’s inner core might be a natural reactor too. Last but not least, such variations would obviously also affect radioisotope based dating methods. I’m citing Sanders 2008, :

    It has long been known that the 14C calibration curve, which relates the known age of tree rings to their apparent 14C ages, includes a number of “wiggles” which clearly are not experimental errors or other random effects. A reasonable interpretation of these wiggles is that they indicate that the Sun’s fusion “furnace” is pulsating, perhaps for reasons similar to
    that of the Cepheid variables, albeit under a very different regime of pressure and temperature. If this speculation is correct, we are seeing the heartbeat of the Sun—the 14C
    calibration curve is the Sun’s “neutrino-cardiogram.”

    Elevated neutrino flux during a relatively brief period would have two effects: (1) a surge in 14C fraction in the atmosphere, which would make biological samples that were alive during the surge appear to be “too young” (2) depletion of 14 in the biotic matter already dead at the time of the surge; this is a consequence of the recently discovered Jenkins-Fischbach
    effect, which is an observed correlation between nuclear decay rates and solar activity or
    Earth-Sun distance.

    In addition, the precise value at any given time of the “half-life” of any unstable isotope —
    including 14C – must now be considered in doubt, since the Jenkins-Fischbach effect implies
    that we may no longer view the decay rate of an isotope as intrinsically governed and
    therefore a constant of Nature.

  18. P.G. Sharrow says:

    @Hugo M; you have put your finger on the problem of steady state assumptions. The universe is a bit more complicated the modern science allows. Creation by way of the”Big Bang” has a few holes in it, and one way break down of neutrons is not logical. The universe may well be more steady state with creation and decay going on all the time. pg

  19. Hugo M says:

    P.G., I have no idea what you mean with “one way break down of neutrons” being illogical. Can you expand on that a bit? You certainly think that neutrons can be created under certain conditions? Btw, the staunchest supporters of the Big Bang hypothesis sit in the Vatican, for a very obvious reason. I tend to believe in the possibility that the universe was always there.

  20. P.G. Sharrow says:

    @Hugo M; I was pointing out that in standard theory neutrons only decay into hydrogen. The creation of all neutrons took place early in the universe created by the Big Bang. Many years ago it was pointed out to me that all nuclear energy was the result of “neutron decay”. E=MC2 and the creation of neutrinos is the explanation for the direct results of the outcome produced by neutron decay. Problem, the creation of neutrons create energy and mass, decay of neutrons create energy and lose mass (neutrinos).???????????????? This can not compute, therefore neutron creation can not take place in standard theory under present conditions in physics. LENR seems to allow for neutron creation, sort of. 8-)
    I prefer a steady state universe, GOD is the soul of the universe, “The Word”, “That which IS”. I don’t need some dude sitting on a cloud, or some old guy sitting in a throne in Rome to tell me how to behave toward others.

  21. E.M.Smith says:

    @Hugo M:

    So your approach is a more random key generator… OK…

    FWIW, the asserting that nobody much (or insufficient somebodies) are looking at the code is simply not true. How do I know this? I’m one of the “somebodies”.

    Yes, there are millions of folks who just download the binaries or ‘compile and go’. But there ARE a large number of folks who look AT the code to assure it is secure. The question of “are there enough?” and the one of “are they good enough?” are unanswerable, and mostly opinions. My opinion is “yes they are” your opinion is “no they are not”.

    What is the basis of my opinion? At Apple, for 7 years, my team of systems programmers kept out ALL black hat attacks. How did we do this? We demanded the source code for our servers. We even got a copy of Ultrix source from DEC (though it was like pulling teeth and took 2 years… at first they shipped it on microfiche… and that added another 1/2 year to get magnetic media.) We often fixed security holes before the vendor even new they existed. From Sun OS, to BSD, to Ultrix, to Unicos (the Cray Unix OS): My team read and fixed the source code, then fed the “issues” back to the vendors. We were just ONE customer doing this. ( I’m certain that other users, like TLA’s, were also getting source code…)

    Every single company making a device that uses an SD card has to make a ‘device driver’ for it. Some start from public or pre-made sources, but it still requires a “port”. Someone has to match the source code to the actual device. Drivers typically have a front end and a back end. One faces the hardware, the other the rest of the device software. A real person has to make sure both parts talk to each other AND talk to the two interfaces correctly. (How do I know this? One of my guys was a device driver specialist in his prior job and ‘we talked’ – and had to make device drivers ‘go’ for several new and cutting edge products. We had the first mega-bit video interface ever installed on our Cray, as one example. Our R&D group put a ‘mouse’ on the Cray too. Our R&D group made it a “PC” – Personal Cray ;-)

    So somebody sets out to make a new camera and some programmer gets the job of making the SD card work. In that process he sets up a ‘breadboard’ and has a lot of instrumentation looking at signal lines and what bits flow back and forth. Yes, a real person watches the handshake at the bit level to debug things. My old roomie worked at HP writing diagnostic microcode; now he teaches kids how to make robots. THEY look at the bit flow when debugging too… It may just be a batch of High School Kids, but someone is watching the bit flow. Stick in a card that is supposed to send “I am here!” and it sends a “whole lot more too”, they will be asking my old Rommiee “why?…” and he’s good enough to figure out it’s a virus or other exploit.

    I managed the QA process on the C (and other) compiler tool chains that went into various Linux (and related) products. We had a dozen or so guys who LIVED in that compiler code. Every line of it. Enhancing it. Adding features. Patching bugs. Testing and proving it. We had hundreds of customers who had source code and who had guys living in that source code (we knew this as they would send us fixes, patches, and enhancements.) Every quarter we’d run the entire tool chain trough a ‘regression test’ that re-tested every single bug we’d ever found (along with basic and complex functionality). My staff would then look inside bits of the code to assure it ‘was as advertised’. (That group was eventually absorbed into Red Hat and last I looked the folks there were doing more, not less.)

    Realize I am NOT asserting it is a perfect solution. I’m asserting it’s a darned site better than any other alternative I’ve seen.

    BTW, take a look at what the Embedded Systems guys do when making things. Standard is to have a breadboard and a load of instruments to monitory just what goes in and out all the contacts / leads. While your assertion that there are not hundreds or thousands of folks pouring over every line of code may well be correct for things like “grep”, it is not valid for things like SD card drivers. That particular bit of hardware and device drivers for it are on hundreds of embedded systems boards being worked on by thousands of folks with hardware level instrumentation. I’m about to be one of them as I get an embedded system type board running as a “reasonably provably secure system”. While I likely won’t be putting a scope on the SD card pinout (unless I ‘have issues’ then I’m dragging in the ol’ roomie and his scope…) I will be looking over the driver code to assure it can only do a normal “open and read” and not do anything “useful” when any “odd thing” comes from the card at insertion. (Higher levels of code will deal with things sent during normal read / write and get their own inspection.)

    Would it be better to have NO visible source code? Nope. Doesn’t make me a perfect ‘screener’ but lets me catch what I can. Just like the thousands of other folks making embedded systems cards run with an SD card.

    As an alternative example: I have ‘blinky lights’ on my network. I deliberately buy gear that ‘flashes’ on traffic. WHEN the ‘flashy lights’ don’t match my expected traffic, I “scram the system” if I’m worried or a “inspect and entice” if I’m not worried and just curious. Yes, “old habits” from decades of “defending the corporate network”. Crude level, but helpful. If something tries to turn my machine into a bot node doing God Only Knows what, it will involve “blinky lights” on traffic. I’m sure I’m not the only one who does this… There is a whole world full of “old systems admins” who DO look at the bit flow and DO look at the source code and DO worry and inspect any ‘oddity’…

    The history of Linux and the history of various other ‘security bugs’ has moved consistently from “security by obscurity” with the notion that keeping source code secret kept folks safe toward “security by diversity” with a million folks having the source code (and a few hundred thousand of them looking at some of it and a few thousand looking at any one ‘issue’.) Over time, security notices have gone form “secret for a while” to “public NOW”. As soon as an exploit is found, publish it and let the sysadmins of the world react NOW. The history shows that the more eyes looking, the faster the find and the faster the fix.

    Again, is it perfect? Nope. Just better than all the alternatives. But since people ARE imperfect, I typically use a mixed strategy for anything that’s really important. The odds of all of the levels having an ‘exploit’ simultaneously is vanishingly small.

    So a given file will be encrypted with a “probably good” encryptor. Might be commercial, or might be open source. It is mixed with a bunch of ‘chaff’. Other encrypted things that are just junk. Why? Cracking is a race condition. Hiding the desired target in a bunch of time wasters makes that race harder for them. Yes, a ‘security by obscurity’ in that the exact target is hidden in plain sight. ( I’m especially fond of encrypting large chunks of Microsoft binaries as the chaff… but also sometimes use things that ‘look interesting but are not’ and sometimes just flat out ‘honey pot lies’…) That, then gets put in a larger container that ALSO gets encrypted, but with a different method and key.

    Now you have to find an exploit in 2 different methods and / or compromise 2 different keys. Oh, and you get to wade through a 10 : 1 or 100 : 1 workload uplift on distractors…

    Now, if I’m going to SEND that to someone else, it will (preferably) be delivered on a bit of physical media (so that it must be captured to be attacked at all) or it will be send via an encrypted pipe (via a third encryption method / keys). Preferably with some “blending” that makes it hard to do ‘contact tracing’ and harder to find the bit that matters. So transport via a VPN in use for a lot of other traffic between sites too, or via something like The Onion Network or anonymizing servers. You send a 1/2 dozen batches of “photos” (maybe your own, but often just junk from the internet) and a few “install this!” files of compressed encrypted standard boring software. Somewhere in it you send your secret message.

    This does two things. First off, it gives a 10:1 or 100:1 added uplift in what the attacker has to store and / or crack to find “the good stuff”. As cracking is always a race condition of newer faster hardware and newer methods against older systems: ANY older method can be saved on tape / disk / whatever and attacked decades later with superior tools. It is ALWAYS a ‘race condition’. So adding that ‘uplift’ to the compute load buys more time in the race. (Hopefully enough to expire the ‘time value’ of the message. Does not good to get “here is a new secret method to encrypt pipes!” a decade after it has been replaced with an even better one…

    Second, it is a psych tool. Your opponent is investing time and resources into trying to find out your secret. By first off making it look like the bulk of what you send is really no secret, you reduce the value of the computes they expend. This makes it hard to justify continuing to decrypt your stuff. It’s nearly free to encrypt “M.S. Office” and send it to someone. It is very expensive to decrypt that for the 10 th time… That is not only an ‘issue’ in the budget process of decryption, but it is highly discouraging to the cracker. The 10th time you get “Hi, here’s the latest version of Word. It think I sent it already, but better safe than sorry!” you start to doubt the merit of your work… Folks look for more ‘interesting’ targets to go after.

    (No, it doesn’t work all the time. Nothing does. It is ALL a matter of tilting the field of probabilities. So send EVERYTHING possible encrypted. Don’t just send the important stuff that way. It is simply shouting “Here is what matters!” to do that.)

    Now, by the time you’ve used the Human Factors layers (sending crap, making everything look irrelevant, etc.) and done a couple or three different levels of encryption and ‘blending’ AND done a basic “does the hardware act as it ought and does the software and activity monitory look correct?” you are about as secure as you can likely expect to ever be.

    Now we add one more layer…

    For things that are truly critical, you use a shared code book.

    Codes can not be cracked. They can only be captured. That is why the Navajo Code Talkers were never “cracked”. Even a native speaker of Navajo didn’t know what a “turtle” meant or what a “great bird” might mean.

    Codes require a shared code book, so the big risk is in the distribution of it. It can be captured, or it can have contact tracing applied so you know who is “in the network”. There is a whole additional set of “art” applied to code books and how to share them.

    Still, with some care, a code book can be shared and agreed. One of my favorite ways is to pass the ‘code book’ as a title. Say “Websters 2007 Collegiate” or even just the ISBN number. Now I send a ‘code’ of digits: Page, paragraph, sentence, word. I and a ‘friend’ are at a common and open public event. To change ‘code books’ all I need to do is, in passing, say “Encyclopedia Britannica 1910″… or leave it on a business card and do a “normal introduction”… (for better security it is better to use a really more obscure book… It’s also possible to just add ‘letter’ to the list of digits so the book just needs the alphabet in it, not all the desired words.)

    While a carefully crafted ‘code book’ can be more effective (in that it can’t be a ‘stumble upon’ copy by, say, guessing you are using the Websters) it is harder to do the code book distribution without detection or capture. Still, having a ‘one use tear off book’ with things like:

    Raven – “Be at the meeting site Tuesday”
    Shoot – “I’ll arrive late in a blue suit”
    Arrow – “Anyone with black socks is to be ejected”

    then sending “Shoot the Arrow at the Raven” is entirely opaque even if sent in the clear (unless the code book is captured…)

    So you can then send your ‘really important message’ inside all those encrypted layers in just that kind of code.

    Mixed with a load of ‘crap’ that said things (NOT in the code book!) like “Frogs fly South” and “Eagles are Shot with Guns” and so on… Well, the person looking to capture the message doesn’t even know what IS a message…

    So, you see, by using several layers and by having “reasonably proven secure” methods, a practical solution to “communicating secretly” that can beat the race condition of decryption is not all that hard to do.

    Or, put much more kurtly: So what do you think of that last encrypted batch of FOIA emails? Nice read, eh? /sarcoff>;

    Would I do that level of effort for “my stuff”? Frankly, no. I don’t really have any secrets that need it. (The couple I do have exist only inside my head and are never written down nor shared. Sorry, no reason too… “need to know” and all that…) I do have some encrypted containers on my laptop that hold most of my “stuff” but frankly, it isn’t really secret stuff. Almost entirely downloaded PDFs on weather related things and Linux software, sorry to say… Why do it? Because it is interesting technology. To “tweak the nose” of anyone who decides (stupidly) that I ought to have a “Tallbloke and the Constable” moment. (Heck, even if forced to divulge the pass phrase they get their nose tweaked. What’s not to like? ;-) To help others who might have a real need. And lastly, but probably most important: Many kinds of virus et al try to insert themselves into executables and / or specific types of files. By making the encrypted container look like a non-target type, all the stuff in it can be protected from such an attack. I leave it encrypted almost all the time, so any ‘infection’ can be repaired by a roll back of the OS to last known good ( a built in on my box). Even an infection of the encrypted container is most likely to just cause a ‘fault’ on the decrypt (so I can go to the back up copy…)

    Also, FWIW, I’ve set up encrypted links between corporate sites for years. Various technologies at different times. Heck, we did a microwave link at one point for very high speed remote connection. Lots of VPN links too. Would it be secure against an attack by a TLA? No, not at all. Would it be secure against ‘record and crack later’? No, not at all. But email between a worker and his boss isn’t interesting to them and doesn’t need that level of protection. It is only important to prevent “snooping” by Joe Random and to prevent common levels of “industrial espionage”; and it does that Just Fine. (How do I know THAT? Because me and my staff tried to attack it ourselves and we were ‘pretty darned good’. If it wasn’t worth the time it would take US to crack in, it wasn’t worth it to the other guys either… )

    Were our RSA 56 bit links THEN good enoug NOW? Nope, not at all. RSA 56 bit can now be cracked in real time with nearly trivial “stuff”. But then again, we don’t have those messages from then in the air now… And the email per a project from 1990 that ended in 1994 would not be very useful even if recorded and decrypted now. Were I doing it now, I’d likely use AES or similar. In 20 years will THAT be ‘nearly trivial’ to crack? Most likely. It is always a Race Condition. (Thus my ‘use several levels’ and “blending” and distractors and for really really important stuff, a ‘shared code book’.) And, of course, ‘be uninteresting’ to begin with… if nobody looks and / or records your stuff, you are already ‘secure’…

  22. Hugo – glad the file helped you; I found it because of this discussion, and if it’s true (seems so) then a lot of the previous ideas of “fixed by nature” become invalid.

    pg – Fred Hoyle had the idea of a steady-state universe but his idea was overtaken by Big Bang. If Big Bang were true, the Universe started as a Black Hole and should therefore still be one. There are just too many places where Big Bang inserts the phrase “here there’s some magic happening”.

    EM – I also wrote hardware-level drivers for SD cards (when the biggest I could get was 64Mb!) and had to look very carefully at the bitstream from it. Any extraneous bits would have been noted and queried. Of course, anything written for a PC would have done nothing to the Dragonball (68K-based) core I was using – not all computers then used 80×86 processors, and now that is even less so. A ‘scope works, but logic analysers give an easier view and can also decompile a datastream.
    With source available, there are a lot of professionals and gifted amateurs looking at the code for two reasons – sysprogs want to find exploits and stop them, whereas blackhats want to find them and use them. The code quickly gets clean with that amount of exposure. Secret sourcecode did not stop the attacks on Microsoft code, and still doesn’t. Decompilers are much better now than when I first used them in my job – pretty well good enough to modify a bit and recompile and all you lose is the comments and the expressive variable names.
    Interestingly, back when 16Mb SD cards were the biggest you could buy in the shops and the 64Mb ones were engineering samples was only around 12 years ago. I can now buy a 64Gb one.

  23. P.G. Sharrow says:

    @EMSmith:More for me to consider. pg

  24. E.M.Smith says:

    @Simon & HugoM:

    The nuclear decay thing is just a way to make a more random “code book”. As such it has all the same problems of a code book (contact tracing, capture) coupled with a very large and very hard to communicate code. (Folks do very poorly at long strings of digits).

    The only ‘saving grace’ it has is that it is random and non-guessable. Not exactly a great leap forward… There are a lot of “good enough” random and non-guessable key generators.

    A large discussion can be found with a simple search:

    and there are a lot of ways to do it. (Frankly, one of the first problems I was assigned in my very first programming class in FORTRAN IV was to make a random number generator. It isn’t all that hard. A common method is to get the time, truncate the high order bits, then shift it around a lot. Another is to do math that causes bit overflow and pick up the ‘trash’ that results. Not purely ‘random’ in the mathematical sense but quite ‘random’ enough for use in keys.)

    Having a more random code book is not very important, frankly. Nice, but neither needed nor sufficient.

    @P.G. Sharrow: “Secret Decoder Rings” are still useful. “Ring shift” encoding was the basis of Enigma and it to a lot to crack and a few new inventions… My old Secret Decoder Ring was the start of my interest in the whole field.

    The Romans used a method that worked for a very long time. Take a standard diameter staff. Wrap in writable cloth. Write your message along the long axis of the staff. Unwind the cloth. The characters are now “semi-randomized” along the cloth. To ‘decode’, wrap on an equal sized staff… (you do need to have more than one line of text and cover the diameter of the staff with writing to fully hide the message ;-)


    “Code book exchange” has always been a major pain. At a minimum it enables contact tracing. At a worst case a captured code book gives away the shop (as when we captured a German sub complete with code book / Enigma settings.)

    The “solution” to this is “Public Key Encryption”. There’s a LARGE body of literature on it, and it looks to work fine as near as I can tell. (After several years of work on it. First looked at it when RSA 56 first came out). So while you can attack the encryption brute force, or the key generation via key guessing or dictionary attacks, the method looks secure.

    A common scheme is to have a public key handshake then inside of it do frequent ‘key exchanges’ to mutate the pipe. Even if the public key gets cracked, the inner tunnel has ‘moved on’ via key exchanges that are now long gone… Setting of the particular rate of key exchange is one of the things you set in configuring VPN tunnels on routers.

    While, in theory, one could record the entire signal history and consecutively crack the steps, it’s not easy… The inner keys being done in a way that is also hard to crack…

    The Pressed Duck example is, in fact, not applicable to your online banking. As that is done with a much more sophisticated method that is not just a ‘code book’ key exchange.

    First off, I used ‘dictionary words’. A known method of attack defeats it in minutes to hours depending on your compute $$$. Second, it was too short. Third, it was described (with “excessive hints”). Forth, the goal was NOT security(!) but education. I was hoping someone could ‘crack it’ as a better education in code books, passwords, and vulnerabilities. In fact, I was structuring the “problem” as a kind of direct cracking by P.G. as he had no idea what I was up to. So I was making it easy to “crack” by a relative novice and without too much compute load.

    If you want an uncrackable bag of bits, I can hand one of those over right now. No fun, though.


    As the goal was ‘education’ and ‘you learned’ I count the experiment as a success ;-)

    Per ‘steady state’: We already now that the universe has “laws” that change with age. Just that most physics presumes they only change a lot in the first brief period of life of the universe. I’d assert they also change rapidly with gravity field ( see black hole physics…). That, then, implies their may well be other ways to “change the laws of physics” (despite what Scotty might say :-)

    Back at neutron decay and encryption:

    I’d rather have a public key / key exchange / frequent change of keys set than a “really random code book” to exchange (at least for the outer layers). I’d also rather have a code book exchanged by a “secret phrase” than via actual physical book exchange. (Best might be an agreed code for exchange of code book descriptions… for the code book description exchange. So something like “I’ll say the Date and rank – like July 23, 1920 – 2; and you look in the NYT Best Seller list for the second book on that date”. Then even someone who captures the verbal or written exchange of 230719202 doesn’t get a decent clue as to the code book… (though folks would need to be careful in looking up the particular book and buying it so as not to leave ‘fingerprints’ on the credit card or Amazon showing a pattern… Cash Only and physical bookstore buy at a small place without cameras ;-)

    At any rate, the bottom line on encrypted message passing is that it is always a race condition, it is always best to use multiple layers, it is typically enough for the time value of the information being passed, and there are some darned good methods in current use. Never forget the value of “human factors” and blending chaff. Public Key, key exchange, frequent re-exchange and passing of private code books in secret methods when combined with the rest would be a nightmare to unscramble. (At that point, sneaking a key logger onto your box would be MUCH easier, or even just a ‘screen scraper’ from that van across the street ;-)

    Oh, and Hugo: Per the “how to attack when the contents is not known plain text?”: Pretty much all message passing now is not just ‘plain text’ but text encoded in various kinds of mathematical transforms. Even ASCII is such a transform. So as long as your “random numbers” are used to encode for letters, that will be picked up. One fun distractor / delay tactic is to use automated translation to periodically shift your language of transmission. (You need two that do a far job on the forward / back transform). So each paragraph gets a different language. Now things like “population count” on letters ( “E” is most common in English) bread down if the span of application is beyond one paragraph. Toss in some Japanese and Chinese and mix some Arabic and Hebrew just for grins ;-) No, it won’t prevent a decryption attack, but it will sure cause folks some added heartburn and cash bleed. Now, do that with, oh, Shakespeare’s Sonnets as the content and you have a mighty fine Human Factors bomb…

    (Can you imagine getting through weeks of slogging, finally figuring out it’s one language / block. Cracking a few blocks, and getting some really crappy machine translations of Olde English Poetry? That’s gotta hurt ;-0 Probably even enough that you don’t do all the blocks and don’t notice that in the 12th Sonnet in the 12th block in the 12th sentence it says “Britania 1920″… in Japanese… The biggest risk in that kind of hypercomplicated method being, as with ALMOND Pressed Duck, some of the ‘shared understanding’ is a bit murky and it isn’t possible for the target of the communication to unscramble it all either ;-)

  25. EM – thanks for the education. I may have a need for it sometime soon, and it’s good to know how to make life more expensive for the opposition. At the moment I don’t encrypt anything on the KISS principle – I don’t need to and it’s something extra to remember how to untangle the encrypted stuff. Forgetting the key would be a problem, so I’d have to write it down, but then it would be useless so I’d have to encode the key as written and have to remember how to decode it…. Apart from that, sending encrypted files is an advert that you have something you want to hide.

    Back in ’86 or so, I wrote a (simple) encrypting disk driver to password-protect disk volumes – it worked at device driver level. Using this I encrypted a 10Mb hard disk. Having set it to one side for a while, I thought I’d look-see what was on it, and had forgotten the password. **It happens….

  26. P.G. Sharrow says:

    @EMSmith; My education was an important part of this effort. The needed concepts as well as the equipment and other tools.Others have added to this overall understanding of the needs and limitations of useful security. Useful is the key word, the total must be workable for the people involved or it won’t be used, no matter how good it is, but still not worth the effort to spend a lot time to keep cracked for those that are just fishing even if they think that they are good. It would appear to me that a mix of equipment and techniques would make the most difficult security to crack, as well as being as user friendly as possible. Complex generation of passwords that can be easily forgotten might not be useful. pg

  27. Hugo M says:

    E.M, my question was not how to decrypt encoded plaintext, but how to break the chiffre if the plaintext actually is a true random sequence, given that the encryption algorithm itself contains no backdoors and no parts of the key or the encrypted random numbers are known to the attacker. Besides, using computer generated random numbers as you proposed above is known to be a very bad idea. This is why TPM chips contain a hardware RNG based upon thermal noise as a random source.

  28. E.M.Smith says:


    The phrase “how to break the chiffre if the plaintext actually is a true random sequence” is nonsensical. It can either be a cypher, or it can be ‘truly random sequence’, but it can not be both. That is why I didn’t address it directly.

    IF there is an encrypted text, BY DEFINITION the cryptext is not random. You can substitute ‘random’ strings for the encoded characters, but that just changes the length of text that is a ‘character’ and is non-random. You seem to be presuming that attacks like “population count” are the preferred or most common attack. They aren’t any more. (They only really work on the methods of about 1960-80 era. With frequent key exchange a stream is very hard to attack that way.)

    Having a book of random strings that you stick in for given words or characters just doesn’t buy you much. And it does it at the cost of needing a “code book exchange” of specific and large values. A BIG book that must be exchanged and will clearly finger the “contact trace” and be subject to a variety of intercept techniques. It has more value in changing tables inside public key encryption methods.

    Per “thermal noise” being “better”: It isn’t. It is a very good technique that is easy to do, so well worth doing, but you can do a very good job by other means. Yes, you must be careful about it, but it isn’t all that hard to get a “good enough” and “random enough” result.

    So the idea of a thermal based random number generator to make your ‘cypher key’ and then exchanging a ‘code book’ of those keys (or ‘substitution keys’) is an interesting one, but not superior to Public Key Encryption or AES in any way that I can see.

    You see, If I’ve got: “To be, or not to be, that is the question” encrypted, it doesn’t really matter if I use “5” or “J” or “4958148270425700198” as the substitution for “e” (other than that the last one takes more time to transmit). It is no more “hidden”. Unless you do “something else” you will end up with that same string in both “be” words and in “question”. Attacks based on population count will still find it (as you never now what the ‘scope’ is for a single character substitution so need to search the space anyway). The degree of ‘added security’ from a nuclear or thermally generated ‘substitution key’ is not significantly better than a software call to a radomizing table generator. The same attacks can be applied to both with about the same results. ( From population counts to ‘known text’ attacks to ‘man in the middle’ to ‘brute force’ to ‘dictionary attack’ to… you just apply the whole suit of tools anyway – at most shifting the order of application based on ‘good guesses’ about likely method). And unlike public key encryption, you now have a ‘code book’ or ‘substitution key’ to exchange and all the risks that come with that.

    Public Key encryption really did obsolete code book exchange for many (most) uses. It is a very good and very secure method and it’s darned hard to beat. So I’d only use a ‘code book’ method INSIDE such an outer wrapper and preferably with the ‘code book’ exchange as a ‘hidden name’ to a shared source rather than actual text exchange (that you need to do with ‘truly random’ text).

    Basically: Getting “random enough” values is just not much of a problem. Exchanging code books or substitution keys is weaker.

    @Simon & P.G.:

    For several years our ‘method’ of making passwords was crude, but VERY effective and helped with the ‘not forgetting’. When time to change came, we’d meet in a room and look around. Pick a couple of objects and either use the text printed on them OR their name (or similar hard to miss attribute) and concatenate a couple. Sometimes it included the calendar text, sometimes a book title. One time it was the name on the fire alarm pull ;-)

    Turns out it is a lot easier to remember “I looked at the clock and the TV” than some randomly picked text. (The clock right now has “Big Ben” and the TV has “PHILIPS MAGNAVOX”. Concatenate that and it’s a pretty good password – at least in the 1990s ;-) As the room at present has 600 Star Trek books on the shelf on one side, my library on the other, a stack of 4 VCR/ DVD recorder / Satellite dish and TV, a dozen bags with names on them (like a ‘sport bag’) and a dozen cameras and more… it would take a very long time to try them all even if a person did have access to the room to read them… A “dictionary attack” would work, provided it included all the brand names AND some words in Vulcan and Klingon ;-) (one of the books is our Klingon Dictionary ;-) though… Oh, and some numbers off the three light bulbs in sight and some of the numbers off book spines…

    Then communicating the password to the others on the team is also a little bit protected from folks overhearing. “The bulb by the door and 3rd row 2nd book title”. Not something you want to have be public, but if someone has turned on a microphone on a laptop, they still didn’t get enough…

    There are other such methods that I’m not going to share in a public forum as they are what I’m using now ;-) But you can dream up some pretty easy. Pi to 4 and Phi to 8 for example, or Periodic Chart column 4 row 4. Many such things are possible…

    Especially for things you need to type in frequently and where they don’t need TLA proof passwords, things subject to some degree of ‘dictionary attack’ but not a simple one are ‘reasonable’. (My favorite sushi is ‘highly productive’ in that regard… “saba udon and 2x salmon” not being in the typical dictionary… very easy for me to remember, very hard for others to guess.) Another trick is to just type every other word backwards. “tnemmocPost” is “Post comment”… The latter a trivial dictionary attack crack, the former harder.

    So you can pick a ‘memorable method’ that isn’t commonly known, share it with the folks who will need it, then creating new passwords that are ‘easier to remember’ and can be shared at lower risk is not all that hard. Such passwords are subject to brute force cracking these days (due to being so short that searching the entire string space is a matter of minutes to hours) so for public exchanges, using a Public Key wrapper is very important. Part of why using things like book titles or even phrases (sentences) from particular pages can be helpful.

    At any rate, creating truly secure passwords these days means making “pass phrases” and including special characters helps a little. (Length matters more but both help). That’s a whole topic by itself, though. For practical personal use, just having a modest complexity password is “enough” security. Frankly, I like using fairly easy ones for the “easter eggs”. I WANT them to crack the 20 Mb file that is repeats of “You wanted to read it, guess what, you’ve got 20 Mb to go. You wanted to read it, guess what, you have 19.99 Mb to go. You wanted to read it, guess what, you have 19.98 Mb to go…” so encrypting it with “youturkey” is a feature ;-) Save the harder passwords for things you don’t want cracked ;-)

    (Though having a very tough password inside a box that says: “Congratulations! You got the hard password of: “$*$*(&#LKlkfakgfg944vcvfdasdfji889f398578hg96!@#$%^&773lfjdl jlj” Bet that took you a while. Go have a Starbucks and regroup. Next one is harder.” has a certain attraction to it ;-)

    But frankly, if someone wants to put that much effort into cracking my archive of PDF downloads and / or read my email saying “Why don’t we get together for lunch on Friday?” it’s not sweat off me. Least I can do is make it interesting for them ;-) My major goal is just to make a “Tallbloke and the Constable” moment an irritant to TPTB in the hope they might question the value of it. They can’t crack Truecrypt at that level, so it would end up being a “squeeze him to divulge the key” which is a great opportunity to be a News Hound and “raise awareness”… Folks can encrypt things for reasons OTHER than keeping them secret ;-)

  29. EM – a good use for a truly random sequence would be as another “encrypted” file. It would, after all, absorb a lot of effort to decrypt. I’m not quite sure what you’d tell them if legally forced to give the key, though.

  30. E.M.Smith says:


    Interesting point. It would likely be even more effective as a ‘not quite random’ file (so as to encourage continued cracking efforts) inside an easily cracked wrapper…

    Then again, I suppose one can do “all of the above”. A bag of “random”. A bag of randomly selected words, scrambled and encrypted (so the population count exactly matches English text, but the results are trash… I know that would drive me nuts… “But ‘E’ is showing up as the most common letter… but what’s a ‘frlegelersw’? And how can I unscramble that into a world?…” )

    You know, this expands into a whole host of new “distractors” methods… Sprinkle some whole words through the trash, so the ‘decrypt’ gives some valid words. Just enough to cause endless effort to get the rest… Hmmm….. Deliberately crafted decoy files designed not to taunt with ‘you idiot’ but to entice to endless cycles of attack…

    Per being forced to divulge the key: Well, you give it to them. When the Judge then demands you do better, you simply explain the technique and state that there is no more. After that, you countersue on continued harassment (and produce your notebook at the trial ;-)


    BTW, a pretty good intro to making random strings is here:

    with pointers to many of the details in RFCs et. al. A quick scan will show that the code can be pretty short given a hash algorithm in existence.

    So cranking out a bunch of random stuff is not very hard.

  31. Hugo M says:

    E.M., you said: “The phrase ‘how to break the chiffre if the plaintext actually is a true random sequence’ is nonsensical. It can either be a cypher, or it can be ‘truly random sequence’, but it can not be both. That is why I didn’t address it directly.”

    Sorry for not having been clear enough. It stilll can be both. As Simon indicated above, the idea behind is simply that one could make use of PK encryption (or any other suitable scheme) to encrypt a random sequence. The result may be transmitted somehow, and *may* later serve as an one-time pad for an else unrelated different message.
    My question is simply how a cryptanalyst could ever find the right key for an encrypted random sequence, since there shouldn’t be any predictable fragment in a truely random sequence — at least if the sequence was not compressed and does not eventually show signs of a solar heartbeat.

  32. E.M.Smith says:

    What you describe is using the random sequence as “salt” to the encryption. (The method is the encryption, the plaintext is what gets encrypted, the blended in ‘stuff’ that mutates the method is called ‘salt’.)

    In cryptography, a salt consists of random bits, creating one of the inputs to a one-way function. The other input is usually a password or passphrase. The output of the one-way function can be stored rather than the password, and still be used for authenticating users. The one-way function typically uses a cryptographic hash function. A salt can also be combined with a password by a key derivation function such as PBKDF2 to generate a key for use with a cipher or other cryptographic algorithm.

    In a typical usage for password authentication, the salt is stored along with the output of the one-way function, sometimes along with the number of iterations to be used in generating the output (for key stretching).

    Early Unix systems used a 12-bit salt, but modern implementations use larger lengths from 48 to 128 bits.

    Salt is closely related to the concept of nonce.

    The benefit provided by using a salted password is making a lookup table assisted dictionary attack against the stored values impractical, provided the salt is large enough. That is, an attacker would not be able to create a precomputed lookup table (i.e. a rainbow table) of hashed values (password + salt), because it would take too much space. A simple dictionary attack is still very possible, although much slower since it cannot be precomputed.

    Though you are looking at blending the salt with the plain text rather like “spice”:

    Encryption and decryption

    Each of the subciphers uses a different algorithm, but there are certain similarities. Three inputs are used to determine the ciphertext: the plaintext (in several 64-bit words plus one “fragment”), the spice (eight 64-bit words, with default value 0), and the key table. The operations within the cipher consist of “stirring”, in which internal variables are combined in various ways, with values from the key table and spice being included at regular intervals. HPC-Short uses two fixed permutations in addition, and HPC-Tiny consists of many special sub-cases.

    Though you have the burden of sending a ‘code book’ around carrying your more complex “spice”.

    How to attack it? I thought I already gave that list above?

    A partial list:

    1) Password Guessing. ( Dictionary attack, brute force, phishing, Human Factors attack, …)

    2) “Man in the MIddle”. (So you send your request to someone for their public key and it gets intercepted in the middle. That lets them compromise your code book exchange.)

    Suppose Alice wishes to communicate with Bob. Meanwhile, Mallory wishes to intercept the conversation to eavesdrop and possibly deliver a false message to Bob.

    First, Alice asks Bob for his public key. If Bob sends his public key to Alice, but Mallory is able to intercept it, a man-in-the-middle attack can begin. Mallory sends a forged message to Alice that claims to be from Bob, but instead includes Mallory’s public key.

    Alice, believing this public key to be Bob’s, encrypts her message with Mallory’s key and sends the enciphered message back to Bob. Mallory again intercepts, deciphers the message using her private key, possibly alters it if she wants, and re-enciphers it using the public key Bob originally sent to Alice. When Bob receives the newly enciphered message, he believes it came from Alice.

    3) Code book interception in general. ( So if you exchange it in person, it sits on a shelf, now your security depends on physical security at the end sites… usually not all that good.)

    4) Known text attack. (This depends on the ‘code book’ being of limited physical size. I.e. not a ‘one use’ pad. Send enough text that is ‘known’ and capture the results. Look for the ‘repeat’ to begin. This helped break Enigma as the Germans tended to end messages with “Heil Hitler”… Once this was noticed, the encryption could be attacked based on that known text.)

    More here:

    The need for a ‘code book exchange’ is a major problem and provides many opportunities to compromise. If used as a ‘one off pad’ then you have even more and frequent exchanges making contact tracing VERY easy (which also increases the risk of MITM and physical site compromises)

    Yes, the use of “salt” and “spice” (and other blendings of random stuff) make it harder to do a direct decryption attack of the cryptext; but unless they are hidden functions, the code book exchange drastically weakens the whole package.

    BTW, the “plaintext” can NEVER be a “truly random sequence” (unless sending random trash). By definition the “plaintext” is the message you are encrypting. The result is called the “cryptext”. So I think you meant to say “the cryptext is a truly random sequence”. Yet that is what is achieved in most systems today (just by other means). That’s what all the repeated application of hash functions is all about. The cryptext is functionally random on surface inspection (having been hashed, sometimes 64 times or more in a row…) but it can be reconstructed by running the process backward. Doing “population count” type attacks on a VPN tunnel or AES product is not productive. There’s just no pattern there to find. Instead you try to compromise the key exchange.

    Your advocacy of the randomizing ability of physical phenomenon has this major flaw: It is not a reversible function, so must have ‘code book’ exchange. Hash function methods are about the same degree of randomizing (and way more than needed) and do not require code book exchange. A huge amount of work went into eliminating the need for that code book exchange and public key encryption was the result. It is way stronger against real world attacks. (Though it, like the others, is subject to some way cool attacks – like ‘key sounds’. There are folks who can listen to the sound of the keyboard and mostly get right what keys are being pressed… Or key loggers or screen scrapers or… Public Key encryption is already good enough that those kinds of routes are cheaper in many cases. So someone really cares, they park a van down the street, point an antenna at your window, and pick up your screen directly along with your keystrokes. Who cares about what you do to encrypt it after that. And they can pick up the password entry. There’s more, but this is a bit long already…)

  33. E.M.Smith says:


    BTW, my “negativity” ought not be interpreted as slamming the idea. Blending in ‘random stuff’ is a valid and useful technique. Used as a part of a system, even the ‘code book exchange’ is an acceptable risk. Usually the random bit is shorter, but the technique is used in HTTP for example:

    In security engineering, nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. For instance, nonces are used in HTTP digest access authentication to calculate an MD5 digest of the password. The nonces are different each time the 401 authentication challenge response code is presented, thus making replay attacks virtually impossible.

    So it is a useful technique, just not particularly superior to Open Key and needs to be used where beneficial but not to the exclusion of other methods.

  34. Hugo M says:

    E.M., side channel attacks, man in the middle attacks, “social engineering”, physical theft, treachery or builtin backdoors are nothing new. All these methods also affect PK encryption schemes. I think confusion came in with my definition of “plaintext”. I used it in the sense that you can encrypt any stream of bits, being it some text, an image, a binary program or a truly random stream. In the latter case, assuming for a moment that the only information to the cryptanalyst is the encryption scheme and the encrypted message, my opinion still is that he can not break the key to get his hands on the random stream. Assume he finally performs a brute force attack. What will be his criterion that any of his results is the right one? Without being lucky by chance, he would need to decrypt the entangled second message trying all results of the first series of decryption attempts, and this should square the invested effort.

    However, at the end of the day the most interesting question is not about the content of the message itself, but to understand who communicates with whom.

  35. Pascvaks says:

    I guess we already have “Computer Finger Prints” and “Blood Types” and probably even “Genes” by now. So spooks know from a number of ‘little’ things entered with and between all the text letters and numbers (like a voice print?) who it is they’re ‘speaking to’? Well, maybe not with your average, everyday PC or cell phone (voice or text), but you know, all the James Bond stuff the Brits keep coming up with. Wonder what I ‘sound, look, smell, feel, and taste like’ in code?;-) If we can ID the device someone’s using, would think the next step is to ID the user too. (Just thinking, aka ‘daydreaming’;-)

  36. On cloud computing – looks like at least one of my worries is justified. tells the story of an Apple iCloud user who was locked out of his account by hackers.

  37. P.G. Sharrow says:

    @Simon, looks like we need our own cloud or maybe a “swamp” pg

  38. E.M.Smith says:


    One of my personal security measures is that I have 4 (major) computers. I swap between them on a semi-random basis. I NEVER connect them together (other than sporadically using the Linux R&D Box from the laptop when doing weather / climate analysis) and always have at least 2 of them turned off. My backups are on media that is not connected to anything or “offsite” in undesignated un-connected encrypted services. Passwords are NEVER stored ( yes, I type them every time).

    Any ONE machine is subject to compromise, but the collection is not. The phone is not connected to anything but the telco.

    Gluing everything together into one ball of mutual trust is just asking for it all to go POOF! in one ball of fire…

    Heck, I even disconnect the wireless link if I don’t need communications at that particular moment. (HP has a nice little button to do that ;-)

    I’d never use a ‘ball it all up in a cloud’ service. Then again, I also don’t do Facebook, Twitter, etc. etc….

    At a prior company the CFO was pushing me to use IP telephones so we could eliminate the phone switch costs. I pointed out two things:

    1) We already owned the phone switch.
    2) WHEN there were network problems, the phones still worked.

    Even if I were to put in an IP based phone system, I’d do it on duplicate gear. Don’t want some rogue computer virus downloaded from some web site to break your ability to make phone calls… especially to emergency services or support companies.

    “Way back when” I had a mantra: “One Service, One Server.” We used generic PC rack mount servers that were darned cheap for things like DHCP and Email and Web Server and… So when we had a “problem” with something (like if DHCP / DNS failed) we could just reboot the server and / or swap to a spare one. No notification needed (as no other services were on the box and that one was already not working) and no time delay.

    At that time, lots of folks where trying to cram as much stuff as possible on one big Windows Server. Anything glitched, the whole suite of services ‘had issues’.

    I have no idea why “the norm” is for folks to want to glue everything together into one insecure non-supportable ball of dreck, but they do….

  39. pg – There’s a Linux cloud I haven’t tried, and I’m pretty sure that IBM have a very private one. With any type of cloud, though, it’s asking to get hacked. Even the Swamp. EM’s techniques of obfuscation would be needed if we did run a Swamp, with encrypted (or not) files of truly random numbers scattered around to soak up the processing power of would-be hackers. (Must be pretty damned good encryption if we can’t decrypt it with a fortnight of Cray time….)

  40. P.G. Sharrow says:

    “Swamps” are nasty places. mosquitoes and alligators as well as mud. ;-) you can sure get lost in the swamp. Are we sure that the “Smithy” can keep us from getting lost? pg

  41. EM – here the only phone problem is that there is one line to the exchange. Orange give me an IP line that I don’t know the protocol of, but is free to phone around 100 other countries’ landlines but damned expensive to phone in on except from a similar line in France. I thus also have a Linksys PAP2T running SIP with a phone number in the UK – free for people in the UK to ring me and the line (from Connexin) is a one-off cost of £6 IIRC. Occasional problems with Orange messing it up, but it’s a two-line box and I’ve found that when that happens, switching to the other line puts things right again for a few months or more till next power-out. There’s also Skype – getting pretty unreliable over the last year (funny how it coincided with M$ takeover). There’s a mobile. Providing the line is physically there there’s POTS. Sounds complex, but isn’t and means that phone calls in or out are normally free. Emergency services use POTS anyway, even on a SIP setup. On mobile, they are normally free, too.

    I think the tarballing together of a lot of functions into one server-box dates from when processors were expensive, so you tried to get the maximum utility out of the investment. For a long time now, though, enough processing power to do these jobs has been very cheap, so reducing the complexities of the OS to just running one application means that you actually need less processing power since the OS becomes a low overhead. The problems are also so much easier to isolate – no cross-talk between processes. Mostly I think the current idea of a box doing everything is that it’s customer-friendly – less power-sockets needed and less connections between boxes. They might have a point for home use. When you want reliability and ease of fixing, go for separate boxes/processors. Murphy’s Law always prevails.

  42. P.G. Sharrow says:

    Back in the “good old days” we used numbers of cheap small tractors and operators to get the job done. Then the latest and greatest was to replace them with one large expensive tractor and operator for greater efficiency. One small problem, If that tractor broke down or the operator got drunk you were out of business until everything was put right. Many old small tractors and their operators were a pain in the rear to manage but the lose of one was no big thing and a special setup was easy to create and of little cost.
    Computers are so cheap and plentiful now that specializations are no big thing. A big general purpose box that does everything is no longer needed. pg

  43. pg – you’re looking from an engineer’s viewpoint (makes sense to me, too). Normal people don’t know and mostly don’t want to know what goes on inside the box, so getting one box that does everything looks neater, is less work to dust/polish, and less complex to wire in. If it goes wrong, either they get someone else to fix it (Somebody Else’s Problem again), or they’ll sue, or they’ll get a new one that brings in other functions that they have been persuaded that they want. I expect my boxes to mast years – my daughter wants a new phone each year as they get outdated so quickly (it hardly has time to go badly wrong).

  44. Pascvaks says:

    Maybe related?
    a. Is anyone making ‘Custom Computers’? Example: the MiniVan craze of days gone by, where a van from Detroit was taken to Podunk, and stripped down and rebuilt and ‘customized’ into something special and kinda painted uniquely. (Limited market sure but would think someone’s out there doing it, not everyone is as talented as yuz guys;-)
    b. Related, is anyone yet tweeking and debugging (customizing;-) and certifying off the shelf computers? Example: taking “EZ-99Whatevers” and doing a thorough checkout of hardware, and especially software, and giving the Good Computing Seal of Approval when done? Let’s say you go to Walmart and buy something off the shelf, take it to the local Geek, s/he does a hardware and software inspection, calls you up and says “you’ve got X, Y, Z issues; I can dump the X’s for $25, disconnect the Y’s for $13.75, and make a minor program addition/deletion to your Z’s that will cost you $30; it’ll be ready for pick up tomorrow at noon; and don’t forget you have the 12 month warranty from UnderwritersDebugging.”

    If the latest version of anything is a mystery box, there’s gotta be a market for all the paraniod folks like me that don’t trust Microsoft or HP or some Chinese guy or Indian girl that had their hands on something I’m going to bring into my home and let watch and listen and whateverelse me for the rest of my life after I plug it in. I mean there’s more to life than encryption, right?;-)

    PS: And if the Geek that told me he fixed it can’t be trusted, who can you trust? (Besides, if something bad does happen, at least I have the name and face of a real human being to hate and curse for the rest of my life in Siberia;-)

  45. Pascvaks – For a long time such customising has been available to geeks and would-be-geeks. Buy all the parts as separate items and build it yourself. There are magazines (periodicals in American?) that cater to this market, and I see them for sale in newsagents in the UK and France – probably all over Europe. Have a look in your local newsagent and see what’s available.

    Local computer-shops have used these parts to produce their own-brand (no-name) computers, too. Some even come with Linux pre-installed. I bought my (mainstream) MSI Wind U90 netbook with SUSE10 installed as a factory-option. Since SUSE was a bit limited, I installed Ubuntu, but at least all the drivers were available and tested. No problems.

    In engineering terms, the less you let the general public fiddle with what’s inside the box, the fewer your returns will be – people with not-enough-knowledge who Think They Can cause a lot of problems. People with a reputation to uphold (such as Apple) will therefore make the whole thing hard to even take to bits without special tools, and limit what can be installed/run.

    There’s a high probability your local geek, especially if long-term resident or born there, will be reliable, but as with anything else there will be exceptions. A local (non-chain-store) computer shop will be run by a geek more often than not, and possibly even chain-stores will employ them. People who enjoy the job will work for less money.

    As a last point, don’t expect that it will work “the rest of your life” unless you intend suicide when it fails. Technology changes so damned quickly, so standards change too. If you’ve just upgraded to a new plasma screen do-everything TV and then they start transmitting 3D pictures, the TV will still be fine, just not the latest. Round here and in the UK, analogue TV has just been turned off – digital box or nothing.

  46. E.M.Smith says:


    They are called “White Box PCs” for the ones used industrially. I’ve “built up” a few in my life. The local “geek shop” started as a grocery store that added tech stuff for geeks up at midnight needing a snack and evolved into a tech store selling everything a geek would need along with a heavy snacks department. ;-)

    You can buy all the parts to build your own from scratch. Nice wall display of motherboards too. I’ve done it. You can get the cheap generic “white box” to put things in, or you can buy ‘way cool’ custom cases with fluorescent colors and / or built in decorative lights. Hard Core Gamers will often juice their box with things like special cooling systems and overclocking. It’s remarkably similar to folks hotrodding engines in cars… only geekier ;-)

    These folks will custom build one for you:

    Major vendors, like Dell and HP, do a LOT of testing and integration work to assure nobody is sticking anything evil into their hardware. The weak spot is software “updates” after the product ships and whatever weaknesses MicroSoft has built in from the beginning. That’s why so many folks run Linux of various flavors or BSD Unix for industrial strength servers. (Solaris made a good living off that space for a long time too; now that it’s part of Oracle, who knows… but probably still good.)

    At some point you have to trust someone. Was the BIOS buggered? Highly unlikely (though there have been occasional ‘bugs’ that were ‘odd’…). Is the CPU firmware buggered? Almost certainly not. Too many ways that could show up / be caught. Is the hard disk controller chip buggered? Almost certainly not ( hard to get enough ‘smarts’ into it to communicate out through an unknown higher level environment). You go down the list and it is pretty much clear that the weakness is in the Operating System and the applications layered on top of it. Microsoft, Google, Flash and such.

    FWIW, Apple has historically been WAY more concerned about ‘exploits’ than Microsoft. While there are a few things that have shown up as security exploits, the level of risk is dramatically lower. If you are really worried, get a Mac. Paranoid folks controlling the whole package from parts to OS to final ship… Personally, I found it a bit too paranoid. Hard to become “root” and manage the box myself. So I like Linux as “not as functional and more open to me screwing around” ;-)

  47. E.M.Smith says:

    Well that’s a bummer…

    has an interesting “exploit” of firewire and thunderbolt to break into Macs (and other computers with those interfaces) and extract encryption / password keys…

    Yes, it takes “physical access”, but it is still an issue. As various Governments are now doing ‘copy and examine’ of laptops at airports, it’s a way for, say, the Chinese to grab a copy of just about anything they want from your machine if, say, you left it in ‘sleep’ mode (even if password protected) rather than encrypted and shutdown…

    Interesting side bar is the potential to use a small single board computer as the agent to do the breaking. So while I’m looking at making an SBC Disposable / Secure communications and browsing platform, they are looking to use on for the ‘hack’ device.


    Looks like one “check point” is just to assure that MY SBC device doesn’t do Firewire / Thunderbolt… or any other DMA capable data transfer.

    Also of note:

    Seems that some TLAs and police are now showing up with a bucket of liquid nitrogen to preserve your ‘volatile’ memory (or perhaps it is mostly a theoretical?) for key extraction.

    So pulling the plug is not not enough. ( But pulling the plug then repowering / rebooting might be…) so a USB powered device with a battery in the loop is a nice to have. Blink power and assure the POST includes a memory test. If YOUR power gets cut, you blink power from the battery and let the POST (power on self test) proceed to wipe memory while answering “the nice men at the door with guns”…

    Some other folks are looking at doing encryption with the keys NOT in RAM, but only kept in cache:

    ( I think I’d rather go with the crash / wipe battery in the USB process… or maybe both ;-)


    It was so much easier to make secure machines back when they didn’t have much networking and “ports” ;-)

  48. EM – since shut-down is software-controlled, you could also add a routine to the BIOS that overwrites memory at shut-down as well as on start-up. Memory tests take at least twice as long as writes, after all. If the power is interrupted, then it doesn’t immediately go down. Probably enough time after the failure-signal to do a fair amount of overwrite if not all of it, and if not then add a bigger power-supply capacitor to give the extra time. A mis-write will probably be just as good as a correct one, after all. If the memory-write could write a random sequence, that’s good, but it takes longer.

    Seems you’d have to add overwrite of the processor cache memory, too – I’m not certain whether that is actually accessible to even BIOS programs. As such, run a dummy program that’s big enough to fill it at least twice.

    Cooling RAM will preserve the last data-state to some degree – it depends just how long it’s been switched off and thus how far the cell voltages will have decayed to random readings. Even then the ECC algorithm could probably resurrect quite a lot of it. Since I remember looking at DRAM memory dumps after a switch-off/reboot cycle, in the days when DRAM was specified as a 2ms refresh time before you lost data, and a lot of the data was still readable, I’d say that the cryogenic freezing within a few minutes would probably work as a forensic technique.

  49. Pascvaks says:

    I don’t speak the lingo or understand a lot of what is being said but from left field here goes nuttin: Would having you own Personal Emergency Virus help with any of this airport security,etc., stuff? If someone breaks in to copy, or whatever, would a Security Virus be any good?

  50. Hugo M says:

    There is a new attack on TLS in the offing, said to be based on a research work on “Compression and Information Leakage of Plaintext”, published in 2002 …

    Our results are as follows:

    1. Commonly-used lossless compression algorithms leak information about the data being compressed, in the size of the compressor output. While this would seem like a very small information leak, it can be exploited in surprisingly powerful ways, by exploiting the ability of many compression algorithms to adapt to the statistics of their previously-processed input data.

  51. Hugo M says:

    Yet another little problem with public key cryptography, this time related to insufficient entropy:

    RSA and DSA can fail catastrophically when used with malfunctioning random number generators, but the extent to which these problems arise in practice has never been comprehensively studied at Internet scale. We perform the largest ever network survey of TLS and SSH servers and present evidence that vulnerable keys are surprisingly widespread. We find that 0.75% of TLS certificates share keys due to insufficient entropy during key generation, and we suspect that another 1.70% come from the same faulty implementations and may be susceptible to compromise. Even more alarmingly, we are able to obtain RSA private keys for 0.50% of TLS hosts and 0.03% of SSH hosts, because their public keys shared nontrivial common factors due to entropy problems, and DSA private keys for 1.03% of SSH hosts, because of insufficient signature randomness. We cluster and investigate the vulnerable hosts, finding that the vast majority appear to be headless or embedded devices. In experiments with three software components commonly used by these devices, we are able to reproduce the vulnerabilities and identify specific software behaviors that induce them, including a boot-time entropy hole in the Linux random number generator. Finally, we suggest defenses and draw lessons for developers, users, and the security community.

  52. E.M.Smith says:


    Overwrite on powerdown would be nice, but I don’t thing you need the bios to do it. Just sense power out in the OS and start writing. Capacitors are cheap ;-)


    Interesting idea. Could likely do something with it. Put a virulent virus in a chunk of memory you ‘never access’ then the forensics guy accesses it… Hmmmm ;-)

    @Hugo M:

    Yup. Using the tool wrongly has always been a weakness. Even Enigma was party broken from folks using it wrongly. (One guy always set the password to his girlfriends name and lots of messages always ended with Heil Hitler IIRC)

    So that they only got fractional percentages from such weaknesses is surprisingly low to me..

    FWIW, that’s why when setting up encrypted links you set the key exchange rate modestly high. So very shortly any weakness from start state gets washed out. Not everybody does that though…

    The “size” issue is part of why I like to put random garbage in folders and com links…

  53. adolfogiurfa says:

    The best encryption? ANALOG systems, write an old fashion written letter and send it by mail. Wow!, that would be indecipherable !

  54. Hugo M says:

    E.M., constantly updating keys does not help against those who are on your line right from beginning if the first key was weak. Regarding Enigma, there weren’t exactly passwords, but centrally ordered rotor types and rotor setting instructions dependend on date. Hence the guy-who-used-his-girlfriend’s-name-as-password story isn’t very credible. The partially known plaintext due to formal parts of the transmitted messages was counteracted by additionally using code books, which were printed on water-soluble material and changed at regular intervals. When assaulting a German submarine, the Brits succeeded in getting a code book from a submarine together with actual rotor codes, and thusly broke in to a part of the German communication for some time.

  55. E.M.Smith says:


    Unless opened… There’s a long history of snooping into snail-mail… it isn’t encrypted… and very easily intercepted if someone is looking into “your stuff”. Though, oddly, using an obscure language and writing it in more obscure letters can be very effective. So, for example, writing Spanish in Futark letters would likely baffle most folks… Put that in ‘mirror writing’ so the letters are read backwards (or alternate on each row) and use a mix of, say, Greek words scattered in Spanish with archaic syntax and I doubt one person in 10 Million could figure it out.

    Many old Celtic inscriptions can not be deciphered because they are in a ‘hidden writing’ form. We know they had a few dozen forms of secret writing and still have not figured them all out.

    But just ‘clear text in an envelope’ is very easy to intercept and copy / read / snoop. Been done for generations…

    @Hugo M.

    You seem to have a Hobby Horse to ride that common encryption is lousy. Go ahead and ride it.

    It is way more strong than just about anything that has ever gone before.
    With any reasonable care in the set up, it is so strong that nobody with less than $Billions to blow can break it.
    It is far beyond overkill for most all practical purposes.
    Many forms are functionally unbreakable no matter WHO you are.
    TRIVIAL actions can make if unbreakable even if someone has complete access to “your line”.

    But no, it is not absolutely perfect completely secure at all times and against all attacks for all future time no matter how stupidly you set up the system with NO information leakage at all.

    One example of the “trivial” acts: Encrypt a file offline with a strong encryption. Open a “line” to someone else with “weaker” encryption and exchange the file. Use what is in the file to set your new key…

    BTW, using public key encryption for the “line” means that someone can be on it from the start and they still get squat…

    I don’t really care if after I’m dead someone can break the encryption (say in 100 years) and find out that I was asking my family for birthday present suggestions.

    I don’t really care if some TLA wants to spend $Billions trying to find out I’m speculating about how to make a nuke from Thorium without isotopic separation ( I think I know how, BTW, but I could be wrong) for the simple reason that, at that point, I’m more likely to wake up in an “undisclosed location” with a pentothal IV drip…

    The fundamental property needed from encryption is “good enough for purpose” now.

    We don’t use 2,000,000,000 character keys or passwords, even though they are clearly and demonstrably vastly superior. We use keys and passwords that are computationally ‘big enough’ to prevent attack in the next couple of decades. Not more. For convenience and because it’s “fit for purpose” (i.e. ‘good enough’).

    In short, encryption is always a race condition and you only need to be ‘good enough’ to force the attack onto an alternate path. (And hopefully NOT good enough to put it on the “gun to the head” path…)

    But go ahead and search for the Perfect Unbreakable Encryption and toss rocks anything less than that. It’s a fun hobby…

Comments are closed.