2021年6月Linux Magazine：探索GPIO、JSON深潜与后量子加密

需积分: 9 157 浏览量更新于2024-07-09 收藏 15.31MB PDF 举报

"Linux Magazine USA Issue 247 June 2021.pdf" 本期的《Linux Magazine》杂志（2021年6月刊）涵盖了多个IT领域的热点话题，特别关注了开源操作系统Linux及其相关技术。以下是对主要内容的详细解读： 1. **GPIO Hands-On Guide**：GPIO（General Purpose Input/Output）是许多嵌入式系统和单板计算机（如Raspberry Pi）中的一个重要特性，允许用户通过编程控制硬件接口。这篇文章可能深入介绍了GPIO的工作原理、如何配置和使用GPIO，以及在实际项目中的应用实例。 2. **JSON Deep Dive**：JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，广泛用于Web服务和API。深潜JSON主题可能涵盖了JSON的语法、解析与生成、最佳实践以及在不同编程语言中的使用技巧。 3. **DTLS Encryption over UDP**：DTLS（Datagram Transport Layer Security）是基于UDP的应用层安全协议，类似于TCP上的TLS。文章可能讨论了DTLS如何提供端到端的安全通信，特别是在物联网设备和实时通信场景中的应用。 4. **Post-Quantum Encryption**：随着量子计算的发展，传统加密算法可能面临被破解的风险。这一部分可能探讨了量子计算对隐私和安全的影响，以及后量子加密技术的发展，如格密码和基于数学难题的新加密算法。 5. **Maddog explores the history of text editors**：Maddog，即著名Linux倡导者Dr. John P. "Maddog" Hall，可能在这篇文章中回顾了文本编辑器的历史，从早期的EDT到现代的Vim、Emacs等，以及它们在Linux世界中的重要性。 6. **Obsidian: Nifty note and knowledge tool**：Obsidian是一款流行的个人知识管理系统，它利用链接笔记的概念来建立知识网络。文章可能介绍了Obsidian如何帮助用户组织信息，提高学习和工作效率。 7. **Will privacy survive quantum computers?**：随着量子计算的进步，隐私保护成为了热议的话题。这部分可能讨论了量子计算对现有隐私保护措施的挑战，以及未来可能的解决方案。 8. **FOSS PICKS**：这部分通常推荐一些优秀的自由和开源软件工具，可能是各种用途的实用工具，包括开发工具、生产力应用和系统管理软件等。 9. **Heavenly Free Tools!**：这部分可能列出了本月的精选免费工具，这些工具不仅功能强大，而且完全免费，适合个人和企业使用。此外，杂志还附带了一张免费DVD，其中可能包含了最新的Linux发行版和其他开源软件的试用版本，供读者探索和学习。这期《Linux Magazine》提供了丰富的Linux和开源技术内容，涉及从底层硬件接口到高级安全协议，再到个人知识管理和未来科技趋势的广泛讨论。无论是开发者、系统管理员还是对开源技术感兴趣的读者，都能从中获得宝贵的知识和见解。

JUNE 2021 ISSUE 247 LINUX-MAGAZINE.COM | LINUXPROMAGAZINE.COM

Kernel News

NEWS

[…]

“Kernel is now very verbose, so impor-

tant messages during bootup scroll away.

It is way bigger deal when you can no

longer get to them using shift-pageup.

“fsck is rather verbose, too, and there’s

no easy way to run that under X termi-

nal… and yes, that makes scrollback very

useful, too.”

Pavel put his money directly where his

mouth was, saying, “If it means I get to

maintain it… I’m not happy about it but

that’s better than no scrollback.”

Adam Borowski felt Pavel’s cry of

pain. Adam unleashed his own tor-

mented howl of “I concur,” lamenting,

“this a serious usability regression for

regular users.”

Adam pointed out that “without some

kind of scrollback, there’s no way of

knowing why eg. your rootfs failed to

mount (there was some oops, but its rea-

son was at the beginning…). Or, any

other problem the user would be able to

solve, or pass the error messages to

someone more knowledgeable.”

He also said to Linus:

“I also wonder why did you choose to

remove softscrollback which is actually

