Concept
This lesson explains different types of cryptography techniques that are commonly used in web applications.

이 수업에서는 Web Application에서 일반적으로 사용되는 다양한 암호화 기술을 설명한다.

Goals
The goal is to get familiar with the following forms of techniques:

다음과 같은 기술 형태에 익숙해지는 것이 목표다:

• Encoding
• Hashing
• Encryption
• Signing
• Keystores
• Security defaults
• Post quantum crypto

Assignments
After the explanation of an item there will be several assignments.

Encoding

Base64 Encoding

Encoding is not really cryptography, but it is used a lot in all kinds of standards around cryptographic functions. Especially Base64 encoding.

인코딩은 실제로 암호화는 아니지만 암호화 기능과 관련된 다양한 표준에서 많이 사용된다. 특히 Base64 인코딩이 많이 사용된다.

Base64 encoding is a technique used to transform all kinds of bytes to a specific range of bytes. This specific range is the ASCII readable bytes. This way you can transfer binary data such as secret or private keys more easily. You could even print these out or write them down. Encoding is also reversible. So if you have the encoded version, you can create the original version.

Base64 인코딩은 다양한 바이트를 특정 범위의 바이트로 변환하는 기술이다. 이 특정 범위는 ASCII로 읽을 수 있는 바이트다. 이를 통해 이진 데이터를 더 쉽게 전송할 수 있다. 예를 들어 비밀 키나 개인 키와 같은 것들을 인코딩 할 수 있다. 또한 인코딩은 되돌릴 수 있다. 즉, 인코딩 된 버전이 있다면 원래 버전을 생성할 수 있다.

On wikipedia you can find more details. Basically it goes through all the bytes and transforms each set of 6 bits into a readable byte (8 bits). The result is that the size of the encoded bytes is increased with about 33%.

위키피디아에서 더 많은 세부 정보를 찾을 수 있다. 기본적으로 모든 바이트를 거쳐 각 6비트 세트를 읽을 수 있는 바이트(8비트)로 변환한다. 결과적으로 인코딩 된 바이트의 크기는 약 33% 증가한다.

Hello ==> SGVsbG8=
0x4d 0x61 ==> TWE=

Basic Authentication

Basic authentication is sometimes used by web applications. This uses base64 encoding. Therefore, it is important to at least use Transport Layer Security (TLS or more commonly known as https) to protect others from reading the username password that is sent to the server.

기본 인증은 Web Application에서 사용된다. 이는 Base64 인코딩을 사용한다. 따라서 서버로 전송되는 사용자 이름과 비밀번호를 보호하기 위해 최소한 TLS를 사용하는 것이 중요하다.

$echo -n "myuser:mypassword" | base64
bXl1c2VyOm15cGFzc3dvcmQ=

The HTTP header will look like:

HTTP 헤더는 다음과 같다.

Authorization: Basic bXl1c2VyOm15cGFzc3dvcmQ=

Other Encoding

Also other encodings are used.

다른 인코딩도 사용된다.

URL encoding

URL encoding is used a lot when sending form data and request parameters to the server. Since spaces are not allowed in a URL, this is then replaced by %20. Similar replacements are made for other characters.

URL 인코딩은 Form 데이터와 요청 파라미터를 서버로 전송할 때 많이 사용된다. URL에 공백이 허용되지 않기 때문에 공백은 %20으로 대체된다. 다른 문자에 대해서도 유사한 대체가 이루어진다.

HTML encoding

HTML encoding ensures that text is displayed as-is in the browser and not interpreted by the browser as HTML.

HTML 인코딩은 텍스트가 브라우저에서 HTML로 해석되지 않고 그대로 표시되도록 보장한다.

UUEncode

The Unix-2-Unix encoding has been used to send email attachments.

Unix-2-Unix 인코딩은 이메일 첨부 파일을 보내는 데 사용되었다.

XOR encoding

Sometimes encoding is used as a first and simple obfuscation technique for storing passwords. IBM WebSphere Application Server e.g. uses a specific implementation of XOR encoding to store passwords in configuration files. IBM recommends to protect access to these files and to replace the default XOR encoding by your own custom encryption. However when these recommendations are not followed, these defaults can become a vulnerability.

때떄로 인코딩은 비밀번호를 저장하기 위한 첫 번째 간단한 난독화 기술로 사용된다. 예를들어 IBM WebSphere Application Server는 구성 파일에 비밀번호를 저장하기 위해 특정 XOR 인코딩 구현을 사용한다. IBM은 이러한 파일에 대한 액세스를 보호하고 기본 XOR 인코딩을 사용자 정의 암호화로 대체할 것을 권장한다. 이러한 권장 사항을 따르지 않으면 기본 설정이 취약점이 될 수 있다.

