Stuff stuff

xbox remote play: ios/ipados에서 xbox 로고 표시된 후 검은 화면만 나오는 경우

anerdinaserver — Sat, 26 Nov 2022 14:07:02 +0900

xbox cloud gaming이 아닌 xbox remote play는 개인 소유 xbox에 원격으로 접속해 사용하는 기능입니다.

ios/ipados에서 xbox 앱을 이용해 remote play를 하는 경우, xbox 로고 표시 된 다음 검은 화면만 표시되는 경우가 있습니다.

특히 xbox와 다른 네트워크에서 접속하는 경우 자주 발생합니다.

해결 방법은, xbox와 같은 네트워크에서 접속하면 화면이 잘 나오기 때문에, 간단히 vpn을 이용해 xbox와 같은 네트워크로 연결한 다음 remote play를 하면 됩니다.

ps remote play: ios/ipados에서 80001fff 오류

anerdinaserver — Sat, 26 Nov 2022 14:02:14 +0900

아이폰이나 아이패드에서 ps remote play 앱으로 연결 시 80001fff 오류가 발생하는 경우, 다음과 같이 해결할 수 있습니다.

무선 컨트롤러 전원을 끈다.
ps remote play 앱으로 ps에 원격 접속한다.
무선 컨트롤러 전원을 켜 페어링한다.

무선 컨트롤러가 연결된 상태면 발생할 수 있는 문제로 보입니다.

iOS에서 Xbox Cloud Gaming 좌상단 메뉴와 하단바 가리기

anerdinaserver — Fri, 18 Nov 2022 00:36:46 +0900

Xbox Cloud Gaming 게임 화면에서는 좌상단에 HUD가 표시됩니다.

CSS Selector를 이용해 HUD를 가리는 방식입니다. 유니콘과 같은 광고 차단 앱이 필요합니다.

구글 스테디아가 처음 나올 때만 하더라도, 게임 스트리밍이 요즘처럼 널리 사용될 수 있을지 예상하지 못했습니다. 아무래도 레이턴시와 반응 속도 문제 때문에 쓸모없을 것이라고 생각했습니다.

지금은 Xbox Cloud Gaming, 지포스 나우와 여러 게임 스트리밍 서비스가 생겼고 많은 사람들이 잘 사용하고 있는 것 같습니다. 저도 Xbox Cloud Gaming과 지포스 나우를 구독하고 있습니다. 지원하는 게임이 한정돼 있지만, 지원하는 게임들은 인터넷만 가능하다면 언제든 할 수 있다는게 매력적입니다.

클라우드 게이밍을 데스크톱에서도 자주 사용하지만, 아무래도 외출했을 때도 휴대폰이나 태블릿을 이용해 게임을 하고 싶은 것이 당연할 것입니다. 그 중에서도 항상 옆에 있는 휴대폰으로 접속하는 것이 자연스러울 텐데요, 요즘 어느 정도 플래그십에 가까운 휴대폰은 올레드를 사용하고 있기 때문에 고정 UI가 있는 게임을 할 때 신경이 쓰입니다. 이 게임 저 게임하면 고정 UI도 바뀌니 영향이 상대적으로 적겠지만, 게임 서비스에서 표시하는 메뉴와 같은 고정 UI는 모든 게임에서 동일하게 표시되기 때문에 영향을 계속 주게 됩니다.

물론 게임 서비스에서 일정 시간이 지나면 HUD가 안 보이게 해 주면 좋겠지만, 제가 사용하는 Xbox Cloud Gaming과 지포스 나우에서는 지원해주지 않고 있습니다. 그래도 어떻게든 가릴 수 있는 방법을 찾다가, Xbox Cloud Gaming에서는 가리는 방법을 알게 되었습니다. (지포스 나우는 메뉴도 리모트에서 미리 그려주는 것으로 보여, 로컬에서 손 대지 못하는 것으로 생각됩니다)

(유니콘 기준으로 작성했습니다)

Xbox Cloud Gaming 좌상단 메뉴 버튼 가리기

유니콘 앱에서, [설정] - [사용자 필터] 로 들어갑니다.

필터 입력창에, 아래와 같이 입력합니다.

xbox.com##[id='StreamHud']

Xbox Cloud Gaming 웹앱을 완전히 종료하고 다시 접속하면 좌상단 메뉴가 사라지게 됩니다:

좌상단 메뉴가 사라진 모습. 우상단의 메뉴 버튼은 터치 컨트롤의 일부입니다.

이 글을 작성하는 시점에는, 컨트롤러의 엑스박스 버튼을 누르면 메뉴가 나와서 게임 선택 화면으로 돌아갈 수 있었습니다:

지포스 나우도 자주 사용하고 있는데, 자체적으로 메뉴를 가릴 수 있는 방법을 만들어 주면 좋겠습니다. 물론 Xbox Cloud Gaming에서도 자체 지원해주면 정말 좋겠습니다. 저는 화면에 고정 UI 가 신경 쓰이기 때문에, 올레드 화면을 쓸 때는 이 방식으로 Xbox Cloud Gaming만 사용할 것 같습니다.

iOS에서 게임할 때 하단 바 가리기

쉽게 찾을 수 있는 정보이니, 간단하게 설정 방법만 같이 적습니다. 사용법 유도를 활성화하면 하단 홈 바가 가려집니다.

[설정] - [손쉬운 사용] - [사용법 유도] 와, [설정] - [손쉬운 사용] - [손쉬운 사용 단축키] 를 확인해 게임 화면에서 사용법 유도를 활성화하시기 바랍니다.

윈도우 탐색기에서 Onedrive 제거하는 프로그램

anerdinaserver — Mon, 5 Jun 2017 00:31:41 +0900

개요:

윈도우 탐색기에서

이것을 제거하는 프로그램입니다.

직접 작성했습니다.

사용법:

실행해서 저 버튼 누르시면 됩니다.

단순히 레지스트리 값만 1에서 0으로 바꿔주는 프로그램입니다.