useful, yet leave hardscrollback which

doesn’t come to use on any non-ancient

hardware:

* on !x86 there’s no vgacon at all

* on x86, in-tree drivers for GPUs by

Intel, nVidia and AMD (others are dead)

default to switching away from vgacon

* EFI wants its own earlycon

”… thus, the only niche left is nVidia

proprietary drivers which, the last time I

looked, still used CGA text mode.”

Finally, to Pavel’s willingness to main-

tain the code in question, Adam re-

marked, “That’d be greatly appreciated.

There are also some simplifications/ re-

writes that could be done, like getting rid

of redundant 1-byte/ 4-byte storage (or

even the code for 1-byte…). Hard scroll-

back could be axed altogether (it pro-

vides only a small amount of scroll).

Etc….”

Throwing his lot in with the rebellious

Adam and Pavel, Maciej W. Rozycki con-

firmed that “For the record I keep using

the console scrollback all the time, and

FWIW I have gone through all the hoops

required to keep using VGA hardware

emulation and its console text mode

with my most recent laptop, which is a

ThinkPad P51; no longer manufactured,

but still hardly an obsolete device by to-

day’s standards I believe.” He therefore

concluded that “no, it’s not that nobody

uses that stuff anymore, and not with

obsolete hardware either.”

At that point, the matter rested and

several months passed. Then, as if no

time whatsoever had passed, Phillip Susi

replied to Pavel, “Amen! What self re-

specting admin installs a gui on servers?

What do we have to do to get this back

in? What was so buggy with this code

that it needed to be removed? Why was

it such a burden to just leave it be?”

To which Linus replied:

“It really was buggy, with security im-

plications. And we have no maintainers.

“So the scroll-back code can’t come

back until we have a maintainer and a

cleaner and simpler implementation.

“And no, maintaining it really doesn’t

mean ‘just get it back to the old broken

state’.

“So far I haven’t actually seen any

patches, which means that it’s not com-

ing back.”

Philip asked if there was any more in-

formation available. He said, “I can’t try

to fix it if I don’t understand what is

wrong with it. Are there any bug reports

or anything I could look at?”

Meanwhile, Daniel Vetter was not

going to let scrollback return without a

fight. In addition to the problems Linus

had identified, Daniel said, “on anything

that is remotely modern […] there’s a

pile more issues on top of just the scroll-

back/ fbcon code being a mess.” He con-

tinued:

“Specifically the locking is somewhere

between yolo and outright deadlocks.

This holds even more so if the use case

here is ‘I want scrollback for an oops’.

There’s rough sketches for how it could be

solved, but it’s all very tricky work.

“Also, we need testcases for this, both

in-kernel unit-test style stuff and uapi

testcases. Especially the full interaction

on a modern stack between /dev/ fb/ 0, /

dev/ drm/ card0, vt ioctls and the console

is a pure nightmare.

“Altogether this is a few years of full

time hacking to get this back into shape,

and until that’s happening and clearly

getting somewhere the only reasonable

thing to do is to delete features in re-

sponse to syzkaller crashes.”

At this point, Greg Kroah-Hartman

piled in, saying, “Along with what

Daniel has already pointed out, just

look at all of the old syzbot reports for

the code in this area. Try fixing one of

those reports in an older kernel to give

yourself an idea of the issues involved.

Best of luck!”

Philip was utterly unwilling to let this

go, however. And when Geert Uytterho-

even offered some comments on the

overall situation, Philip said, “Judging

from some of the comments in the code,

it looks like you were one of the original

authors of fbcon?” And Geert replied,

“Indeed, a looooong time ago….”

The two of them embarked on an im-

plementation discussion. Philip said he

was willing to try to rewrite scrollback

from scratch if that was what it took,

and he proposed some ideas about how

to do that. And Geert replied:

“There are multiple ways to implement

scrolling:

1. If the hardware supports a larger vir-

tual screen and panning, and the virtual

screen is enabled, most scrolling can be

implemented by panning, with a casual

copy when reaching the bottom (or top)

of the virtual screen. This mode is (was)

available on most graphics hardware

with dedicated graphics memory.