Hashing

Plain Hashing

Hashing is a type of cryptography which is mostly used to detect if the original data has been changed. A hash is generated from the original data. It is based on irreversible cryptographic techniques. If the original data is changed by even one byte, the resulting hash is also different.

해싱은 주로 원본 데이터가 변경되었는지 여부를 감지하는데 사용되는 암호화 유형이다. 원본 데이터에서 해시가 생성된다. 이는 되돌릴 수 없는 암호화 기술을 기반으로 한다. 원본 데이터가 한 바이트라도 변경되면 생성된 해시도 달라진다.

So in a way it looks like a secure technique. However, it is NOT and even NEVER a good solution when using it for passwords. The problem here is that you can generate passwords from dictionaries and calculate all kinds of variants from these passwords. For each password you can calculate a hash. This can all be stored in large databases. So whenever you find a hash that could be a password, you just look up the hash in the database and find out the password.

따라서 이 기술은 보안 기술처럼 보이지만 비밀번호에 사용하는 것은 좋은 해결책이 아니다. 문제는 사전에서 비밀번호를 생성하고 이러한 비밀번호의 모든 변형을 계산할 수 있다는 것이다. 각 비밀번호에 대한 해시를 계산할 수 있다. 이는 대규모 데이터베이스에 모두 저장될 수 있다. 따라서 비밀번호일 수 있는 해시를 찾으면 데이터베이스에서 해시를 찾아 비밀번호를 알아낼 수 있다.

Some hashing algorithms should no longer be used: MD5, SHA-1 For these hashes it is possible to change the payload in such a way that it still results in the same hash. This takes a lot of computing power, but is still a feasible option.

일부 해싱 알고리즘은 더 사용하지 않는 것이 좋다: MD5, SHA-1. 이러한 해시의 경우 페이로드를 변경해 동일한 해시가 나오도록 할 수 있다.이는 많은 컴퓨팅 파워를 필요로 하지만 여전히 실현 가능하다.

Salted Hashes

Plain passwords should obviously not be stored in a database. And the same goes for plain hashes. The OWASP Password Storage Cheat Sheet explains what should be used when password related information needs to be stored securely.

평문 패스워드는 데이터베이스에 저장되어서는 안 된다. 평문 해시도 마찬가지다. 패스워드 관련 정보를 안전하게 저장해야 할 때사용하는 방법은 OWASP 비밀번호 저장 치트 시트에 설명되어 있다.

Encrypthon

Symmetric encryption

Symmetric encryption is based on a shared secret that is used for both encryption as well as decryption. Therefore, both parties (that are involved in exchanging secrets) share the same key.

대칭 암호화는 암호화와 복호화 모두에 사용되는 공유 Secret을 기반으로 한다. 따라서 Secret을 교환하는 두 주체는 동일한 키를 공유한다.

Example protocols are:

• AES
• 3DES

Asymmetric encryption

Asymmetric encryption is based on mathematical principles that consist of a key pair. The two keys are usually called a private key and a public key. The private key needs to be protected very well and is only known to one party. All others can freely use the public key. Something encrypted with the private key can be decrypted by all that have the public key, and something encrypted with the public key can only be decrypted with the private key.

비대칭 암호화는 키 쌍으로 구성된 수학적 원칙을 기반으로 한다. 두 키는 개인 키와 공개 키라고 한다. 개인 키는 보호되어야 하며 한 쪽의 당사자만 알고 있다. 다른 모든 사람은 공개 키를 자유롭게 사용할 수 있다. 개인 키로 암호화 된 것은 공개 키를 가진 모든 사람이 복호화 할 수 있으며, 공개 키로 암호화 된 것은 개인 키로만 복호화 할 수 있다.

Example protocols are:

• RSA
• DSA

HTTPS는 대칭 및 비대칭 키를 모두 사용한다
다음은 브라우저를 열고 https 사이트에 접속할 때 발생하는 일에 대한 설명이다.