아래 자료 참고하셔서 직접 수정하셔도 같은 효과입니다.

혹시 나중에 원드라이브 다시 사용하시려면 Restore 버튼 누르시면 됩니다.

이 프로그램은 다음 링크를 참조해서 작성했습니다.

참고한 자료:

https://www.tekrevue.com/tip/remove-onedrive-file-explorer-sidebar-windows-10/

윈도우10 64비트/32비트버전에서 작동 확인했습니다.

NoOnedriveFileExplorer.exe

Windows.Forms.OpenFileDialog와 WPF의 OpenFileDialog

anerdinaserver — Sat, 8 Apr 2017 12:45:20 +0900

OpenFileDialog는 닷넷에서 두 네임스페이스에 따로 같은 이름으로 정의되어 있다.

1. System.Windows.Forms.OpenFileDialog

2. Microsoft.Win32.OpenFileDialog

WPF를 이용할 때 파일 열기/저장하기 대화상자를 표시하려면 OpenFileDialog와 SaveFileDialog가 필요하다.

다만 WPF상태에서 Forms를 또 참조에 추가하는것도 자원 낭비이기 때문에 마이크로소프트에서 두 대화상자를 Microsoft.Win32 네임스페이스에 정의해 뒀다.

한 가지 알아둬야 할 점은 Forms에 있는 OpenFileDialog의 ShowDialog() 메서드는 DialogResult를 반환하지만 Win32의 OpenFileDialog의 ShowDialog() 메서드는 bool? 타입을 반환한다는 점이다.

또한 Forms에는 Open/Save 말고도 여러가지 자주 사용할만한 다이얼로그가 정의되어 있는 반면 Win32 에는 저 두 가지 대화상자만 있다.(적어도 CommonDialog에는)

WPF Binding과 INotifyPropertyChanged

anerdinaserver — Sat, 8 Apr 2017 12:12:13 +0900

WPF Binding과 INotifyPropertyChanged 노트

xaml에서 x:Name, DataContext, Content등의 속성을 이용해 바인딩을 할 때 사용하는 인터페이스이다.

Content에 바인딩할때 추가하는 Path 문자열은 DataContext에 설정된 객체의 Property이름과 일치해야 한다.

이 때 DataContext 객체는 INotifyPropertyChanged 인터페이스를 구현해야 하며,

해당 인터페이스는 System.ComponentModel 네임스페이스에 정의되어있다.

이 인터페이스는 PropertyChanged 이벤트를 구현하도록 하는 인터페이스이고 바인딩한 Path에 해당되는 Property의 set 메서드에서

PropertyChanged이벤트를 발생시키면 Property와 WPF Element의 양방향 바인딩을 만들 수 있다.

PropertyChanged이벤트는 이벤트이므로 첫 매개변수는 sender이고 두 번째 매개변수는 PropertyChangedEventArgs 객체이다.

PropertyChangedEventArgs는 마찬가지로 System.ComponentModel 네임스페이스에 정의되어 있으며 이름에서 알 수 있듯이

System.EventArgs를 상속받은 클래스이다. 따라서 딱히 특별할 것이 없는 이벤트이다.

DataContext는 바인딩하는 요소의 상위 요소에 적용해도 상속된다.

DataContext 속성을 자기 자신에게 지정할 경우 RelativeSource 구문에 Self를 사용하면 좋다.

바인딩을 통해 DataContext의 Property가 변경되면 바인딩된 요소의 해당 속성이 변경되고 반대로 요소의 해당 속성이 변경되어도 DataContext의 Property가 변경된다.

메모리상의 값과 UI를 간단하게 결합할 수 있다는 점에서 의미가 있는 기술이다.

GPG 서명하고 확인하기

anerdinaserver — Mon, 5 Dec 2016 20:55:00 +0900

이번 글에서는 서명을 하고 서명을 확인하는 방법을 알아보겠습니다.

지난 글에서 암호화는 받는 사람의 공개키를 이용해 하고 복호화는 받은 사람이 개인키를 이용해 한다고 했습니다.

서명은 반대로 서명자가 개인키로 서명하고 받은 사람이 서명자의 공개키로 서명을 확인합니다.

서명을 한 메시지나 파일이 서명을 한 이후 어떤식으로든 변경되면 서명 확인이 실패합니다. 따라서 자료가 의도치 않게 변경되었다는 것을 알 수 있게 됩니다.

서명이 일치하지 않는다는 것은 꼭 누군가가 자료를 악의적으로 변경했다는 것을 의미하지는 않습니다. 단순히 전송 과정에서 문제가 좀 있었던 것일 수도 있습니다. 하지만 중간에 뭔가 바뀌었다는 것은 알 수 있습니다. 이것이 서명의 목적입니다.

공개키를 들여오기할 때 키 지문을 잘 확인해야 한다고 했습니다. 그래야 받아온 공개키가 정말로 여러분이 공개키의 주인이라고 생각하는 사람으로부터 온 것인지 알 수 있기 때문입니다. 공개키의 출처를 믿는다면 서명 일치 여부도 믿을 수 있겠습니다. 믿는 키로부터의 서명이 확인된다면 이 키의 주인으로부터 받은 메시지와 자료 또한 신뢰할 수 있습니다.

디지털 서명은 또한 주고받은 메시지나 자료의 내용이 무엇이든 서명자가 직접 서명했다는 것을 부정할 수 없게 하는 효과가 있습니다. 이것 또한 알아두셔야 합니다. 즉, 디지털 서명은 해당 개인키의 주인이 이 메시지/자료를 만들었고 서명이 이루어진 시점에서 더 이상 수정이 이루어지지 않았다는 보증인 셈입니다. 다시 한 번 강조하지만 개인키를 잘 보호해야 하는 이유가 이것입니다. 처음에 마스터 키를 생성하고 바로 이어서 폐기 인증서를 생성하고 잘 보관하라고 했던 이유 또한 이것입니다. 만약 개인키가 못 쓰게 되거나 유출되면 즉시 폐기해야 합니다. 만약 해커가 개인키 파일과 암호를 손에 넣었다면 기본적으로 그 사람이 하는 일은 여러분이 하는 일이나 마찬가지가 되는 것이기 때문입니다.