2. If a 2D acceleration engine is avail-

able, copying (and clearing/ filling) can

be implemented by rectangle copy/ fill op-

erations.

3. Rectangle copy/ fill by the CPU is al-

ways available.

4. Redrawing characters by the CPU is

always available.

“Which option was used depended on

the hardware: not all options are avail-

able everywhere, and some perform bet-

ter than others.”

Several people joined the discussion,

but no patches seemed to come out of it.

Reimplementing this feature seems, on

the one hand, like something a fair num-

ber of people want badly enough to do

just about anything for it and, on the

other hand, like something that’s very

hard to get right. And Linus doesn’t

seem inclined to accept any patches that

don’t actually get the thing right.

Will it come back? It seems like a

fairly large mountain to climb for a fea-

ture that is only really useful for kernel

developers debugging kernel code. And

yet, it does seem to have a special place

in the hearts of a fair number of those

kernel developers. Time will tell.

nnn

Quantum computers and the quest for quantum-resilient encryption

Entangled Secrets

The encryption methods we use today are no match for tomorrow’s quantum computers.

We’ll show you why and what’s ahead for cryptography in the post-quantum era.

By Stefan-Lukas Gazdag, Sophia Grundner-Culemann, Tobias Guggemos, Tobias Heider, and Daniel Loebenberger

ncryption is an everyday part of life on today’s Internet. En-

cryption protocols facilitate virtual private networks (VPNs),

protect corporate secrets, and validate banking transactions.

Encryption is also the secret sauce behind technologies such

as digital signatures and blockchain. The beauty of encryption is

that, even if an observer intercepts the transmitted data, the original

contents of the message remains hidden from view.

End users and corporations alike have come to depend on encrypted private

communication over public networks, but many experts believe the way we think

about encryption today will have to change if we want our secrets to stay secret.

Cryptographers are looking ahead for a new form of encryption that will meet the

needs of the post-quantum era.

The Problem

A quantum computer is a computer that is designed to exploit the mysterious features

of quantum mechanics. The basic unit of a conventional computer is binary (0 or 1). A

quantum computer, on the other hand, is built around the quantum bit, or qubit,

which assumes multiple states simultaneously.

To fully understand the nuances of quantum computing [1], you would need a PhD

in physics or computer science (or both), but as a quick illustration, Figure 1 shows a

classical bit on the left with two states, zero or one. A qubit (right, represented by a

Bloch sphere), can also represent values in between through what is known as super-

position, such as a 1 with 65 percent probability and a 0 with 35 percent probability.

If you mix up several qubits so that they influence each other, different results can

occur, each with a specific probability. This strange but powerful feature lets quan-

tum computers solve certain mathematical problems much more quickly than a con-

ventional computer.

Quantum computers

have been theorized for

many years, but the tech-

nology is still at the early

stages of development. A

few test systems exist

today, but the kind of

large-scale, production-

ready quantum comput-

ing power necessary to

implement the ideas dis-

cussed in this article are

still a few years away.

However, the experts be-

lieve the time of the

quantum computer will

come, and it make sense

Figure 1: Classical bits (left) versus quantum

bits (right).

COVER STORY

JUNE 2021 ISSUE 247 LINUX-MAGAZINE.COM | LINUXPROMAGAZINE.COM

Quantum Computing and Encryption

for the IT industry to prepare.

A quantum computer could the-

oretically solve any problem you can

solve with a conventional computer, but the theorized game-

changing efficiency that speeds up solution by orders of magni-

tude will only work for certain types of problems that can be

addressed using specialized quantum algorithms that exploit

the power of superposition and qubits.

For example, some popular encryption methods use a key

that is a product of prime numbers. The fact that the number

15 is the result of multiplying the two prime factors 3 and 5 is

easy to deduce for humans as well as computers, but a number

like the one in Listing 1 is difficult for even a computer to re-

duce to prime factors. The 309-digit number in Listing 1 once

carried a US$100,000 prize for anyone who could factor it. The

contest ran from 2001 to 2007, and as of the time the contest

ended, no one had claimed the prize [2]. Computer scientists

have continued to work on the RSA Factoring Challenge num-