• 브라우저가 서버에 연결해 웹 서버 인증서를 가져온다.
• 브라우저는 인증서 발급자가 신뢰할 수 있는 저장소에 있는지 확인하여 인증서 발급자를 신뢰할 수 있는지 확인한다. 이 저장소는 운영 체제 및 브라우저 업데이트로 관리된다. 일부 기업 네트워크에서는 회사에서 관리한다. 브라우저는 인증서에서 공개 키를 얻는다.
• 브라우저는 이제 대칭 키를 생성하기 위해 사용할 임의의 바이트를 생성하고 이를 서버의 공개 키로 암호화 한다. 따라서 서버만이 이를 복호화 할 수 있다.
• 이 과정이 끝나면 브라우저와 웹 서버는 대칭 키 교환 과정에서 교환한 대칭 키를 사용하여 브라우저와 웹 서버간에 주고 받는 메세지를 암호화하고 복호화 한다.

Symmetric keys are used because it can be used more easily with large sets of data and requires less processing power in doing so.

대칭 키는 대용량 데이터 셋과 더 쉽게 사용할 수 있으며 처리하는 데 드는 파워가 적기 때문에 사용된다.

Signing

A signature is a hash that can be used to check the validity of some data. The signature can be supplied separately from the data that it validates, or in the case of CMS or SOAP can be included in the same file. (Where parts of that file contain the data and parts contain the signature).

서명은 일부 데이터의 유효성을 확인하는 데 사용할 수 있는 해시다. 서명은 데이터를 검즣아는 해시와 별도로 제공되거나 CMS 또는 SOAP의 경우 동일한 파일에 포함될 수 있다(파일의 일부는 데이터, 일부는 서명으로 구성된다).

Signing is used when integrity is important. It is meant to be a guarantee that data sent from Party-A to Party-B was not altered. So Party-A signs the data by calculating the hash of the data and encrypting that hash using an asymmetric private key. Party-B can then verify the data by calculating the hash of the data and decrypting the signature to compare if both hashes are the same.

서명은 무결성이 중요한 경우 사용된다. 이는 A에서 B로 전송된 데이터가 변경되지 않았음을 보장하기 위한 것이다. 따라서 A는 데이터를 해시하여 데이터에 서명한다. 그 다음 비대칭 개인 키를 사용해 해당 해시를 암호화 한다. B는 데이터를 해시하고 서명을 복호화하여 두 해시가 동일한지 비교해 데이터를 검증한다.

RAW signatures

A raw signature is usually calculated by Party-A as follows:

• create a hash of the data (e.g. SHA-256 hash)
• encrypt the hash using an asymmetric private key (e.g. RSA 2048 bit key)
• (optionally) encode the binary encrypted hash using base64 encoding

RAW 서명은 보통 A가 다음과 같이 계산한다.

• 데이터의 해시 생성(e.g. SHA-256 gotl)
• 비대칭 개인 키를 사용해 해시 암호화(e.g. RSA 2048비트 키)
• (선택적으로) 바이너리 암호화된 해시를 Base64 인코딩

Party-B will have to get the certificate with the public key as well. This might have been exchanged before. So at least 3 files are involved: the data, the signature and the certificate.

B는 인증서와 공개 키를 가지고 있어야 한다. 이는 이전에 교환되었을 수 있다. 따라서 최소 3개의 파일이 필요하다: 데이터, 서명, 인증서

CMS signatures

A CMS signature is a standardized way to send data + signature + certificate with the public key all in one file from Party-A to Party-B. As long as the certificate is valid and not revoked, Party-B can use the supplied public key to verify the signature.

CMS 서명은 표준화된 방식을 통해 A에서 B로 데이터, 서명, 공개 키가 하나의 파일로 전송되는 것이다. 인증서가 유효하고 취소되지 않는 한 B는 제공된 공개 키를 사용해 서명을 확인할 수 있다.

SOAP signatures

A SOAP signature also contains data and the signature and optionally the certificate. All in one XML payload. There are special steps involved in calculating the hash of the data. This has to do with the fact that the SOAP XML sent from system to system might introduce extra elements or timestamps. Also, SOAP Signing offers the possibility to sign different parts of the message by different parties.

SOAP 서명은 데이터와 서명, 그리고 선택적으로 인증서가 모두 하나의 XML 페이로드에 포함된다. 시스템 간 전송된 SOAP XML이 추가 요소나 타임 스탬프를 도입할 수 있으므로 데이터의 해시를 계산하는 데 특별한 단계가 포함된다. 또한 SOAP 서명은 다른 당사자가 메시지의 서로 다른 부분을 서명할 수 있는 기능을 제공한다.

Email signatures