또 한 번 강조합니다. 개인 키의 암호는 최대한 길고 예측하기 어렵게 설정하십시오. Diceware를 다시 한 번 추천합니다. 요즘 개인 컴퓨터의 성능으로도 짧은 암호는 생각보다 빨리 알아낼 수 있습니다.

서명하기

gpg로 하는 서명에 사용되는 옵션은 방식에 따라 (-s, --sign), --clearsign, 그리고 (-b, --detach-sign) 세 가지 종류가 있습니다.

-s, --sign

기본 사인 방식은 서명을 결과 파일 안에 집어넣고 자체적으로 압축을 합니다. 결과 파일은 압축을 하기 때문에 무조건 바이너리 형식입니다.

$ gpg2 -o signedmessage.txt.gpg --sign message.txt

이 방식으로 서명을 하면 원본 자료를 gpg로 복원을 해야 사용할 수 있다는 특징이 있습니다.

--clearsign

이 방식은 특히 텍스트 메시지를 서명할 때 유용합니다. 이메일, 문자로 메시지를 보내거나 게시판에 글을 올릴 때 서명을 하고 싶으면 이 옵션을 사용합니다. 메시지 자체는 서명 형식 안에 수정되지 않은 상태로 기록됩니다.

Clearsign을 한 메시지는 이렇게 생겼습니다:

$ gpg2 -o signedmessage.txt.asc --clearsign message.txt
...
$ cat signedmessage.txt.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

this is a secret message!
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJYRU3sAAoJEOTA4dVcFs1vyYgQAJ8vj7EjWCJUDEAWoAp3/AoH
s+B4ELtAu58fGM4g2T/CabBLtXdZIOuDvgZelZH938qvJKVxUd6Efpv3qvfuxCoA
mn9ubmARM3OmvFXbAb0tud/qRFnaTfFfCKBL3P5IIGDA8ai07Q0bubYS00CvUqbS
...
MqyjCfNuwPpWQfX4vXsEDxO+x1R7+WNCvaLsarTNV9lFLHw3U5C0bYUbylayqIKj
wYMbl+v7U4TpIBb/U8V37EZaoGJT20NYo/SHUGjfIYJOvFWapFxPOqN26RWqe4UO
aHBu+emEJDLsb6Vna5VD
=R9P+
-----END PGP SIGNATURE-----

-b, --detach-sign

위 두 방식의 서명은 원본 자료가 어떻게든 변환된다는 특징이 있습니다. 그래서 서명된 자료를 바로 사용하지 못 할 수 있습니다. 경우에 따라 이런 특징이 방해가 될 때가 있습니다.

Detached signature는 서명을 원본 메시지와 분리해서 따로 생성합니다. 따라서 서명을 확인한 뒤 원본 파일을 바로 사용할 수 있습니다. 자료가 실행 파일이나 워드 파일 등 서명 자료가 파일 안에 포함되어 있으면 곤란한 경우에 사용하면 좋습니다.

여러 웹 사이트에서 자료를 제공할 때 이 방식으로 자료에 서명을 해서 배포하고 있습니다. 해당 업체의 공개키를 가지고 있다면 서명 일치 여부를 확인할 수 있고 따라서 다운로드 받은 자료가 완전하다는 것을 알 수 있습니다.

또는 SHA–1과 같은 단방향 해시 값을 같이 게시하는 경우도 있습니다. 이 방식은 gpg를 이용하지는 않지만 자료의 완전성을 입증할 수 있는 또 다른 방식입니다. 이 또한 알아두시면 좋을 것 같습니다.

Detached signature는 이렇게 사용합니다:

$ gpg2 -o message.sig -b message.txt

이렇게 하면 message.sig 파일이 생성됩니다. 이 파일이 message.txt 파일에 대한 전자 서명입니다.

서명 확인하기

서명을 하는 방법을 알았으니 서명을 확인하는 방법을 알아보겠습니다.

서명을 확인하려면 --verify 옵션을 사용하면 됩니다.

--sign과 --clearsign으로 서명된 자료는 --verify 옵션으로 서명만 확인할 수도 있고, --decrypt 옵션으로 서명을 확인하고 동시에 자료를 원본으로 변환할 수도 있습니다.

이렇게 하면 서명 일치 여부만 알려줍니다:

$ gpg2 --verify signedmessage.txt.gpg

이렇게 하면 원본 파일을 생성하고 서명 일치 여부도 같이 알려줍니다:

$ gpg2 -o message.txt --decrypt signedmessage.txt.gpg

--detach-sig의 경우 원본 파일과 서명 파일이 함께 있어야 검증할 수 있습니다.

이렇게 서명 파일과 원본 파일 순서로 적어주면 됩니다:

$ gpg2 --verify message.sig message.txt

서명 확인 결과가 gpg: Good signature from와 같이 나오면 서명이 확인된 것입니다.

암호화와 서명은 동시에 할 수 있습니다. 예를 들면 이렇습니다:

$ gpg2 -aser John -r Park -r ... -o message.txt.asc message.txt

이렇게 하면 받는 사람은 복호화를 하면서 서명 일치 여부를 확인하게 될 것입니다.

이것으로 gpg의 가장 기초적인 사용 방법을 알아봤습니다. 지금까지 배운 내용으로도 충분히 gpg를 이용해 안전하게 자료를 주고받고 개인 자료를 암호화 할 수 있습니다.

다음 포스트부터는 키 서버를 통해 공개키를 배포하는 방법, 서브키 사용법, 키 id를 관리하는 방법, --edit-key 프롬프트 사용법 등을 다루도록 하겠습니다.

GPG 자료 암호화/복호화하기

anerdinaserver — Mon, 5 Dec 2016 17:48:55 +0900

이번 포스트에서는 자료를 암호화/복호화하는 방법을 알아보겠습니다.

