5333 private links
Craig Wright, an Australian computer scientist who claims to be Satoshi Nakamoto, the inventor of Bitcoin, has been cleared of six out of seven civil charges during a trial in a Miami court on Dec. 7 that put him up against the estate of his deceased business partner.
Trial and claims: The plaintiff of the civil court case declared that Wright and David Kleiman, a computer forensics expert and Wright’s friend, pre-mined 1.1 million bitcoin together (worth $54 billion), fueling an argument over whether Wright owed half of his assets to Kleiman’s family.
A hacker stole $31 million from the blockchain company MonoX Finance, by exploiting a bug in software the service uses to draft smart contracts.
The article goes on to talk about how common these sorts of attacks are. The basic problem is that the code is the ultimate authority — there is no adjudication protocol — so if there’s a vulnerability in the code, there is no recourse. And, of course, there are lots of vulnerabilities in code.
To me, this is reason enough never to use smart contracts for anything important. Human-based adjudication systems are not useless pre-Internet human baggage, they’re vital.
A secure disk wipe tool based on VeraCrypt encryption engine.
Release archives are signed using PGP key with fingerprint 607E5A7AD030D38E5E5C2CA502C30AE90FAE4A6F belonging to Mounir IDRASSI and which can be found on major key servers
Features
- Securely wipe disks and partition of all types (HD, SSD, Flash, SD Card)
- Disk content is overwritten using random data generated using well-established VeraCrypt encryption engine
- Wiping full disk erases all its partitions making the disk raw
On December 10th 2020, Germany's Federal Office for Information Security (BSI) published the English report of a security evaluation of VeraCrypt that they ordered from the Fraunhofer Institute for Secure Information Technology (SIT).
The report can be found at the following URL: https://www.bsi.bund.de/DE/Publikationen/Studien/VeraCrypt/veracrypt.html
I have also attached the PDF of the report to this post in case URL changes in the future.
Before the publication of this report, the SIT team responsible of the security evaluation reached out to us and we had exchanges about their findings. I shared my feedback and I also implemented changes in 1.24-Update7 based on their findings.
In my opinion, this evaluation is the most comprehensive one that have been published so far about VeraCrypt, spanning over a year and analyzing all aspects of the project and the source code. Their findings are helpful and VeraCrypt development will benefit from them.
CertEncryptor is a Windows application that enables encrypting and decrypting files using existing digital certificates.
The encryption uses AES 256-bit and the data is encrypted following the Cryptographic Message Syntax (CMS) standard. It allows encrypting files for an unlimited numbers of recipients, each recipient being identified by a standard X509 digital certificate (either RSA or Elliptic Curve). File decryption requires the presence of the private key associated with one of the certificates used for the encryption.
The maximum file size allowed by this tool is 100 MB per file.
IDRIX is proud to share with the Cryptography and Security community some of its internal tools. These tools proved to be very useful in our internal development process and we are sure that they will do the same with others. Of course, they can be used freely without any license but they come with no warranty attached.
Enigma2Illusion - 2021-05-19
I think people tend to forget that Mounir as a fulltime job, family obligations and the data center fire that impacted his livelihood and the VeraCrypt project.
I think people should consider how much time it takes to work on VeraCrypt for three OS's including the various Linux variants.
Mounir Idrassi handling the many features of VeraCrypt across three OS platforms (Linux, Mac, Windows) by performing development, testing, bug fixes and releasing software during his free personal time after working a fulltime job and family commitments for little to no monetary compensation. Just to compile and perform a release takes two days for a release of the three OSs.
Beta software is released to the VeraCrypt community with the hope that users are willing to test new upcoming versions to find issues before the next version is released since it is impossible for the developer to have test machines from the various PC makers, various Windows, Linux, Mac OS versions and various disk partitioning configurations for testing.
Hence, the developer relies on the VeraCrypt user community to help test the beta releases.
As with many Open Source projects, the developers rely on the user community to help each other with issues due to the overwhelming requests for assistance.
TL:DR
Each VeraCrypt user should consider how much work effort is involved on an Open Source project supporting three OSs and their various versions for little financial gain by performing development, testing, bug fixes and releasing software during their free time after meeting their obligations of fulltime job and family obligations. Not to mention some VeraCrypt users feeling entitled to have their support issues and/or features worked on immediately. :)
EDS (Encrypted Data Store) is a virtual disk encryption software for Android which allows you to store your files in an encrypted container. VeraCrypt(R), TrueCrypt(R), LUKS, EncFs, CyberSafe(R) container types are supported. The program can operate in two modes: non-mounted and mounted.
We’re incredibly excited to launch Element One!
It’s a complete messaging package - the Element app with high-performance hosting, the entire Matrix universe and bridging to WhatsApp, Signal and Telegram. All for just $5 per month. //
Element One is the quickest and easiest way to get unlimited bridging to WhatsApp, Signal and Telegram.
Just sign up from the Element website.
https://ems.element.io/element-one //
It’s also worth noting that end-to-end encryption is necessarily broken as messages to (and from) WhatsApp, Signal and Telegram pass across the bridge(s). The bridge(s) operates in Element’s trusted EMS environment, with no content scanning or datamining, but currently bridged conversations are not stored end-to-end encrypted in Matrix (they will be in the future).
One thing that ultimately allowed the impact of this event to be greatly reduced is that Android devices do not check the expiration date of the Root CA Certificate when establishing trust in the certificate chain... This means that it is still possible to anchor on the expired IdenTrust Root CA, and those Android devices would work, //
The 'New Default Chain' still ultimately anchors on the IdenTrust Root CA, meaning compatibility with Android devices that won't check the expiration date, but it passes through the new Let's Encrypt ISRG Root X1 CA which more modern clients will have in their trust store. This means those modern clients will stop the chain there and accept it as trusted too. Win-win. //
One interesting side effect of this though is that you can then modify the Root Certificates in the trust store and because no signature validation is taking place, meaning no integrity check is taking place, the modified Root Certificate will be treated as perfectly valid. This is the part that I'd never thought about. //
When first thinking about this issue, I felt a little bit like I did when I first found out, all those years ago, about signatures not being validated on roots and how that seemed ridiculous. Once you think about this more though, you realise that it does make sense and that it just doesn't seem logical upon first thought. In order to make this change and it actually have an effect on the client, you need to have access to that client with administrative privileges to change the root store. If your concern is that an attacker might do something like this, well, I'd suggest you have far bigger issues to concern yourself with given that the attacker has admin/root and is on your device!
NIST Randomness Beacon (Version 2.0 Beta) -- work in progress
WARNING: DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.
An overview of this project can be found at: https://csrc.nist.gov/projects/interoperable-randomness-beacons
This prototype implementation generates full-entropy bit-strings and posts them in blocks of 512 bits every 60 seconds. Each such value is sequence-numbered, time-stamped and signed, and includes the hash of the previous value to chain the sequence of values together and prevent even the source to retroactively change an output package without being detected.
A selection of currently implemented calls are listed below. Users submitting a request need to provide the pulse generation time in POSIX format (number of milliseconds since midnight UTC, January 1, 1970 (see http://en.wikipedia.org/wiki/Unix_time for more information and http://www.epochconverter.com for an online time converter.)
Opinion: Cryptocurrencies are useless. Blockchain solutions are frequently much worse than the systems they replace. Here's why. //
In his 2008 white paper that first proposed bitcoin, the anonymous Satoshi Nakamoto concluded with: “We have proposed a system for electronic transactions without relying on trust.” He was referring to blockchain, the system behind bitcoin cryptocurrency. The circumvention of trust is a great promise, but it’s just not true. Yes, bitcoin eliminates certain trusted intermediaries that are inherent in other payment systems like credit cards. But you still have to trust bitcoin—and everything about it. //
By blockchain, I mean something very specific: the data structures and protocols that make up a public blockchain. These have three essential elements. The first is a distributed (as in multiple copies) but centralized (as in there’s only one) ledger, which is a way of recording what happened and in what order. This ledger is public, meaning that anyone can read it, and immutable, meaning that no one can change what happened in the past.
The second element is the consensus algorithm, which is a way to ensure all the copies of the ledger are the same. This is generally called mining; a critical part of the system is that anyone can participate. It is also distributed, meaning that you don’t have to trust any particular node in the consensus network. It can also be extremely expensive, both in data storage and in the energy required to maintain it. Bitcoin has the most expensive consensus algorithm the world has ever seen, by far.
Finally, the third element is the currency. This is some sort of digital token that has value and is publicly traded. Currency is a necessary element of a blockchain to align the incentives of everyone involved. Transactions involving these tokens are stored on the ledger. //
Most blockchain enthusiasts have a unnaturally narrow definition of trust. They’re fond of catchphrases like “in code we trust,” “in math we trust,” and “in crypto we trust.” This is trust as verification. But verification isn’t the same as trust. //
What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they’re often single points of failure.
When that trust turns out to be misplaced, there is no recourse. If your bitcoin exchange gets hacked, you lose all of your money. If your bitcoin wallet gets hacked, you lose all of your money. If you forget your login credentials, you lose all of your money. If there’s a bug in the code of your smart contract, you lose all of your money. If someone successfully hacks the blockchain security, you lose all of your money. In many ways, trusting technology is harder than trusting people. Would you rather trust a human legal system or the details of some computer code you don’t have the expertise to audit? //
Any blockchain system will have to coexist with other, more conventional systems. Modern banking, for example, is designed to be reversible. Bitcoin is not. That makes it hard to make the two compatible, and the result is often an insecurity. //
To the extent that people don’t use bitcoin, it’s because they don’t trust bitcoin. That has nothing to do with the cryptography or the protocols. In fact, a system where you can lose your life savings if you forget your key or download a piece of malware is not particularly trustworthy. No amount of explaining how SHA-256 works to prevent double-spending will fix that. //
A false trust in blockchain can itself be a security risk. The inefficiencies, especially in scaling, are probably not worth it. I have looked at many blockchain applications, and all of them could achieve the same security properties without using a blockchain—of course, then they wouldn’t have the cool name.
Honestly, cryptocurrencies are useless. They're only used by speculators looking for quick riches, people who don't like government-backed currencies, and criminals who want a black-market way to exchange money.
To answer the question of whether the blockchain is needed, ask yourself: Does the blockchain change the system of trust in any meaningful way, or just shift it around? Does it just try to replace trust with verification? Does it strengthen existing trust relationships, or try to go against them? How can trust be abused in the new system, and is this better or worse than the potential abuses in the old system? And lastly: What would your system look like if you didn’t use blockchain at all?
Clive Robinson • September 3, 2021 6:14 PM
@ ALL,
“In fact, it was arguably the most secure rotor machine ever built.”
Probably not the most secure rotor machine ever built, but probably the most secure rotor machine ever put into production even if for a very very small number (The British / Canadian Rockex was after TEMPEST issues were sorted out more secure than any rotor cipher machine ever envisaged and would still be secure today).
Some have heard of the US SIGABA / ECM II Cipher Machine[1] it had some interesting features including the way stepping was done. Because of this it was considered unbreakable at the time (but is breakable today).
One feature that the US thought was unknown to others was the ability to make wheels step not just forwards but backwards as well as not rotate at all etc.
The British had a problem the stalwart Typex was long over due for a full replacment. Unfortunately the British did not have the mechanical manufacturing capability at the time[2]. It was hoped that under the BRUSA arangment, the British could use either the US SIGABA or get parts manufactured secretly in the US.
As normal the “Special Relationship” rapidly hit the rocks. The US did not want the secret of the rotor wheel steping to be known to the British so the use of SIGABA was vetoed. The resulting cludge to enable a Typex and SIGABA to inter opperate evolved and became the CCM.
So one of the greatest brains at Bletchly Gordon Welchman was called upon to design an unbreakable and future proof rotor system which he went ahead and did.
The US did not want it built, they would not be able to eves drop on it and much backwards and forwards happened. As part of it the Brirish revealed their secret of independent rotor steping that would not just do all the US had tried to keep hidden but a few tricks more (lets be honest folks such rotor behaviour is kind of obvious and it turned up in other places).
What killed Welchman’s machine in the end was the US Navy that adamantly refused under any circumstances to have it aboard their ships… Thus as a more secure replacment for the CCM it was not to be, thus it was as far as British Civil Servants were concerned pointless continuing with it’s development.
It was without doubt a beast and yes it is doubtful that it’s reliability would have been good enough.
[2] Lack of mechanical manufacturing was one of the reasons the British designed the Rockex system that used Post Office relays valve/tube electronics using standard parts and standard teleprinter readers and punches. Another issue was that the US were pushing a voice scrambler X-Ray at the British on the notion it was easy to use. However those “in the know” were not just deeply suspicious they were fairly certain that the US would be able to evesdrop on the system. So bad was the situation that Churchill who was Prime Minister had to personally authorise which system should be used abd Rockex got the nod of approval because Churchill did not trust the US in the slightest at that time.
Der Firmensitz der ehemaligen Crypto AG im zugerischen Steinhausen produzierte jahrzehntelang Chiffriermaschinen. Der deutsche Auslandsnachrichtendienst BND und die US-amerikanische CIA kauften das Unternehmen 1970 heimlich auf. Sie veranlassten, dass vielen Staaten Maschinen mit einer schwächeren Verschlüsselung geliefert wurden, die von BND und CIA entschlüsselt werden konnten. Zuletzt war dort das Nachfolgeunternehmen Crypto International AG ansässig.
Rotor-based cipher machine - wanted item
HX-63 was an electromechanical rotor-based cipher machine, introduced in 1964 by Crypto AG in Zug (Switzerland). It features nine electrically wired permutations wheels, or rotors, that have more contacts than the 26 letters of the alphabet. It was patented by Boris Hagelin, and uses an operating principle that is very similar to that of the – also patented – American AFSAM-7 (KL-7).
The image on the right shows the HX-63, which is housed in a molded plastic enclosure. At the front right is the keyboard. The 9 cipher wheels are visible through a narrow window at the top.
The machine was developed during the 1950s, and is mentioned in reports filed by NSA cryptographer William Friedman in 1955 and again in 1957 [2]. It is likely though, that it was not finished before 1963, and that it was first sold in 1964 [A]. The first and only customer was the French Army, who ordered 12 units [4]. It is very likely that no more than 15 init were ever made.
Apart from the TKG-35, a joint development of Boris Hagelin and Dr. Edgar Gretener, the HX-63 was first and only rotor-based cipher machine that was ever built by Crypto AG. Around 1964, Crypto AG made the transition to electronic shift-register-based designs, and moved away from (electro)mechanical cipher machines. In 1970, the HX-63 was succeeded by the electronic H-460.
How this gadget figured in the shady Rubicon spy case //
In 1976, during a visit to the Polish Army Museum in Warsaw, I saw an Enigma, the famous German World War II cipher machine. I was fascinated. Some years later, I had the good fortune of visiting the huge headquarters of the cipher machine company Crypto AG (CAG), in Steinhausen, Switzerland, and befriending a high-level cryptographer there. My friend gave me an internal history of the company written by its founder, Boris Hagelin. It mentioned a 1963 cipher machine, the HX-63.
Like the Enigma, the HX-63 was an electromechanical cipher system known as a rotor machine. It was the only electromechanical rotor machine ever built by CAG, and it was much more advanced and secure than even the famous Enigmas. In fact, it was arguably the most secure rotor machine ever built. I longed to get my hands on one, but I doubted I ever would. //
Most professional cryptographers have never heard of it. Yet it was so secure that its invention alarmed William Friedman, one of the greatest cryptanalysts ever and, in the early 1950s, the first chief cryptologist of the U.S. National Security Agency (NSA). After reading a 1957 Hagelin patent (more on that later), Friedman realized that the HX-63, then under development, was, if anything, more secure than the NSA's own KL-7, then considered unbreakable. During the Cold War, the NSA built thousands of KL-7s, which were used by every U.S. military, diplomatic, and intelligence agency from 1952 to 1968.
The reasons for Friedman's anxiety are easy enough to understand. The HX-63 had about 10^600 possible key combinations; in modern terms, that's equivalent to a 2,000-bit binary key. For comparison, the Advanced Encryption Standard, which is used today to protect sensitive information in government, banking, and many other sectors, typically uses a 128- or a 256-bit key.
Boris Casear Wilhelm Hagelin (2 July 1892 - 7 September 1983) was a Russia-born Swedish engineer, inventor of cipher machines and businessman. He developed his first cipher machine in 1925, as a colleague of Arvid Gerhard Damm at A.B. Cryptograph in Stockholm (Sweden), of which his father, Karl Wilhelm Hagelin, and the Nobel family were investors. Hagelin eventually founded one of the largest and most successful manufacturers of cipher machines — Crypto AG.
The HX-63 cipher machine is an electromechanical, rotor-based system designed and built by Crypto AG. The machine uses nine rotors [center right] to encrypt messages. A dual paper-tape printer is at the upper left. //
Growing up in New York City, I always wanted to be a spy. But when I graduated from college in January 1968, the Cold War and Vietnam War were raging, and spying seemed like a risky career choice. So I became an electrical engineer, working on real-time spectrum analyzers for a U.S. defense contractor.
In 1976, during a visit to the Polish Army Museum in Warsaw, I saw an Enigma, the famous German World War II cipher machine. I was fascinated. Some years later, I had the good fortune of visiting the huge headquarters of the cipher machine company Crypto AG (CAG), in Steinhausen, Switzerland, and befriending a high-level cryptographer there. My friend gave me an internal history of the company written by its founder, Boris Hagelin. It mentioned a 1963 cipher machine, the HX-63.
Sometimes, locking down a laptop with the latest defenses isn't enough. ///
Typing in a password is still better than relying entirely on credentials stored in TPM.
verify that the user’s VeraCrypt installation is not configured to encrypt keys and passwords stored in RAM. To check this option, open VeraCrypt Settings – Preferences – More settings – Performance/Driver configuration and check if the Activate encryption of keys and passwords stored in the RAM box is selected.
If this option is selected, EFDD will be unable to locate the encryption keys. Note that disabling this setting requires a reboot, so the point of this action is lost as the encrypted container will be locked/unmounted after the reboot.
What is RAM encryption?
According to Mounir IDRASSI, “RAM encryption mechanism serves two purposes: add a protection against cold boot attacks and add an obfuscation layer to make it much more difficult to recover encryption master keys from memory dumps , either live dumps or offline dumps (without it, locating and extracting master keys from memory dumps is relatively easy).” (We strongly recommend reading Mounir’s entire post as it contains important details on how this protection is implemented).
Known limitations
As you already know, breaking VeraCrypt is extremely complex. VeraCrypt presents one of the strongest encryption options we have encountered. Even a thousand computers or a network of powerful Amazon EC1 instances with top GPUs may spend years if not hundreds of years to break a strong password. Extracting and using OTFE keys remains one of the few usable method to break in to encrypted containers. Yet, this method has a number of limitations.
One of the most restricting limitations is the requirement to obtain physical access to the computer during the time a VeraCrypt disk is mounted: only in that case the encryption keys are available in RAM. That computer must not be locked, and the authenticated user session must have administrator’s privileges (you need them to obtain the memory dump). Finally, the memory encryption option in VeraCrypt must not be used. On the bright side, the choice of encryption and hashing algorithms does not matter, as well as the PIM number.