Sending emails is not very difficult. You have to fill in some data and send it to a server that forwards it, and eventually it will end up at its destination. However, it is possible to send emails with a FROM field that is not your own email address. In order to guarantee to your receiver that you really sent this email, you can sign your email. A trusted third party will check your identity and issue an email signing certificate. You install the private key in your email application and configure it to sign emails that you send out. The certificate is issued on a specific email address and all others that receive this email will see an indication that the sender is verified, because their tools will verify the signature using the public certificate that was issued by the trusted third party.

이메일을 보내는 것은 그다지 어렵지 않다. 데이터를 채우고 서버에 전달하면 결국 목적지에 도달하게 된다. 그러나 보내는 사람의 이메일 주소가 실제로 본인의 이메일 주소가 아닌 경우도 있다. 수신자에게 본인이 이 이메일을 보냈다는 것을 보증하기 위해 이메일에 서명할 수 있다. 신뢰할 수 있는 제 삼자가 당신의 신원을 확인하고 이메일 서명 인증서를 발급한다. 개인 키를 이메일 애플리케이션에 설치하고 이를 사용하여 보내는 이메일에 서명하도록 구성한다. 인증서는 특정 이메일 주소에 대해 발급되며, 이 이메일을 수신하는 모든 사용자는 신뢰할 수 있는 제 삼자가 발급한 공개 인증서를 사용하여 서명이 확인되었음을 알 수 있다.

Keystores

A keystore is a place where you store keys. Besides keystore the term truststore is also used frequently. A truststore is the same thing as a keystore. Only it usually contains only the certificates (so basically only public keys and issuer information) of trusted certificates or certificate authorities.

키 저장소는 키를 저장하는 장소다. 키 저장소 이외에도 신뢰 저장소라는 용어가 자주 사용된다. 신뢰 저장소는 일반적으로 신뢰할 수 있는 인증서 또는 인증서 기관의 인증서(즉, 기본적으로 공개 키 및 발급자 정보만)만 포함한다.

File based keystores

A file based keystore is something that in the end has the keys on a file system. Storing public certificates in a file based keystore is very common

파일 기반 키 저장소는 결국 키가 파일 시스템에 저장되는 것이다. 공개 인증서를 파일 기반 키 저장소에 저장하는 것은 매우 흔하다.

Database keystores

Keys and especially public certificates can of course also be stored in a database.

키와 특히 공개 인증서는 데이터베이스에 저장할 수 있다.

Hardware keystore

A hardware keystore is a system that has some sort of hardware which contain the actual keys. This is typically done in high end security environments where the private key is really private. In comparison with file based or database keystores, it is impossible to make a copy of the keystore to send it to some unknown and untrusted environment.

하드웨어 키 저장소는 실제 키를 포함하는 하드웨어가 있는 시스템이다. 이것은 일반적으로 개인 키가 정말로 프라이빗한 고급 보안 환경에서 수행된다. 파일 기반이나 데이터베이스 기반 키 저장소와 달리 키 저장소의 사본을 만들어 알려지지 않은 환경으로 전송하는 것은 불가능하다.

Some certificate authorities that are used to provide you with a server certificate for your website, also create the private keys for you (as-a-service). However, it is by definition no longer considered a private key. For all keystore types, you should keep the private key private and use a certificate signing request to order your signing or server certificates.

사용자에게 웹 사이트의 서버 인증서를 제공하는 일부 인증 기관에서는 사용자를 위한 개인 키(서비스형 키)를 만들기도 한다. 그러나 정의상 이는 더 이상 개인 키로 간주되지 않는다. 모든 키 저장소 종류는 개인 키를 프라이빗하게 유지하고 서명 또는 서버 인증서를 요청할 때 인증서 서명 요청을 사용해야 한다.

Managed keystores in operating system, browser and other applications

When you visit a website and your browser says that the certificates are fine, it means that the certificate used for the website is issued by a trusted certificate authority. But this list of trusted certificate authorities is managed. Some CA’s might be revoked or removed. These updates happen in the background when browser updates are installed. Not only the browser maintains a list of trusted certificate authorities, the operation system does so as well. And the Java runtime also has its own list which is kept in the cacerts file. Updates of the OS and Java JRE keep this list up to date. In corporate environments, these are usually maintained by the company and also contain company root certificates.