앞선 포스트를 모두 따라했다면 현재 여러분의 키 링에는 적어도 본인의 개인키와 공개키가 들어 있을 것입니다. 친구나 다른 사람의 공개키가 저장되어 있을수도 있겠습니다.

비대칭 키를 이용한 암호화 과정에서 흔히 공개키를 열린 금고로 비유하곤 합니다. 이 금고에는 금고 주인만 열 수 있는 자물쇠가 걸려 있고 한 번 잠그면 금고 주인의 전용 열쇠가 아니면 열리지 않습니다.

자료를 암호화 할 때는 받는 사람의 공개키를 이용합니다. 받는 사람은 여러명이 될 수 있고 본인 스스로를 받는 사람 목록에 추가할 수도 있습니다.

받는 사람의 공개키로 자료를 암호화하면 받는 사람의 개인키로만 해독할 수 있습니다. 여러분이 자료를 암호화 할 때 본인을 받는 사람 목록에 적지 않으면 직접 암호화 한 자료라고 해도 복호화할 수 없습니다. 수신인의 개인키가 없기 때문입니다.

마찬가지로 다른 사람이 여러분의 공개키 하나로 자료를 암호화하면 쌍을 이루는 개인키를 갖고 있는 여러분 스스로만 그 자료를 복호화 해서 읽을 수 있습니다. 개인키를 잘 간수해야 하는 이유 중 하나입니다. 개인키가 유출되면 여러분만 보도록 암호화된 자료를 개인키를 입수한 사람도 볼 수 있게 되기 때문입니다.

이런 원리로 철수에게 비밀 메시지를 보내려면 철수의 공개키를 이용하고, 영희에게 비밀 자료를 보내려면 영희의 공개키를 이용하면 되는 것입니다. 철수가 여러분에게 자료를 보낼 때는 여러분의 공개키를 이용할 것입니다.

자료 암호화하기

gpg를 이용해 자료를 암호화하려면 --encrypt 옵션을 사용합니다. 짧은 표현은 -e입니다.

키 내보내기 과정에서와 같이 결과물을 파일로 내보내려면 --output, 또는 -o 옵션을 사용하면 됩니다.

마찬가지로 결과물을 아스키 문자 형태로 내보내려면 --armor, 또는 -a 옵션을 사용하면 됩니다.

받는 사람은 --recipient 또는 -r 옵션을 사용합니다. 이 옵션은 최소한 한 번은 사용되어야 하고 받는 사람마다 한 번씩 여러번 사용하면 됩니다.

암호화를 할 파일을 정하거나 간단하게 하나 만들고 실제로 암호화를 해 보겠습니다:

$ echo this is a secret message! > mysecret.txt
$ gpg2 -aer Biscuit -o mysecret.txt.asc mysecret.txt

이렇게 하면 mysecret.txt.asc 파일이 생깁니다. 내용을 보면 알아볼 수 없게 되어있는 것을 알 수 있습니다:

$ cat mysecret.txt.asc
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

hQIMA8vZzLznXZVLARAA4D6VXlR1DbYzu8zp6qUiO7s/0nNXaHeMtd0PMUlurzt6
5HZrzRPMT4Yi+87e6TfUnAG1utZwqBpjw2+Iytpip9kt00ySH8zAliQo9CU1lLlZ
...
WwFhMEZPa0aqrO0f7TOy9/lV/aNirUGFreaaP9+HklPHZWPfQ+duVyrwYf5CaCoC
jZ+QrqtDgp8/K9dj5IuhwSlkql3C0khPqFeMRv8FJU3g/WcJ7kDZ/uG+A3w=
=TWqD
-----END PGP MESSAGE-----

만약 받는 사람이 여럿이라면 이런식으로 하시면 됩니다:

$ gpg2 -aer Biscuit -r Ginger -r Ross ... -o mysecret.txt.asc mysecret.txt

그려면 명시된 수신자의 개인키 중 하나로 자료를 복호화 할 수 있습니다.

참고로 암호화된 자료를 받은 사람의 화면에는 복원 시 맞는 개인키가 발견될때까지 암호 입력 창이 표시됩니다. 따라서 한 수신자는 다른 수신자가 누구인지 알 수 있습니다. 경우에 따라 한번에 여러 명의 공개키를 이용해 암호화하거나 받는 사람마다 따로 암호화를 한 번씩 하면 되겠습니다.

자료 복호화하기

gpg로 자료를 복호화 할 때는 --decrypt 옵션을 사용합니다. 짧은 표현은 -d입니다.

$ gpg2 -o secretmessage.txt -d mysecret.txt.asc

gpg는 복호화를 위해 개인키를 사용해야 하기 때문에 개인키의 암호를 물어볼 것입니다. 입력하면 복호화되고 위 예제에서는 secretmessage.txt에 this is a secret message! 라는 내용이 복원됩니다. -o 옵션을 사용하지 않으면 그냥 터미널에 복호화된 내용이 표시됩니다.

리눅스/맥 사용자를 위한 팁

윈도우 커멘드를 개인적으로 사용하지 않고 있기 때문에 윈도우에서도 같은 일이 가능한지는 모르겠습니다. 하지만 bash/zsh등을 사용하는 분들이 쉘에서 간편하게 메시지를 암호화 하는 방법을 알려드리겠습니다.

이것은 gpg의 기능이 아니고 아마도 쉘마다 공통적으로 가능한 쉘 자체의 기능입니다.

암호화

$ gpg2 -aer Biscuit << 'EOF'
> This is a message
> EOF

복호화

마찬가지로 아스키 형태로 수신된 자료를 복호화 하려면:

$ gpg2 -o output.txt -d << 'EOF'
> -----BEGIN PGP MESSAGE-----
...
-----END PGP MESSAGE-----
> EOF

...

This is a message

수신된 암호문을 복사해서 붙여넣으면 됩니다. 메일 등으로 수신했을 때 간편하게 사용할 수 있습니다.

쉘 변수 확장을 사용하시려면 << EOF로 사용하시면 됩니다.

