Posts Tagged ‘scalability

Limitations of Modern Cryptosystems

Before exploring quantum key distribution, it is important to understand the state of modern cryptography and how quantum cryptography may address current digital cryptography limitations. Since public key cryptography involves complex calculations that are relatively slow, they are employed to exchange keys rather than for the encryption of voluminous amounts of date. For example, widely deployed solutions, such as the RSA and the Diffie-Hellman key negotiation schemes, are typically used to distribute symmetric keys among remote parties. However, because asymmetric encryption is significantly slower than symmetric encryption, a hybrid approach is preferred by many institutions to take advantage of the speed of a shared key system and the security of a public key system for the initial exchange of the symmetric key. Thus, this approach exploits the speed and performance of a symmetric key system while leveraging the scalability of a public key infrastructure.

However, public key cryptosystems such as RSA and Diffie-Hellman are not based on concrete mathematical proofs. Rather, these algorithms are considered to be reasonably secure based on years of public scrutiny over the fundamental process of factoring large integers into their primes, which is said to be “intractable”. In other words, by the time the encryption algorithm could be defeated, the information being protected would have already lost all of its value. Thus, the power of these algorithms is based on the fact that there is no known mathematical operation for quickly factoring very large numbers given today’s computer processing power.

Secondly, there is uncertainty whether a theorem may be developed in the future  or perhaps already available that can factor large numbers into their primes in a timely manner. At present, there is no existing proof stating that it is impossible to develop such a factoring theorem. As a result, public key systems are thus vulnerable to the uncertainty regarding the future creation of such a theorem, which would have a significant affect on the algorithm being mathematical intractable. This uncertainty provides potential risk to areas of national security and intellectual property which require perfect security.

In sum, modern cryptography is vulnerable to both technological progress of computing power and evolution in mathematics to quickly reverse one way functions such as that of factoring large integers. If a factoring theorem were publicized or computing became powerful enough to defeat public cryptography, then business, governments, militaries and other affected institutions would have to spend significant resources to research the risk of damage and potentially deploy a new and costly cryptography system quickly.

Tags : , , , , , , , , ,

InnoDB and MyISAM Benchmark Results

The ACID properties of InnoDB were relaxed when running the performance comparisons. The log buffer is configured to write out updates to the log file at each commit, butonly flushes to disk at set time intervals. The following statement is used to configure this behavior.


Using the value above, the log file is flushed once per second, essentially batching writes to disk,rather than committing transactions individually. The result is higher throughput, especially for update-intensive and I/O bound workloads. When using a value of “2”, as above, only an operating system crash or a power outage can erase the last second of transactions. However, InnoDB’s crash recovery is not affected and continues to work regardless of the value.

With a value of “0” used in the statement above, a mysqld process crash can erase the last second of transactions, though again InnoDB’s crash recovery is unaffected. The default value of “1” is required in the statement above for full ACID-compliance.

Sysbench Results

Both Read / Write and Read-Only Sysbench tests were run to compare the performance and scalability of InnoDB and MyISAM, with Transactions Per Second (TPS) recorded for each storage engine as more cores were enabled in the host server. Initial runs were made with 6-cores, and then repeated as the server was scaled with 12, 18, 24, 30 and then 36-cores. In allcases, the number of concurrent database connections was set at 64.

As the data below demonstrates, InnoDB delivers very good scalability up to 30-cores. From 30 to36-cores, performance continues to increase, though scalability is reduced.

MyISAM demonstrates almost zero scalability from 6 to 36 cores, with performance significantly lower than InnoDB.

Read-Write Results

As the graph below shows, InnoDB delivered 35x higher throughput than MyISAM, while achieving 85% – 90% scalability from 6 to 36-cores. Above 30-cores, the scalability curve starts to flatten out as the number of hot mutexes grow, but performance does still continue to increase.

Clearly table locking in MyISAM reduces throughput for Read / Write workloads.

Figure 1: InnoDB Delivers 35x Higher Performance than MyISAM with up to 90% Scalability

Read-Only Results

InnoDB delivered 4.6x higher throughput than MyISAM, while achieving 90% – 95% scalability from 6 to 36-cores. Above 30-cores, scalability flattens out as the server is again saturated by anumber of hot mutexes.

Figure 2: InnoDB Delivers 4.6x Higher Performance than MyISAM with up to 95%Scalability


Tags : , , , , , , , , , ,

A protocol answering the usability and scalability issues

A major observation that substantially improves the protocol is that each user typically uses a limited set of computers, and that it is unlikely that a dictionary attack would be mounted against this user’s account from one of these computers. This observation can be used to answer the scalability and usability issues, while reducing security by only a negligible amount. Another helpful observation is that it would be hard for the adversary to attack accounts even if it is required to answer RTTs for only a fraction of its login attempts (and we show below how to do this without running into the problem pointed out in the comment above). This enables a great improvement in the scalability of the system.