웹 사이트에 방문했을 때 브라우저가 인증서가 정상임을 알려주면, 해당 웹 사이트에 사용된 인증서가 신뢰할 수 있는 인증 기관에서 발급되었음을 의미한다. 하지만 신뢰할 수 있는 인증서 기관 목록은 관리되고 있고, 일부 인증 기관은 취소되거나 제거될 수 있다. 이러한 업데이트는 브라우저 업데이트가 설치될 때 백그라운드에서 일어난다. 브라우저 뿐만 아니라 운영 체제도 신뢰할 수 있는 인증서 기관 목록을 유지 관리한다. 또한 Java 런타임도 자체 목록을 가지고 있으며 이는 cacerts 파일에 저장된다. 운영 체제와 Java JRE의 업데이트로 이 목록이 최신 상태로 유지된다. 기업 환경에서는 이러한 목록이 일반적으로 회사에 의해 관리되며 회사의 루트 인증서도 포함된다.

Extra check for website certificates using DNS CAA records

Some companies inspect all or most internet traffic. Even the ones were you think you have an end-2-end secured connection. This works as follows. An employee opens a browser and googles some information. The browser will use https and go to the site of google. The link looks real and the lock is shown in the browser. However, if you would inspect the certificate, you might notice that it has been issued by one of your companies root CA’s! So you have established an end-2-end secure connection with a server of your company, and that server has the secure connection with google. In order to prevent such man in the middle connections to your server, modern browsers now will also check the DNS CAA records to see whether or not a certain issuer is allowed for a certain website.

어떤 회사들은 인터넷 트래픽 대부분을 검사한다. 심지어 사용자가 생각하기에는 처음부터 끝까지 안전하게 보호된 환경이라도. 이러한 과정은 다음과 같이 이루어진다. 직원이 브라우저를 열고 구글에서 정보를 검색한다. 브라우저는 HTTPS를 사용해 구글 사이트로 이동하고, 브라우저에는 연결이 안전하다는 것을 나타내는 자물쇠 아이콘이 표시된다. 그러나 만약 그 사이트의 인증서를 자세히 검토한다면, 그 인증서가 회사의 루트 인증 기관(CA) 중 하나에 의해 발급되었음을 알게 될 수 있다. 이는 회사의 브라우저와 회사의 서버 간에 안전한 연결이 확립되었으며 해당 서버는 구글과 안전한 연결을 유지하고 있다는 것을 의미한다. 이런 종류의 중간자 공격 연결을 방지하기 위해 현대의 브라우저는 이제 DNS CAA 레코드를 확인하여 특정 사이트에 대해 특정 발급자가 허용되는지 여부를 검사한다.

Free certificates from Let’s encrypt

Let’s encrypt is a free, automated and open Certificate Authority. It allows you to create valid certificates for the websites that you control. By following and implementing a certain protocol, your identity is checked and a certificate will be issued. The certificates are free of charge and this is done to stimulate the use of authorised certificates and to lower the use of self-signed certificates on the internet. Certificates are valid for 90 days, so they need to be automatically renewed. (Which makes sure that the proof of identity/ownership also takes place frequently).

Let's Encrypt는 무료이고 자동화되고 개방된 인증 기관이다. 이를 통해 사용자가 제어하는 웹 사이트에 유효한 인증서를 생성할 수 있다. 특정 프로토콜을 따르고 구현함으로써 사용자의 신원이 확인되고 인증서가 발급된다. 인증서는 무료이며 이는 인터넷 상에서 공인 인증서의 사용을 장려하고 자체 서명 인증서의 사용을 줄이기 위해 제공되고 있다. 인증서는 90일 동안 유효하므로 자동으로 갱신되어야 한다(이는 신원과 소유권 증명이 자주 이루어지도록 한다).

Security Defaults

A big problem in all kinds of systems is the use of default configurations. E.g. default username/passwords in routers, default passwords for keystores, default unencrypted mode, etc.

모든 종류의 시스템에서 발생하는 큰 문제 중 하나는 기본 구성을 사용하는 것이다. 예를 들어 라우터의 기본 사용자 이름/비밀번호, 키 스토어의 기본 비밀번호, 기본 미암호화 모드 등을 사용하는 것이 있다.

Java cacerts

Did you ever changeit? Putting a password on the cacerts file has some implications. It is important when the trusted certificate authorities need to be protected and an unknown self signed certificate authority cannot be added too easily.

cacerts 파일의 암호를 변경한 적 있나? cacerts 파일에 암호를 설정하는 것에는 몇가지 함의가 있다. 신뢰할 수 있는 인증 기관을 보호해야 하며, 알려지지 않은 자체 서명 인증 기관이 너무 쉽게 추가되지 않아야 한다.