대칭 키 암호화

지금까지는 비대칭 키를 이용한 암호화에 대해 알아봤습니다. 하지만 경우에 따라 따로 암호 하나로 자료를 암호화해서 같은 암호로 해독하도록 하는 것이 편한 경우도 있을 수 있습니다. 이 경우를 위해 gpg로 대칭 키 암호화도 할 수 있습니다.

대칭 키 암호화는 --symmetric 옵션을 사용합니다. 짧은 표현은 -c입니다.

$ gpg2 -o secret.txt.gpg --symmetric secret.txt

이렇게 암호화된 자료는 공개키를 이용하지 않고 암호만으로 암호화되기 때문에 암호를 잘 관리해야 합니다. 특히 본인의 개인키 암호를 사용하지 않도록 주의하십시오.

참고로 gpg는 여러가지 암호화 방식을 지원합니다. --help 옵션을 사용하면 간단한 옵션 목록이 나오는데 상단 부분에 사용 가능한 암호화 방식의 목록이 같이 표시됩니다.

...
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
...

기본 값은 CAST5이고 modern 버전부터는 AES–128 방식이 기본으로 사용됩니다. 기본값이 존재하는 이유는 받는 사람의 gpg도 같은 암호화 방식이 지원되어야 하기 때문입니다.

물론 암호화 방식을 지정할 수도 있습니다. 예를 들어 AES256 방식으로 암호화를 하려면 --cipher-algo 옵션을 사용해서 이렇게 합니다:

$ gpg2 -o secret.txt.gpg --cipher-algo AES256 --symmetric secret.txt

적절히 강한 암호를 사용한다면 기본 값으로도 충분할 것입니다. 필요에 따라 지정해서 사용하십시오.

대칭 키 암호화의 가장 큰 단점이 암호 자체를 전달하는 것이 어렵다는 것입니다. 자료가 아무리 잘 암호화 되어도 암호가 유출되면 암호화의 의미가 없게 됩니다. 그래서 나온 방법이 비대칭 키 암호화입니다. 꼭 대칭키 암호화를 사용해서 통신하려면 암호 전달에 신경을 쓰시기 바랍니다. 자료는 대칭키로 암호화하고 암호를 비대칭키를 이용해 전달하는 방법도 있지만 개개인의 자료 전달에서는 그냥 비대칭 키를 이용하는 것이 좋겠습니다.

다음 포스트에서는 메시지나 자료에 서명을 하고 확인하는 방법을 알아보겠습니다.

GPG 공개키 주고받기

anerdinaserver — Mon, 5 Dec 2016 03:17:33 +0900

이번 포스트에서는 키를 관리하는 기본적인 방법을 알아보겠습니다.

키를 생성하면 개인키와 공개키가 쌍을 이뤄 생성됩니다. 또한 기본적으로 각 키는 사인용 주 키(Primary key)와 암호화용 하위키(Subkey)를 갖습니다. 서브키는 나중에 사용법을 따로 설명할 예정입니다. 지금 중요한 것은 키가 여러가지 구성 요소로 되어 있다는 것입니다. 여러가지 구성 요소가 모인 것을 키링(keyring)이라고 부릅니다. Keyring은 여러분의 개인키와 공개키, 다른사람의 공개키를 전부 저장하게 됩니다.

정리하자면 기본적인 keyring은 다음과 같이 구성됩니다:

Keyring
    - Key
        - Private key
            - Primary (사인용)
            - Sub (암호화용)
        - Public key
            - Primary (사인용)
            - Sub (암호화용)
    - Key
        - Public key (다른 사람의 공개 키)
        ...

Keyring은 여러개의 키를 가질 수 있고 각 키는 여러개의 서브키를 가질 수 있습니다. 마스터 키는 반드시 사인을 할 수 있어야 합니다. 서브키는 추가하거나 제거할 수 있습니다. 서브키는 사인용, 암호화용 모두 생성할 수 있습니다.

각 키에는 User ID가 포함됩니다. 아이디는 추가할 수 있지만 수정할 수는 없습니다.

Keyring의 키 목록

Keyring에는 여러 개인키와 공개키가 포함된다고 했습니다. 키 목록을 확인하려면 --list-keys 옵션을 사용합니다. 이 옵션은 공개 키의 목록을 표시합니다.

$ gpg2 --list-keys
pub   rsa2048/2F5DB256 2016-12-03 [SC]
uid         [ultimate] Infinite Cookies <infcookies@gmail.com>
sub   rsa2048/7EB1A92D 2016-12-03 [E]

pub은 공개 키를 의미합니다.
uid는 User ID를 의미합니다.
sub는 서브키를 의미합니다.
rsa2048과 같은 문구는 키의 종류와 길이를 의미합니다.
2F5DB256와 같은 문구는 키의 ID입니다. 각자 다릅니다.
[SC]와 [E]는 해당 키의 역할입니다.
- S: Sign(사인)
- C: Certificate(인증)
- E: Encryption(암호화)
[ultimate]는 해당 키에 대한 신뢰도를 의미합니다. 본인의 키이기 때문에 ultimate 단계로 되어 있습니다. 다른 사람의 키는 기본적으로 신뢰도가 존재하지 않고 marginal, full 등으로 설정할 수 있습니다.
--list-keys 뒤에 키의 아이디나 이메일 주소, 이름을 적으면 해당하는 키만 출력됩니다. 키를 구분할 때 적는 검색어를 keyspec이라고 하겠습니다.

개인 키의 목록을 보려면 --list-secret-keys 옵션을 사용합니다. 사용법은 --list-keys와 같습니다.

공개키의 역할

공개키는 아무에게나 공개해도 괜찮습니다. 특히 다른 사람과 메시지나 자료를 주고받기 위해서는 각자 서로의 공개키를 가지고 있어야 합니다.

공개키는 이런 경우에 사용됩니다:

공개키 주인에게 보낼 자료를 암호화
공개키 주인이 비공개키로 사인한 메시지와 자료의 사인 확인