bers even after the contest ended, and to this day, no one has

found the prime factors for the number in Listing 1, which is

known as RSA-1024.

A message properly encrypted with a huge numbers like

the one in Listing 1 poses a formidable challenge for a poten-

tial eavesdropper working with a conventional computer sys-

tem. If you know the secret (in this case, the prime factors)

the contents is quite trivial to decrypt, but if you don’t know

the secret, the message is effectively indecipherable.

However, encryption methods based on integer factorization

problems of this type are far more vulnerable to attack using a

quantum algorithm. According to cryp-

tography experts, Shor’s algorithm [3],

which was created by the mathematician

Peter Shor in 1994, could radically re-

duce the time needed to factor large

numbers.

Other encryption techniques rely on methods that mathema-

ticians refer to with names like the discrete logarithm prob-

lem or the elliptic-curve discrete logarithm problem, both

of which are also susceptible to attack using

quantum techniques.

Symmetric

Symmetric key encryption (where the data is

encrypted and decrypted using the same key) is

the most efficient means for achieving private com-

munication on the Internet – if you can solve the key

distribution problem. Even some procedures that begin

with an asymmetric key exchange actually use symmetric

encryption for communication and just employ an asym-

metric process to communicate the symmetric session key.

The most popular symmetric technique in use today is Ad-

vanced Encryption Standard (AES).

Symmetric encryption is subject to attack using quantum

techniques; however, algorithms such as AES do appear to

have some capacity to respond – at least in the near term. The

most efficient generic attack by quantum computers on sym-

metric methods is the Grover algorithm, which was developed

by Lov Grover in 1996. The Grover algorithm speeds up mind-

less brute-force checking of all possible keys. Classically, prob-

ability theory says that you have to test half of all possible keys

on average. However, even in the worst case, the Grover algo-

rithm requires no more tests than the square root of the num-

ber of all possibilities.

The Grover algorithm could thus reduce the bit security by

half. In other words, a 128-bit encryption key would provide

only the security level of 64-bit encryption in a quantum con-

text. If you double the key length, you get back to the original

security level – unattractive, but not technically difficult to im-

plement. In practice, this means that wherever AES-128 is

used, for example, you would need to upgrade to AES-256 for

equivalent security; or, in the case of hash processes, you

would need to upgrade from SHA-256 to SHA-512.

Asymmetric

The security of asymmetric methods, on the other hand, is

based on complex mathematical problems such as factoring

large numbers or finding discrete logarithms. For sufficiently

large numbers, this kind of encryption is practically impossible

to solve using classical computers, but quantum computers will

have a much better chance. Shor’s algorithm provides exponen-

tial speed-up for several asymmetric encryption methods on a

quantum computer. This speed-up allows the computation of

keys of virtually arbitrary length in a meaningful amount of time

and makes all widely used asymmetric algorithms, such as RSA,

Diffie-Hellman, DSA, and variants based on elliptic curves

(ECDH, ECDSA) vulnerable.

The potential obsolescence of the critical asymmetric algo-

rithms that underpin today’s Internet economy is one of the

1350664108659952233496032162788059699388814756056670275244851438515265106048595338

3394028715057190944179820728216447155137368041970396419174304649658927425623934102

0864383202110372958725762358509643110564073501508187510676594629205563685529475213

500852879416377328533906109750544334999811150056977236890927563

Listing 1: RSA-1024 Challenge

COVER STORY

Quantum Computing and Encryption

LINUX-MAGAZINE.COM | LINUXPROMAGAZINE.COM ISSUE 247 JUNE 2021

example, has been known since 1978 and remains unbroken

since then. However, the McEliece technique requires the

exchange of a public key that weighs in at around 1MB,

which has made the cryptosystem unattractive thus far.

Other better alternatives exist for creating signatures: Hash-

based signatures are already well understood and ready for

use. One interesting area is isogenies [4] on supersingular

elliptic curves [5] (not to be confused with classical cryptog-

raphy based on elliptic curves). However, research on this

approach has only been going for a few years, and so many

questions still remain.

Some experts point to the benefits of a hybrid approach that

would incorporate multiple procedures: If several of the proce-