Protecting your id_rsa private key

Are you using an ssh key for GitHub and or other sites and are you leaving it unencrypted on your disk? Or even on your cloud drive? By default, the generation of an ssh key pair leaves the private key unencrypted. Which makes it easy to use and if stored in a place where only you can go, it offers sufficient protection. However, it is better to encrypt the key. When you want to use the key, you would have to provide the password again.

GitHub 및 기타 사이트에서 SSH 키를사용하는데, 암호화 되지 않은 채로 디스크에 남겨두고 있나? 심지어 클라우드 드라이브에도? 기본적으로 SSH 키 쌍 생성 시 개인 키는 암호화되지 않은 상태로 남게 된다. 이는 사용이 쉽고 오직 개인이 액세스 할 수 있는 곳에 저장된다면 충분히 보호할 수 있다. 그러나 키를 암호화 하는 것이 좋다. 키를 사용하려면 다시 암호를 제공해야 한다.

SSH username/password to your server

When you are getting a virtual server from some hosting provider, there are usually a lot of not so secure defaults. One of which is that ssh to the server runs on the default port 22 and allows username/password attempts. One of the first things you should do, is to change the configuration that you cannot ssh as user root, and you cannot ssh using username/password, but only with a valid and strong ssh key. If not, then you will notice continuous brute force attempts to login to your server.

호스팅 제공 업체로부터 가상 서버를 받을 때 보안에 취약한 기본 설정이 많다. 그 중 하나는 서버로의 SSH가 기본 포트 22에서 실행되며 사용자 이름/비밀번호로 접근하려는 시도를 허용한다는 것이다. 첫 번째로 할 일 중 하나는 사용자 root로 SSH 접근을 할 수 없도록 하고 사용자 이름/비밀번호를 이용해 SSH에 접근할 수 없도록 구성을 변경하는 것이다. 그렇지 않으면 지속적으로 무차별 대입 공격을 받을 것이다.

Assignment

In this exercise you need to retrieve a secret that has accidentally been left inside a docker container image. With this secret, you can decrypt the following message: U2FsdGVkX199jgh5oANElFdtCxIEvdEvciLi+v+5loE+VCuy6Ii0b+5byb5DXp32RPmT02Ek1pf55ctQN+DHbwCPiVRfFQamDmbHBUpD7as=.
You can decrypt the message by logging in to the running container (docker exec …) and getting access to the password file located in /root. Then use the openssl command inside the container (for portability issues in openssl on Windows/Mac/Linux) You can find the secret in the following docker image, which you can start as:

docker run -d webgoat/assignments:findthesecret

echo "U2FsdGVkX199jgh5oANElFdtCxIEvdEvciLi+v+5loE+VCuy6Ii0b+5byb5DXp32RPmT02Ek1pf55ctQN+DHbwCPiVRfFQamDmbHBUpD7as=" | openssl enc -aes-256-cbc -d -a -kfile ....

Post Quantum Crypto

Quantum computers are here and getting more power in available qubits each year. Quantum computers are and will be capable of decrypting information that was encrypted with algorithms that were thought to be safe. For some years now, a lot of encrypted communication using quantum vulnerable cryptography is being recorded. This information will be decrypted when the quantum computers are powerful enough. Even though the information may be old, it still could contain valuable information that can be misused. Besides the fact that some private information will be known to parties it was not intended for.

양자 컴퓨터는 이미 우리 주변에 있으며 연간 사용 가능한 큐비트의 파워가 더 높아지고 있다. 양자 컴퓨터는 예전에는 안전하다고 여겨졌던 알고리즘으로 암호화된 정보를 해독할 수 있는 능력을 갖고 있으며 앞으로도 그 능력은 계속해서 증가할 것이다. 여러 해 동안 양자 취약 암호화를 사용한 암호화 통신이 많이 기록되어 있다. 양자 컴퓨터가 충분히 강력해지면 이 정보는 해독될 것이다. 정보가 오래 되었더라도 가치 있는 정보가 포함되어 있을 수 있으며 이는 오용될 수 있다. 또한 일부 개인 정보가 의도되지 않은 당사자들에게 알려질 수도 있다.

Mathematics has answers for the post quantum era. New cryptography is already available and should be used NOW in order to minimize threats.

수학은 포스트 양자 시대에 대한 해결책을 가지고 있다. 새로운 암호화 기술이 이미 존재하고 있으며 현재 사용되어야 한다. 이는 위협을 최소화하기 위한 것이다.