The protocol assumes that the server has a reliable way of identifying computers. For example, in a web based system the server can identify a web browser using cookies. Other identification measures could be, for example, based on network addresses or special client programs used by the user. To simplify the exposition we assume that the login processuses a web browser, and that cookies are enabled. Our protocol can handle cookie theft, as we describe below.

User login protocol

Initialization: Once the user has successfully logged into an account, the server places in the user’s computer a cookie that contains an authenticated record of the username, and possibly an expiration date. (“Authenticated” means that no party except for the server is able to change the cookie data without being detected by the server. This can be ensured, for example, by adding a MAC that is computed using a key known only to the server. Cookies of this type can be stored in several computers, as long as each of them was used by the user.


  1. If the cookie is correctly authenticated and has not yet expired, and the user identification record stored in the cookie agrees with the entered username, then the user is granted access to the server.
  2. Otherwise (there is no cookie, or the cookie is not authenticated, or the user identification in the cookie does not agree with the entered username) the server generates an RTT and sends it to the user. The useris granted access to the server only if  he answers the RTT correctly.
  1. With probability p (where 0 < p <=1 is a system parameter, say p = 0:05), the user is asked to answer an RTT. When his answer is received he is denied access to the server, regardless of whether it is correct or not.
  2. With probability 1- p, the user is immediately denied access to the server.

This is the login protocol


The user is experiencing almost the same interaction as in the original login protocol (that uses no RTTs). The only difference is that he is required to pass an RTT in two instances (1) when he tries to login from a new computer for the first time, and (2) when he enters a wrong password (with probability p). We assume that most users are likely to use a small set of computers to access their accounts, and use other computers very in frequently (say,while traveling without a laptop). We also have evidence, from the use of RTTs in Yahoo!, Alta Vista and Paypal,that users are willing to answer RTTs if they are not asked to do so very frequently. Based on these observations we argue that the suggested protocol could be implemented without substantially downgrading the usability of the login system.


The main difference in the operation of the server, compared to a login protocol that does not use RTTs, is that it has to generate RTTs whenever they are required by the protocol. To simplify the analysis assume that most users use a small set of computers, and very seldom use a computer that they haven’t used before. We can therefore estimate that the server is required to generate RTTs only for a fraction p of the unsuccessful login attempts. Thisis a great improvement compared to the basic protocol, which requires the server to generate an RTT for every login attempt. Note that the overhead decreases as p is set to a smaller value. As for the cost of adding the new protocol to an existing system, note that no changes need to be made to the existing procedure, where the authentication module receives a username/password pair and decides whether they correspond to a legitimate user. The new protocol can use this procedure as a subroutine, together with additional code that decides whether to require the user to pass an RTT, and whether to accept the user as legitimate.

Tags : , , , , , , , , ,

E-Commerce and the semantic web

The web has drastically changed the online availability of data and the amount of electronically exchanged information. It has revolutionised access to personal information and knowledge management in large organisations. Also, it has started to change the commercial relationships between suppliers and customers. Around 1% of the overall sales figures in B2C in the US are done on-line. This is still a small fraction but its fast growth looks very likely given that the number of Internet users grew from 100 to 300 million between 1997 and 2000. Forecasts for the dollar value of B2B in the US range between $0,5 and $3 trillion for 2003. Currently, alarge fraction of the B2B transactions is still realised by traditional non-Internet networks, such as those conducted over EDI systems. In this traditional paradigm, direct 1-1 connections and mappings are programmed. However, this traditional paradigm nowhere near employs the full power of electronic commerce and it is quite likely that it will soon to be out-ranged by more timely, Internet and web-based types for transactions. Internet-based electronic commerce provides a much higher level of flexibility and openness that will help to optimise business relationships. Instead of implementing one link to each supplier, a supplier is linked to a large number of potential customers. Therefore, a supplier or customer can choose between a large number of potential customers and can optimise his business relationships.

Bringing electronic commerce to its full potential requires a Peer-to-Peer (P2P) approach. Anybody must be able to trade and negotiate with anybody else. However, such an open and flexible electronic commerce has to deal with many obstacles before it becomes reality.

Therefore, applying semantic web technology to bring electronic commerce to its full potential is such a promising activity. Semantic web technology has the potential to solve some of the key obstacles in effective and efficient electronic commerce and electronic commerce is an area with a large economic potential. It is also the natural way to link semantic web technology and web services. Transferring the latter from hype to a working technology requires the solutions of the problems we mentioned above.

Tags : , , , , , , , , , , , , ,