여러분은 공개키 자체에 이런 일을 할 수 있습니다:

공개키의 인적사항(User ID) 확인하고 사인하기
공개키 내보내기/받아오기
공개키 폐기하기 등

공개키 내보내기

다른 사람이 여러분에게 뭔가 암호화해서 보내려면 여러분의 공개키를 갖고 있어야 합니다. 공개키는 --export 옵션을 사용해서 내보냅니다.

$ gpg2 --output pubkey.gpg --export keyspec

이렇게 입력하면 pubkey.gpg 파일이 생성됩니다. 이 파일은 사람이 읽을 수 없는 바이트로 구성되어 있습니다. 이 파일을 주고 받아도 되지만 경우에 따라 불편할 수 있습니다. 예를 들어 문자 메시지로 공개 키를 보내거나 게시판을 통해 공개키를 주고받는 경우 등이 있겠습니다.

gpg의 모든 출력 관련 옵션에는 -a 또는 --armor 옵션을 추가할 수 있습니다. 이 옵션을 추가하면 알파벳과 숫자등으로 표현된 결과 파일이 생성됩니다.

$ gpg2 -ao pubkey.asc --export keyspec

-o는 --output의 짧은 형태입니다. 이렇게 생성된 파일을 보면 다음과 비슷하게 되어 있습니다.

이 파일이나 내용을 보내줘도 동일하게 공개키를 주고받을 수 있습니다. 필요에 따라 적절한 형태로 출력시켜 사용하십시오. 일반적으로 -a 옵션을 사용한 경우 결과 파일의 크기가 아주 약간 더 큽니다.

공개키 들여오기

여러분이 다른 사람에게 자료를 암호화해서 보내려면 받는 사람의 공개키가 필요합니다. 방금 여러분이 한 것과 같이 상대방도 자신의 공개키를 내보내기 해서 보내올 것입니다. 그러면 여러분은 받은 키를 여러분의 keyring에 저장합니다.

들여오기는 --import 옵션을 사용합니다.

$ gpg2 --import pubkey-John.asc

잘 들어왔는지 --list-keys로 확인합니다.

$ gpg2 --list-keys
/home/infcookies/.gnupg/pubring.kbx
-----------------------------------
pub   rsa2048/2F5DB256 2016-12-03 [SC]
uid         [ultimate] Infinite Cookies <infcookies@gmail.com>
sub   rsa2048/7EB1A92D 2016-12-03 [E]

pub   rsa4096/0F3FBF20 2016-12-04 [SC]
uid         [ unknown] Biscuit John <goodbiscuit@gmail.com>
sub   rsa4096/E75D954B 2016-12-04 [E]

새로 들여온 공개키의 uid의 신뢰도는 unknown입니다. 이것은 기본값이고 지금부터 들여온 공개키의 신뢰도를 결정해야 합니다.

키의 신뢰도는 다음과 같이 결정합니다:

개인적으로 확인: 전화 통화나 직접 만나서 키의 지문(fingerprint)를 확인
타인을 통해 확인: 충분한 수의 믿을 수 있는 사람들이 확인. 이 방식을 Web of Trust라고 부릅니다.
확인 후 본인 개인키로 사인

지금은 개인적으로 확인할 수 있는 상황을 가정합니다. 예를 들어 친구와 만나 공개키를 주고받은 후 키 지문을 확인하면 정확히 필요한 키를 받았다는 것을 확신할 수 있습니다.

키 지문은 --fingerprint 옵션을 사용하면 볼 수 있습니다.

$ gpg2 --fingerprint Biscuit
pub   rsa4096/0F3FBF20 2016-12-04 [SC]
      Key fingerprint = DD56 E74D A77D E1C3 46AC  AC57 DE4E 1192 0F3F BF20
uid         [ unknown] Biscuit John <goodbiscuit@gmail.com>
sub   rsa4096/E75D954B 2016-12-04 [E]

Key fingerprint = 다음에 나열되는 값이 이 키의 지문입니다. 직접 만나거나 통화를 통해 이 지문 값의 모든 자리수를 확인해서 일치하면 이 키는 믿을 수 있는 키입니다. 특히 0, O, o, I, i, l, 1 등과 같이 비슷해 보이는 글자를 주의해서 보십시오. 프로그래머들이 사용하는 고정폭 폰트를 사용하면 이런 문자들이 잘 구분되어 보입니다. 폰트를 설치해서 사용하는 터미널 등에서 사용하면 좋습니다.

여러분의 공개키를 받은 사람들도 필요한 경우 여러분에게 이 값을 물어볼 수 있습니다. 이 경우 지문 값을 불러주면 됩니다. 또는 지문을 불러달라고 한 뒤 맞으면 맞다고 해도 되겠습니다.

이제 지문을 확인했으니 서명을 해서 본인이 이 공개키는 믿을 수 있다고 표시를 하면 키 확인이 끝나게 됩니다.

gpg에는 --edit-key라는 옵션이 있습니다. 이 옵션은 키에 대한 여러가지 작업을 할 때 사용합니다. 방금 사용한 키 지문도 확인할 수 있고 키에 서명을 하거나 새 user id를 생성하거나 만료기간을 설정할 수도 있고 서브키를 생성하고 폐기하는 등 수많은 작업을 할 수 있는 명령어들이 제공됩니다.

$ gpg2 --edit-key Biscuit
...
gpg>

gpg>는 --edit-key 옵션이 실행되면 사용할 수 있는 gpg 자체의 커멘드 프롬프트입니다. 여기에 여러가지 명령을 입력해서 사용합니다. help를 입력하면 명령어읭 목록이 나옵니다. 종료는 quit을 입력합니다. 지문은 fpr을 입력합니다. 작업 후 저장하려면 save를 입력합니다.

서명에 관련된 명령어는 sign, lsign, tsign, nrsign이 있습니다. 여러분이 지금 알아둬야 할 명령어는 sign과 lsign입니다.

