Live Webinar and Q&A – What Does The JVM Garbage Collector Really Do? (Live Webinar Oct 21st, 2021) Save Your Seat
Facilitating the spread of knowledge and innovation in professional software development
In this article, we’ll explore the benefits of using blockchain for business solutions, describing the differences between public and private versions of this technology in practice. We’ll also talk about a new type of chain — a hybrid of private and public chains which takes the benefits of both to create a truly versatile platform with no compromises.
Using the metaphor of lego blocks, Lin Clark (a Senior Principal Software Engineer at Fastly) discusses WebAssembly Component model with Wes Reisz, including the background, roadmap, and design goals. Today on the podcast, Lin and Wes talk web assembly and the work happening around developing the component model.
In this second edition of the Modern Data Engineering eMag, we’ll explore the ways in which data engineering has changed in the last few years. Data engineering has now become key to the success of products and companies. And new requirements breed new solutions.
In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Sam McAfee about helping technologists move from being individual contributors to leaders of teams.
Sergey Fedorov discusses how to build the Internet latency map, using network protocols and edge infrastructure, and how to use a data-driven approach to evolve your client-server interactions.
Learn how to apply Microservices and DevSecOps to improve application security & deployment speed. Virtual Event on Oct 19th, 9AM EDT/ 3PM CEST
Turn advice from 64+ world-class professionals into immediate action items. Attend online on Nov 1-12.
Learn from practitioners driving innovation and change in software. Attend in-person on April 4-6, 2022.
InfoQ Homepage Articles Post-Quantum: Bi-Symmetric Hybrid Encryption System
Oct 05, 2021 24 min read
CEW Systems’ Bi-Symmetric Hybrid Encryption System provides a novel approach to post-quantum encryption that has been specifically designed to be immune to a variety of attacks.
The Bi-Symmetric Encryption software was evaluated using credit card purchasing, e-commerce and banking application examples. In addition, Bi-Symmetric Encryption was designed for many additional uses and applications, including embedment into electronics and radio-based communication technologies including remote keyless entry (car FOBs). Bi-Symmetric Encryption was designed to be immune to brute force attacks, man-in-the-middle attacks and rolljam attacks. It is not our intent to describe the system or its workings in detail, other than as necessary in describing what has been performed and observed. We conclude with a short summary of strengths and weaknesses as determined by the author.
Bi-Symmetric Encryption uses a unique and novel handshake incorporating encrypted session key combinations, allowing user’s login credentials, biometric data, credit card data, or command/activation codes to be quickly and correctly processed, without directly transmitting this confidential data. The plug-and-play, hybridized encryption system employs concepts like asymmetric encryption meshed with more secure symmetric encryption.
Protect Identities. Secure Digital Services Enable highly scalable and secure user access to web and mobile applications. Start free trial.
A significant difference from commonly employed asymmetric encryption is that during the initial handshake to set up communication, no vulnerable data are exchanged. Should the sender key communication be intercepted by a hacker, they still cannot pretend to be the originator of the communication to the receiver.
The encryption itself is achieved by randomly generating keys and interweaving them with portions of unencrypted data to be transmitted, applied to single bytes of data rather than long byte collections. During the initial handshake, private keys are generated from or found in the form of login credentials, credit card information, biometric data, or other personal credential information or pre-shared private keys.
The private keys are used to start the handshake and are never actually transmitted. Randomly generated data in the form of challenge codes, counter challenge codes and session keys are exchanged during the handshake. This allows for the client and server to ascertain that the communicator, at the other end, are who they say they are. During the handshake, both parties mutually confirm the identity of the other, wherein when each device or computer properly modifies the challenge or counter challenge code, a fully encrypted session is established, and communication can proceed.
During the regular portion of the session, data are encrypted multiple times in a specific way so that only the correct receiver can decrypt the communication directly. Mathematical formulas are not used for encryption/decryption. Instead, algorithmic protocols are used.
During encryption, multiple levels of interweaving modifies and processes the various bytes, combined into new encrypted data sets which are finally transmitted to the receiver who then reverses the whole process to decrypt the message.
An important aspect of the encryption is that plain text characters in the data packets are modified individually instead of in groups or blocks, meaning that there are no overall mathematical relationships that can be identified. Each packet to be encrypted uses a different set of keys adding greatly to the complexity of the encrypted message. Several benefits result. Brute force attacks have no way in which to identify if an attempt to decrypt a portion of the message results in valid useable data. Hence any possible outcome is as likely as any other outcome. When billions of possible outcomes exist, it becomes impossible to determine the correct one.
The Bi-Symmetric encryption system is intended for use in multiple types of applications and is available with various levels of security requirements. Three levels are available based on need of apparent security level vs apparent encryption speed requirements. Where small portable devices which need high speed operations, the Bluetooth level is best suited. Where corporate, commercial and banking operations are concerned, a higher level of commercial encryption is warranted.
Bluetooth-level uses the smallest packet sizes, shortest key lengths, and the least amount of interweaving. The intended context for this level is keyless lock entry (ex. car fob) or other Bluetooth-based communication between devices, typical of private use applications and IoT devices.
Commercial applications form the next level of security robustness. These applications would include virtually any kind of transaction conducted over the internet, whether it be interaction with one’s bank, credit card account, or making online purchases, VPN remote access products and Industrial Internet of Things (IIoT).
The highest level of security robustness includes government and military applications. This level of security is many factors more complex than either commercial or Bluetooth applications.
Bluetooth encryption level is available with 256-bit encryption. The commercial encryption level is available using 336-bit encryption. It goes without saying, that the government and military encryption levels are far more complex and cannot be publicly disclosed.
In all cases, the inherent complexity of hacking the message by determining the keys is many orders of magnitude greater than current standard internet encryption protocols; all of which are considered secure against present standard supercomputers.
Perhaps the most significant and imminent threat to encryption security and possible breaking of the encryption keys, are the rapidly increasing capabilities of quantum computers. This threat has been known for a number of years.
In 2017, the National Institute of Standards and Technology (NIST) published a request for quantum resilient asymmetric encryption algorithms and received 89 submissions. The contenders were narrowed down to 26 during round 2, and has now further narrowed the selection down to 3 to 5 contenders. Due to the unexpected acceleration of quantum computer development, the final recommendation publication has been accelerated to 2023. Bi-Symmetric encryption is classified as a hybridized encryption system, not asymmetric, and therefore does not fall under the testing requirements of the NIST call for proposal.
The capabilities of quantum computing to reduce computationally hard problems, such as molecule modelling, to achievable solutions, are remarkable. IBM is currently offering a series of quantum computers (up to 51 qubits) in the cloud for use by anyone. They have defined a path of achievement that suggests the number of qubits in their computers will double every year and by 2023, plan to debut a 1,121-qubit computer called the IBM Quantum Condor.
It has been observed that a large enough number of qubits and support memory will be able to break RSA-2048 keys. With a 4000-qubit computer and 100 million gates, it theoretically becomes possible to factor 2048-bit keys; Shor’s algorithm may take 10,000 qubits. However, if IBM succeeds in their development path, a 10,000-qubit computer may be available as early as 2027, a mere 6 years from now.
Of course, these capabilities must still work within an acceptable amount of time to be useful to a hacker. It is often stated that a quantum computer can achieve the breaking of encryption keys, but it is not stated within what time frame are we theorizing. If the processing requires days, weeks, or months to complete, they lose their effectiveness as a code-breaking solution.
However, the threat is still real and not that far off. Shor’s algorithm was designed to allow quantum computers to process asymmetric encryption. Since Bi-Symmetric encryption is a hybridized encryption system using symmetric encryption, Grover’s algorithm needs to be applied instead of Shor’s algorithm.
Grover’s algorithm, also known as the quantum search algorithm, is a search quantum computer tool developed by Lov Grover, designed to allow databases to be quickly searched using a quantum computer. Grover’s algorithm was found to be able to provide a quadratic speed up for many types of algorithms including brute force attacking symmetric encryption. In fact, Grover’s algorithm is the only published algorithm that describes how a quantum computer can be programmed to attack symmetric encryption.
Calculations show that Grover’s algorithm can process a 128-bit AES symmetric key in 264 iterations and a 256-bit AES symmetric key in 2128 iterations. This translates into a quantum computer taking over 30,000 years to process. More information can be found in the published papers called “Quantum computers will not cause all forms of conventional encryption to become insecure” and “Reassessing Grover’s Algorithm” which describe Grover’s algorithm in more detail.
The table below shows estimated computational timing results for quantum computer processing AES and Bi-Symmetric Encryption. The values listed below assume a quantum computer can compute encryption functions at the “absurdly fast time of 1 picosecond” per iteration. Because the Bi-Symmetric handshake consists of multiple stages and types of data or instructions being encrypted, the timing results for the different uses are each listed separately below.
Session Keys or
Credit Card data,
For Grover’s Algorithm (and any future algorithm’s that may be invented) to work, a large data set encrypted using a single key must be available or provided for processing. To avoid this, the Bi-Symmetric handshake updates the session keys at periodic random intervals, ensuring a single key encrypted dataset will not be large enough to be successfully processed.
The approach taken by the CEW system is suitable to thwart even a quantum computing threat because of the nature in which they use multiple keys at both ends of the communication. Even with a quantum computer to assist in breaking the encryption keys, the large number of keys and seemingly random way in which they are applied still makes it unlikely that a key discovery will occur. In addition, since they apply and change keys, during the interweaving steps, even if keys were determined, the decrypted message would have many possible values making deciding which is the correct value virtually impossible.
Interweaving produces a result that has a very large, effective key set. For example, a 40-byte x 8-bit packet, generates approximately 7.16E+172 possibilities. By comparison, a standard 40-byte RSA key generates 1E+40 possibilities. It would require a classical computer roughly 3.17098E+23 years to break the code at 1,000,000,000 operations per second trying all permutations of the 40-byte key. The characteristic curve for factorization (using Python script run on a Dell GEFORCE) is shown here:
For non-programmers reading this article, shown above is the time taken to compute all factors for a given power of two. As can be seen, each loop takes twice as long as the previous. In a short number of loops the time will become unmanageable. For standard computers, the current factorization problem for determining the encryption keys of 2048 bits, is beyond capability.
While it is currently not possible to test a brute force attack using a quantum computer on a Bi-Symmetric Encryption handshake, CEW Systems undertook benchmark testing on a standard medium level computer to determine the processing time required to process the handshake.
The Bi-Symmetric Encryption handshake was evaluated for speed performance of standalone cryptographic operations, for the key exchange portion of the handshake. This was done for comparison reasons, as a third-party benchmark testing review was published on GitHub, comparing various published post-quantum encryption handshakes (https://github.com/mupq/pqm4/blob/master/benchmarks.md). Bi-Symmetric Encryption was written in C. Speed of wireless and internet connections and communication costs were not considered as these values will vary from system to system, distance between sending and receiving devices and loading of the receiving server.
The tests for the Bi-Symmetric Encryption were implemented on a stand-alone computer using an AMD A12-9720P, 4 core CPU processor, running at 2.7 GHz with 4 Gigs of RAM running on Windows 10 Home. The testing consisted of 4 rounds of testing, each testing 100 repetitions with the first instance excluded due to computer speed ramp up, resulting in 4 x 99 test results. The average time for a Bi-Symmetric handshake processing 336-bit keys is listed in milliseconds and computer cycles. Computer cycles are listed this is the standard benchmark for comparing encryption computational timing results.
Comparison Processing Time
Processing Time (%)
It may seem contrary that overhead processing of the Bi-Symmetric Encrypted message does not add significant delays to encryption/decryption (as listed above in CEW System’s encryption runtime tests). This seems reasonable when one understands that instead of processing large byte sets in encrypted blocks, the system encrypts small blocks but with a large set of keys. Thus, processing is very fast while still secure. This is why the CEW Systems calls the handshake system the fastest, smallest, and largest of the encryption techniques.
Much has been explored about ways in which the Bi-Symmetric Encryption handshake is ideally suited for encrypting pay-per-use e-commerce transactions.
For ease of explanation, two main examples are described below, a smart device banking app and a credit card purchasing app. The Bi-Symmetric handshake has been designed with many more types of applications in mind, including car fobs, autonomous vehicles, smart phone apps, client/server logins applications, file transfer encryption, IoT and IIoT devices, just to name a few.
Consistent with all communication, the customer’s account information is never actually transmitted. The customer’s username, ID number, or database lookup index number is sent as salted encrypted data, so the server can look up the customer’s account. The use of a database lookup index number allows the database server to access the user’s account more quickly without having to do a database query search. The following image shows the data that is actually transmitted during the exchange:
The crucial security point is that the customer’s account card containing the private pre-shared keys would be used as the master keys for the handshake allowing a purchase to occur without transmitting the private keys.
In this example, when a login with a banking app is requested, the password typed in by the user is not sufficiently complicated and needs to be expanded in size out to a large more complex set of private keys. To accomplish this, unique data from the computer or smart device, such as serial numbers, are extracted and factored with the user’s typed in password to create a complex combined passcode. Using the now much larger combined passcode, the challenge and counter challenge codes are exchanged and modified to process and authenticate the login request. The user’s combined passcode, must of course be pre-registered with the banking server during account registration, see “What about initial secret exchange and account setup?” section below.
The use of internal database values helps to further protect from MIM attacks. Note that the database index must not be tied to physical data locations because those locations could change if the database were moved or restored from a backup. Any database-managed keys (index, constraint, etc.) would be suitable.
Another important feature is that the non-transmitted data that each system (client/server) has, must match or the interaction is dismissed. For example, consider a credit card purchase. Here are the screens of the purchaser (client, left) and the retailer (server, right):
In the above scenario, the information on the client matches that on the server. Even though the data itself is not exchanged, session keys based on the data are generated at each end of the communication.
The authorization is processed by converting the complex data entered by the client into the purchasing app and the data held by the financial institute are independently factored into large private keys which then modify the challenge and counter challenge codes during the authentication handshake.
In this case, when the client clicks the “Purchase” button, the purchase will be approved because the session keys at each end encrypted and decrypted correctly.
Now consider where some information is different (perhaps it has been illegally obtained).
When the “Purchase” button is clicked, the session keys at each end of the communication will be different because the critical data upon which they were created are different. Since the server cannot decrypt the message correctly, it will decline the transaction:
Common secrets, known to both server and client, must be exchanged when initial set up of accounts is made. Various methods exist to do this, but most involve the human factor, which is dangerous.
If setting up an account with a bank, or credit card, one must (still) visit in person to initially establish identity. Once this is accomplished, remaining interaction with the bank or credit institution is likely to be electronic. If in-person is not possible, a secure postal service, such as registered mail, can be an alternative to sharing the common secrets.
When the initial interaction is online only, such as when setting up an account with an online retailer, the initial secrets have to be exchanged online as well. A suggested approach is based upon using a 3rd party where a person would already have exchanged pre-share private keys. It is a variation of the “trusted party” identification used in standard RSA to ensure the response, encrypted with the public key, is in fact coming from the person it is supposed to and not a hacker. In the Bi-Symmetric case, the trusted third party could be a credit card company.
The credit card companies could be incentivized to provide this third-party confirmation/key exchange as a service that could be offered for a small fee. The following describes a potential interchange.
A standard credit card purchase using the Bi-Symmetric handshake, which relies upon pre-shared private keys, uses the purchaser's credit card data and billing address as the pre-shared private keys. When a user goes to sign up for a new account with, say Netflix, the Bi-Symmetric Handshake requires pre-shared private keys. Using a credit card transaction at account setup can provide the required pre-shared private keys. Upon account setup, a user would be prompted to first enter their credit card information to confirm that they have both a valid credit card, while also confirming who they truly are.
The standard Bi-Symmetric encryption handshake occurs between the e-commerce app (could be provided by Netflix or a third-party e-commerce app) and the credit card company. The credit card transaction occurs which creates the required set of Bi-Symmetric session keys as part of the standard transaction. If the transaction is approved, the server then starts a second Bi-Symmetric handshake directly with Netflix, then transmits the original transaction session keys to Netflix.
Now the user and Netflix both have the identical transaction session keys, and the user can finish the account setup. The user's e-commerce app then uploads the user's address information to Netflix. The user is then free to enter additional required data specific to Netflix's product offerings and approved family member users, all securely encrypted. Subsequent logins to the account happen in the normal manner.
Additional identification authentication using usual methods can be added to the trusted data. For example, answers to security questions can be added for additional authentication. It is suggested that a user-supplied question be added to the typical set of standard questions to help thwart social media scraping. This additional information can be used to support changing passwords, or other secret data shared by both client and server:
How does Netflix receive the credit card data so that they can then process the user's monthly subscription? This is accomplished in that when the approval transaction occurs, the credit card server takes Netflix's corporate account private keys, combines them with the user's private credit card keys and encrypts them together with Bi-Symmetric encryption. The combined key set is then sent to Netflix during the initial transaction as an additional data packet. As each monthly customers’ transactions are processed, the combined key sets are processed through a specialized bulk submittal credit card purchase transaction server function.
If a hacker does manage to break into the Netflix server, no credit card numbers will be found, only the combined key sets will be found. Since these combined key sets can only be submitted through the specialized bulk credit card purchase transaction server, they are useless for making online purchases.
These combined keys cannot be separated by hackers and cannot be used to purchase anything through an ordinary e-commerce purchase user interface. Of course, it is always possible that, somehow, a hacker could non-digitally steal the set of secrets. However, the nature of the protocol means the worst that could happen is the hacker would end up giving money to the company (Netflix).
Initial account setup often requires additional steps to establish and record secrets which must consider possible key logging, screen capture and other attempts to invade the privacy of the data during the set-up transaction. One approach for entering such data, suggested by CEW, involves using rotation wheels of characters (special and alphanumeric depending on what is being entered) similar to a rotating wheel found on luggage, as shown here:
Each time an entry of data is required, a number of wheels appear with randomly generated characters. Thus, it cannot be predicted from which start character the user will click the wheel to find the correct data element. Key logging can count the clicks but without knowing the start position of the wheel, the count is meaningless. Although this is an issue with all security systems during critical initial data entry, the approach suggested here decreases even further any likelihood of easily capturing secret data.
The Bi-Symmetric encryption algorithm has been designed to use the computational superposition of quantum computers against itself. During the encryption, key expansion keys are extracted from a small amount of the data being encrypted. As mentioned previously, the main keys are encrypted and modified by the extracted data, which in turn, using the now modified keys, encrypts the data. This action expands the original key count from 336-bit keys up to a much larger 12,096-bit key size.
What this means for an attacking quantum computer is, if the quantum computer uses the superposition capability to test every possible plain text value against every possible encryption key combination, the quantum computer will be processing each encrypted data packet using 12,096-bit keys.
Where a quantum computer is testing every possible key combination, the keys are modified 5,184 times for each variation of the 336-bit keys. This adds additional exponential complexity.
These design features does not necessarily mean a quantum computer will take extra time processing the data. Instead, they are designed to exponentially increase the total possible variations a quantum computer needs to process when comparing multiple intercepted encrypted data packets. Now you can understand that with the expanded key size being much greater in size and the large number of possible modifications that can be applied to the original keys, there will be a very large number of resulting combinations that will mimic the exact same intercepted data packets. CEW Systems calls these “false positive results”. The table below shows approximate computed values for commercial grade encryption showing the number of false positive results for each level of the encryption handshake.
Data packet length
Transmitted non-public key size
Extracted data for key expansion keys
Key size to be processed after key expansion
Total possible key expansion modifications
Per key variation
Number of possible false positive results for each encrypted data packet
False positive duplications
Number of possible false positive results when examining the session keys or command codes
False positive duplications
Total number of possible false positive results when examining the handshake for credit card data or login passcodes
False positive duplications
~10 followed by 163 trillion zeros
Knowing the procedures would aid in hacking the keys, therefore, the actual implementation of the algorithms, as well as the algorithms themselves, must be kept secret.
Take for example the widely used freely downloadable messaging software Signal. A post published in December of 2020 by the software firm Cellebrite, claimed that they are able to easily decrypt messages stored on any device encrypted by the Signal software. The post claims that by simply reading through the published algorithms, they were able to find where the encryption key is stored and used to encrypt stored messages.
The interweaving protocol is not mathematically based, but procedurally based. Of course, the data secrets for each client-server interchange must also be known, which is highly unlikely. CEW has many protocols in place to keep their application code secure. However, this may cause difficulty in obtaining certification by security agencies if they cannot inspect the code for security issues and thoroughness.
With the signing of an appropriate NDA agreement, CEW Systems is agreeable and open to certification with appropriate companies or agencies.
Finally, it is not currently known how easy it would be to reverse engineer a copy of the executable code. In a manner akin to salting data values before hashing, extraneous code could be added throughout the actual code to hide the true nature of the functions within the application. This is something that can be undertaken in the future should it become an issue.
The new and novel Bi-Symmetric Encryption system reviewed here offers multilevel quantum resilient encryption technology that has been specifically designed to be immune to brute force attacks, man-in-the-middle attacks, with the use of a timer, relay attacks and rolljam attacks (a method to break into an automobile by blocking and recording the signal transmitted by a car key fob and then used by the recording device to access the vehicle).
Quantum computers are hyped in the media as the current and only real threat to classical encryption. It would be prudent to note that while quantum computers will eventually decrypt current classical encryption, there are currently multiple existing types of attacks, which have been designed to defeat various types of current software without the need of resorting to super powerful computers. Bi-Symmetric Encryption has been designed specifically to address several of the above-mentioned types of attacks.
Wherein other encryption programs only provide a token key exchange, or 2-Factor Authentication (2FA), the Bi-Symmetric Encryption system is designed with an exponentially leveled multi-factor authentication system.
The potential to employ financial institutions and credit card companies for third party trusted authentication will allow online customers to safely and securely sign up with online commercial corporations using the Bi-Symmetric Encryption handshake system.
The Bi-Symmetric Encryption handshake allows for pre-shared private keys, login credentials and command codes to be processed by a receiving device or server without the need to transmit the data directly.
Bi-Symmetric Encryption will also encrypt standard types of data directly. The handshake has the ability to periodically update the session keys, at random or predefine intervals, to ensure that a large enough dataset encrypted by a single session key for which a quantum computer could use to detect a pattern, will not be produced.
Bi-Symmetric Encryption is designed to be embedded within electronic devices and systems such as Internet of Things (IoT), automotive Remote Keyless Systems (RKS), autonomous systems such as driverless vehicles, as well as being ideally suited for online downloading of keys to allow smart devices to be used by vehicle owners to connect to their vehicles. It has been designed and optimized to be embedded in electronics, depending upon the type of system and the C or C++ compiler used, the compiled library is only 30k to 60k is size.
Through integration with online retailers, credit card companies and financial institutions, a higher level of security can be achieved for the millions of transactions that occur daily over the internet.
This article is a based on a third-party academic peer review requested by CEW Systems Canada Inc. to have the Saskatchewan Polytechnic Digital Integration Centre of Excellence (DICE) group evaluate their Bi-Symmetric Hybrid Encryption System for quantum resilient encryption robustness. The review was funded by the National Research Council of Canada’s Industrial Research Assistance Program (NRC and IRAP) as a CTO-funded analysis of their Bi-Symmetric Hybrid Encryption System.
DICE is Saskatchewan’s first Technology Access Centre (TAC) funded by NSERC and Innovation Saskatchewan. DICE works collaboratively with various industry partners to help solve their data challenges — particularly those related to data integrity, data transmission, and data analysis and storage. Businesses, industries and non-profits work with DICE on data issues or challenges. This can be as basic as to how to identify usable business statistics or as complex as using machine learning and artificial intelligence to ensure constant process optimization on a production line.
Cyril Coupal has his PhD in Computer Science specializing in database architecting, software engineering and machine learning. He has an academic career of 34 years. During this time, he also contributed to the software and database development of several industrial projects spanning large commercial wholesale systems, data analysis of pressure vessel tests used in the oil and gas industry, and automated planning and design for the housing industry. Cyril has been a senior research associate with DICE since 2017.
A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example
We protect your privacy.
You need to Register an InfoQ account or Login or login to post comments. But there’s so much more behind being registered.
Get the most out of the InfoQ experience.
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p
Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p
A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example
We protect your privacy.
Focus on the topics that matter in software development right now.
Deep-dive with 64+ world-class software leaders. Discover how they are applying emerging trends. Learn their use cases and best practices.
Stay ahead of the adoption curve and shape your roadmap with QCon Plus online software development conference.
InfoQ.com and all content copyright © 2006-2021 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we’ve ever worked with.