dures are used in parallel, the security of the overall system is

based on all the procedures used, which spreads the risk if one

of the methods is broken. In this context, experts speak of

crypto-agility, a term that encompasses easy sharing of proce-

dures, an easy way to respond to security incidents, and appro-

priate mitigation of incidents.

This hybrid approach seems relatively easy to implement

for a task such as software updates. The update mechanism

is modified such that, in addition to checking a classical sig-

nature, it also checks a second, quantum-resilient signature.

The overhead is then limited to the additional signatures

and verification times.

VPNs

VPNs are an important part of today’s networks, and en-

cryption is essential to the privacy provided by a VPN. The

protocols most commonly used with VPNs are not well pre-

pared for attacks by quantum computers, and even some of

the quantum-resilient alternatives are not well suited to use

in VPNs. For example, the 1MB public key required by the

quantum-resilient McEliece’s method is 2,000 times bigger

than what is currently required with today’s protocols. This

also affects software development – a programmer cannot

allocate an arbitrary amount of memory on a system. In

other words, software that was written for the data sizes

that are common today (or in the past) may now need to be

adapted for the new methods.

In the case of the IPsec VPN protocol, there is broad con-

sensus that – as long as no suitably powerful quantum com-

puter exists – you merely need to add methods that are quan-

tum-resilient, but you do not yet need to replace the classical

methods. Based on this approach, initial solutions have al-

ready been discussed for the Internet Key Exchange v2

(IKEv2) protocol, which is widespread in IPsec and laid down

in the form of two Internet drafts currently under review.

These drafts specify how additional messages can be ex-

changed in the protocol: The keys of most quantum-resilient

alternatives turn out to be too large to be exchanged together

with the underlying Diffie-Hellman exchange in a message

without exceeding the maximum size of the initial message.

(The maximum size is not just determined by the protocol

but is also dependent on external parameters of the network,

such as the Maximum Transmission Unit or MTU.)

Therefore, between the initial handshake, from which the con-

nection is secured using a session key derived from Diffie-Hell-

man for AES, and the authentication step, you need to insert

reasons why cryptographers are working ahead to ensure that

quantum-resilient alternatives are in place before quantum

computers emerge from the laboratory.

Quantum-Resilient Alternatives

Production-ready quantum computers are still several years

away. Stop-gap measures such as increasing key lengths and

tweaking handshake procedures might work for a while, but

eventually, the world will need a whole new class of encryp-

tion methods.

Today’s security protocols are usually optimized for a spe-

cific procedure (e.g., a specific key exchange such as the Dif-

fie-Hellman key exchange). Replacing this procedure was

never intended; therefore, the protocol was not modularized

accordingly. Designing the protocol around the encryption

improves the efficiency of communication, and it also implic-

itly rules out certain attacks; however, the structure of the

legacy protocol might complicate your efforts to migrate to a

new encryption method.

Cryptographers are exploring several potential techniques for

quantum-resilient encryption. One promising alternative is

based on the concept of lattices. In a two-dimensional grid

(Figure 2), it is comparatively easy to see which grid point

(red) an arbitrarily set point (purple) is closest to. In a multidi-

mensional grid, this becomes computationally very difficult. If

the grid points symbolize all possible messages, a shifted point

could represent the encrypted message. The receiver, who has

precise knowledge of the grid, will find the next point with

comparative ease. An attacker without sufficient information

would have a hard time. Therefore, grids enable efficient en-

cryption and signature procedures. Although it is very difficult

to find reliable parameters, it is believed that this type of proce-

dure is one of the most promising.

A quantum-resilient encryption method could also be built

around error-correcting codes. McEliece’s cryptosystem, for

Figure 2: Multidimensional lattices can serve as

the starting point of quantum-resilient encryption

schemes.

COVER STORY

Quantum Computing and Encryption

JUNE 2021 ISSUE 247 LINUX-MAGAZINE.COM | LINUXPROMAGAZINE.COM

剩余101页未读，继续阅读

医生的托马斯

粉丝: 28
资源: 7

2021年6月Linux Magazine：探索GPIO、JSON深潜与后量子加密

最新资源