sign 명령어로 다른 사람의 공개키에 서명하는 것은 서명을 했다는 기록이 다른 사람에게도 알려지기를 바란다는 의미입니다. 나중에 키 서버를 이용해 서명한 공개키를 내보내면 여러분의 서명을 신뢰하는 사람들이 여러분이 서명한 다른 사람의 공개키를 신뢰할지 판단하는 데 영향을 줍니다.(Web of trust)

lsign은 local 사인입니다. 이 명령어로 사인한 경우 서명했다는 사실이 밖으로 내보내지지 않습니다. 다른 사람들은 여러분이 이 공개키에 서명했다는 사실을 알지 못합니다.

어떤 명령어를 사용할지는 정해져 있지 않습니다. 상황에 맞게 직접 판단하시면 됩니다.

지금은 직접 만난 친구의 공개키를 확인 후 서명하고 있는 상황이기 때문에 다른 친구들이 알 수 있도록 공개 서명을 하도록 합니다.

아무 키에나 무턱대고 서명하는 것은 나쁜 습관입니다. 반드시 공개 키가 올바른 사람으로부터 온 것인지 최대한 확인하시고 확신이 들면 서명하십시오. 키의 정체를 확인하지 않고 서명하는 것은 서명의 신뢰도를 떨어트리는 일입니다.

gpg> sign

pub  rsa4096/0F3FBF20
     created: 2016-12-04  expires: never       usage: SC  
     trust: unknown       validity: unknown
 Primary key fingerprint: DD56 E74D A77D E1C3 46AC  AC57 DE4E 1192 0F3F BF20

     Biscuit John <goodbiscuit@gmail.com>

Are you sure that you want to sign this key with your
key "Infinite Cookies <infcookies@gmail.com>" (2F5DB256)

Really sign? (y/N) y

서명은 여러분의 서명용 키를 사용해서 하게 됩니다. 따라서 gpg는 암호를 물어볼 것입니다.

서명이 잘 되었는지 확인하려면 check 명령어를 사용합니다.

gpg> check
uid  Biscuit John <goodbiscuit@gmail.com>
sig!3        0F3FBF20 2016-12-04  [self-signature]
sig!         2F5DB256 2016-12-04  Infinite Cookies <infcookies@gmail.com>

sig! 옆에 본인의 아이디가 보입니다. sig는 서명을 의미하고 !는 keyring에 있는 공개키로 서명을 확인 후 확인이 되었다는 의미입니다. 옆의 숫자는 인증의 정도입니다. --ask-cert-level 옵션을 사용하면 지정할 수 있습니다. 이 옵션이 사용되지 않으면 기본적으로 인증 레벨을 물어보지 않고 기본 값을 사용합니다. 기본값은 0이며 자세한 내용은 man gpg에서 --ask-cert-level과 --default-cert-level등을 읽어보십시오.

어쨌든 sig!가 보인다는 것은 서명이 되었다는 의미입니다. 서명은 gpg --list-sigs 옵션을 이용해도 볼 수 있습니다.

이제 이 공개키를 믿는 상태이므로 이 공개키를 이용해서 상대방에게 보낼 메시지나 자료를 암호화해서 보내면 상대방은 본인의 개인키를 이용해서 자료를 해독할 것입니다. 상대방이 개인키로 서명한 메시지와 자료를 상대방의 공개키로 확인할 수도 있습니다. 마찬가지로 상대방도 여러분의 공개키로 자료를 암호화하고 서명을 확인할 것입니다. 이것이 비대칭 키를 이용한 통신 방법입니다.

다음 포스트부터는 실제로 자료를 암호화하고 상대방이 암호화한 자료를 해독하는 방법, 메시지와 자료에 서명하는 방법을 알아보도록 하겠습니다.

GPG 키 생성하기

anerdinaserver — Sat, 3 Dec 2016 23:48:30 +0900

오늘은 gpg에서 사용할 마스터 키를 생성하겠습니다.

예제는 모두 리눅스를 사용해서 진행하겠습니다. 하지만 사용법 자체는 운영체제와 관계 없이 거의 같다고 보시면 됩니다.

리눅스와 맥에서는 터미널을, 윈도우에서는 cmd를 실행시키고 진행해 주십시오.

GPG 명령어 개요

gpg 명령은 다음과 같은 형태로 되어 있습니다:

$ gpg [options] [files]

각 옵션에 대한 짧은 도움말을 보려면 이렇게 입력합니다:

$ gpg --help

짧은 도움말 목록을 인쇄해서 옆에 놓고 사용하면 자주 쓰는 옵션들을 외우기 전까지 도움이 많이 될 것 같습니다.

참고: 시스템에 따라 gpg classic이 기본으로 설치되어 있고 버전 2.0 또는 2.1이 gpg2로 설치되어 있는 경우도 있습니다. 예제가 gpg인지 gpg2인지보다 여러 옵션들을 어떻게 사용하고 어떤 결과가 나오는지에 집중해 주세요.

GPG 키 생성하기

뭔가 생성하는 옵션은 다음과 같이 두 가지가 있습니다.

--gen-key              generate a new key pair
--gen-revoke           generate a revocation certificate

--gen-key는 키를 생성하는 옵션이고 --gen-revoke는 곧 이어 진행할 revocation certificate를 생성할 때 사용합니다.

커멘드 라인에 다음과 같이 입력합니다:

$ gpg2 --gen-key

만약 modern 버전(2.1.x) 사용하고 있다면 --full-gen-key 옵션을 사용하십시오.

지금부터는 gpg가 물어보는 여러 사항에 대해 입력하면 됩니다.

일반적으로 기본값을 사용하시면 됩니다.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits

키 종류는 RSA and RSA (default)가 기본 값입니다. RSA의 keysize는 2048비트가 기본 값이지만 요즘은 개인용 컴퓨터도 충분히 빠르기 때문에 4096비트를 선택하는게 좋을 것 같습니다.

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 2w
Key expires at Sat Dec 17 23:16:10 2016 KST
Is this correct? (y/N) y

유효기간(expiration)은 나중에 수정할 수 있으니 필요한 값을 정하시면 됩니다. 유효기간을 지정하지 않으려면 0, 일 단위로 지정하려면 정수, 연 단위는 2y, 3y과 같은 형태로 지정하시면 됩니다.

Real name: Infinite Cookies
Email address: infcookies@gmail.com
You selected this USER-ID:
    "Infinite Cookies <infcookies@gmail.com>"

Change (N)ame, (E)mail, or (O)kay/(Q)uit?

이름은 실명을 사용해도 되고 안 해도 됩니다. 마스터 키는 메시지/자료가 본인이 만든 것임을 증명하기 위해 사용하기도 하기 때문에 실명을 사용하는 것이 말이 되는 경우도 있습니다. 팀을 대표하는 마스터 키인 경우 팀 이름을 사용하는 것이 말이 되는 경우도 있겠습니다.

이메일은 본인에게 연락 가능한 이메일 주소를 입력하면 됩니다.

Comment는 지금 입력한 이름과 이메일 주소에 달리는 주석입니다. 입력하지 않아도 됩니다.

이름과 이메일 주소를 입력한 뒤 이름과 이메일 주소를 수정할 수 있습니다. 키를 생성한 뒤에는 이름과 이메일 주소를 수정할 수 없으니 주의하십시오. 키 생성을 계속 진행하려면 O를 입력합니다.

다음으로 마스터 키를 보호할 암호(passphrase)를 입력합니다. 암호는 마스터 키를 보호할 수 있는 최후의 보루입니다. 강력한 암호가 있으면 마스터 키 파일 자체가 유출되더라도 즉각적인 피해를 막을 수 있습니다(피해가 없다는 것은 아닙니다. 피해를 최소화할 수 있는 시간이 주어진다는 것입니다.)

암호는 다음과 같은 원칙을 가지고 생성하십시오:

나와 관련이 없는 단어만 사용: 전화번호, 생년월일, 가족 이름등은 암호로써의 가치가 없다.
최대한 많은 경우의 수: 영문자 대소문자, 숫자, 기호등을 전부 사용한다. 또한 길이를 최대한 길게 한다.
알아맞추기는 어렵고 기억하기는 좋은 암호를 만든다.

물론 너무 긴 암호는 정작 사용할 때 불편하기도 합니다. 안전함과 편리함의 균형을 맞춰 본인이 생각하기에 이정도면 괜찮겠다 생각되는 길이의 암호를 설정합니다.

암호를 만드는 방법 중 하나인 Diceware에 대해 알아보시고 사용하시길 추천합니다. Diceware는 적절하게 만들면 맞추기는 사실상 불가능하고 기억하기는 매우 좋은 암호를 만들 수 있습니다. 간단히 말하면 전혀 관련 없는 단어들의 목록에서 몇 개의 단어를 뽑아 암호로 정하는 것입니다. 8 단어 정도 사용하면 매우 안전하다고 생각됩니다. 저는 10개 단어를 사용하고 있습니다. Diceware 공식 홈페이지

We need to generate a lot of random bytes. 단계에서 진행이 되지 않는 경우

gpg는 키를 생성할 때 랜덤 바이트를 이용하도록 되어 있습니다. 가끔 시스템에서 제공하는 랜덤 바이트 생성 장치가 gpg와 연결되지 않는 경우 랜덤 바이트를 모으는 단계에서 시간이 매우 오래 걸리거나 진행이 되지 않을 수 있습니다. 이 경우 다음과 같이 조치합니다. (리눅스 기준)

$ sudo apt-get install -y rng-tools && sudo rngd -r /dev/urandom

중요: 키 생성 후 해야 할 일

생성에 관련된 옵션에는 두 가지가 있다고 했습니다. 첫번째는 방금 사용한 --gen-key 옵션입니다. 두번째는 --gen-revoke입니다.

마스터 키를 생성하면 항상 이 옵션으로 revocation certificate(폐기 인증서)를 생성하십시오.

폐기 인증서는 다음과 같이 생성합니다:

$ gpg2 -o revoke.asc --gen-revoke keyspec

keyspec은 key의 아이디나 fingerprint, 또는 이름이나 이메일 주소를 입력하면 됩니다.

-o는 --output 옵션의 짧은 형태이고, 명령 실행 결과를 해당 파일로 내보내도록 하는 옵션입니다. -o나 --output이 없는 경우 standard output으로 출력됩니다.

폐기 인증서는 어떤 이유로든 개인 키를 사용할 수 없게 된 경우 해당 개인 키의 공개키를 갖고 있는 사람들에게 더 이상 이 개인 키로 서명된 자료를 믿지 말고 이 개인 키의 공개키로 자료를 암호화해서 보내지 말라고 알릴 수 있는 최후의 수단입니다. 매우 중요합니다. 개인 키의 암호를 잃어버렸거나 개인 키가 유출되거나 완전히 삭제되어 복구할 수 없는 경우 반드시 필요합니다. 특히 개인 키를 도난당하고 잃어버렸는데 폐기 인증서조차 없는 경우에는 개인 키를 빼간 사람이 여러분의 신분으로 무엇이든 해도 막을 방법이 없게 됩니다.

반대로 개인 키는 안전한데 폐기 인증서가 유출되는 경우 키를 본인의 의사와 상관없이 강제로 폐기시킬 수 있으니 폐기 인증서도 최대한 안전하게 보관하십시오. 폐기 인증서 파일의 내용은 짧기 때문에 많은 사람들이 종이에 인쇄해서 금고에 넣는 방식으로 폐기 인증서를 보관합니다. USB나 CD에 기록해서 보관하는것은 생각보다 좋은 방법이 아닙니다. 종이에 인쇄해서 보관하는 것이 생각보다 오래 보관할 수 있는 방법입니다. 아니면 나중에 배울 symmetric cipher를 이용해 암호화 한 뒤 보관하는 것도 한 방법이라고 할 수 있겠습니다. 당연히 폐기 인증서가 아닌 다른 이름으로 보관하는게 좋겠습니다.