대칭키 암호화, 비대칭키 암호화

암호화

1. 대칭키 암호화
→ 암호화하고 복호화 하는데 같은 키를 사용하는 방식.

대칭키 암호화 기법은 2개의 키를 사용하는 비대칭키 암호화 기법에 비해 간단한 반면 A와 B가 메시지를 주고 받기 전에 동일한 내용의 대칭키를 미리 알고 있어야 하는 문제가 있다. 이 대칭키는 쉽게 바꿀 수도 없고 사전에 공유하기 어려운 성질을 갖는다. A와 B가 대칭키 암호화 방식으로 데이터를 주고 받기 결정했다면 A 또는 B 중 한사람은 암호키를 만들어서 상대방에게 전달해야 한다. 그런데 전달 과정에서 누군가 이 암호키를 가로챈다면 그 누군가는 언제든 암호화된 메시지를 복호화 해서 내용을 확인할 수 있게 된다.


2. 비대칭키 암호화
→ 암호화하고 복호화 하는데 공개키/비밀키의 한 쌍을 사용하는 방식.

대칭키 암호화 기법에서 대칭키 교환의 문제를 해결하기 위해 고안된 기법이다. 비대칭키 암호화 기법은 공개키와 비밀키 한쌍의 암호화 키를 이용해 암복호화를 수행한다. 무슨 얘기인가 하면 공개키로 암호화된 메시지는 Pairing된 비밀키로만 복호화할 수 있고, 비밀키로 암호화된 메시지 또한 Pairing된 공개키로만 복호화할 수 있다는 말이다.
비대칭키 암호화 방식의 단점은 CPU 리소스를 대칭키 암호화 방식에 비해 많이 쓴다는 점이다. 따라서 일반적으론 비대칭키 암호화 방식을 이용해 대칭키를 서로 공유한 뒤에 이후의 암호화는 대칭키 방식을 사용한다.


3. 웹 암호화
SSL/TLS 기반의 웹 사이트에 접근하게될 때, 웹 서버는 공개키가 포함된 인증서를 사용자에게 보내주어 이 공개키를 이용해 암호화 하면 된다고 알려준다.  앞선 예와 유사한 이유로 수신한 공개키의 진위 여부를 가릴 필요가 있다.

만약 해커가 인증서와 인증서에 포함된 공개키를 조작해 전달한 것이라면 사용자의 암호화된 패킷을 자유롭게 열어볼 수 있을 것이다. SSL/TLS 기반의 통신을 지원하는 웹 서버는 웹 서버가 사용자에게 전달하는 공개키가 진짜라는 것을 보증받기 위해 신뢰할 수 있는 인증 기관 (Certificate Authority)에 공개키를 등록하게 된다.

인증서가 만들어지는 목적은 공개키의 무결성을 검증하기 위함이고, 신뢰할 수 있는 인증기관에 의해 보증된다. (*신뢰할 수 있는 인증 기관 목록은 이미 브라우저가 알고 있다.)

[SQL] WITH (NOLOCK)

http://www.sqler.com/bColumn/870643

SQL Server에서 잠금(LOCK)은 지극히(?) 정상적인 동작이다. 특정 데이터 영역에 INSERT나 UPDATE 작업이 일어나면 해당 영역엔 LOCK이 걸리게 된다. 데이터의 일관성을 유지하기 위한 것으로 동시에 이 영역을 참조하는 SELECT 작업은 LOCK이 해제될 때까지 대기해야 한다.

문제는 사용자 입장에서 불필요하다고 느낄 때가 있다는 것인데, 정말 단순한 데이터라 일관성은 뒤로하고 그저 빠르게 읽어오고 싶은 경우가 있기 때문이다.

이럴 때 잠금 힌트 중 NOLOCK을 사용한다. NOLOCK 힌트는 커밋되지 않은 트랜잭션이나 읽는 중 롤백된 데이터에 대한 조회를 가능하게 한다. 즉, 커밋되지 않은 읽기가 가능하므로 LOCK이 걸려있어도 대기하지 않고 데이터를 가져올 수 있다. (READUNCOMMITTED) 단, 다시 언급하지만 데이터의 일관성이 보장되진 않으므로 데이터 성격을 감안해서 써야 한다.

사용 방법은 FROM 절 뒤에 WITH (NOLOCK)을 붙여주면 된다.
ex) SELECT * FROM EMPLOYEE WITH (NOLOCK)

Apache Commons DBCP 설정

https://commons.apache.org/proper/commons-dbcp/configuration.html

• initialSize (default: 0) : BasicDataSource 클래스 생성 후 최초로 getConnection()을 호출할 때 커넥션 풀에 채워지는 커넥션 개수
• maxTotal (default: 8) : 동시에 사용할 수 있는 최대 커넥션 개수
• maxIdle (default: 8) : 커넥션 풀에 반납할 때 유지될 수 있는 커넥션 개수
• minIdle (default: 0) : 최소한으로 유지할 커넥션 개수

→ initialSize, maxTotal, maxIdle, minIdle은 동일한 값으로 통일해도 무방한데 실제로 성능에 영향을 주는 요소는 커넥션 개수를 몇개까지 쓸 것인가에 대한 것이기 때문이다. 풀의 최대 크기를 몇 개로 설정할 것인가가 관건이지 저 4개의 변수를 미세 조정하는 것은 별 의미가 없다. 그리고 일반적으론 maxTotal과 maxIdle 값은 같게 지정하는 것이 좋다. maxTotal 보다 maxIdle이 낮게 설정되면 일부 커넥션이 거의 즉시 닫혔다 열리는 현상을 볼 수 있다. 이런 현상은 비용 측면에서 낭비다.
# 초기엔 initialSize, maxIdle, minIdle 값을 maxTotal 대비 낮은 값을 지정해 적정 커넥션 수치를 모니터링한 뒤 값을 Fix하는 것이 권장된다.

• maxWaitMills : 커넥션 풀 안의 커넥션이 고갈됐을 때 커넥션 반납을 대기하는 시간. 단위는 밀리초. 이 값이 너무 짧으면 불필요한 오류가 생기고 너무 크면 사용자가 과도하게 대기하는 증상이 발생해 좋지 않다. (10초(10000ms) 권장)
• validationQuery : 커넥션 풀에서 연결의 유효성을 검사하는데 사용할 SQL 쿼리를 지정한다. 형식은 적어도 하나의 행을 반환하는 SQL SELECT 문이어야 한다.

     - Oracle : select 1 from dual
     - MS-SQL : select 1
     - MySQL : select 1

• testOnBorrow (default: true) : 커넥션 풀에서 커넥션을 얻어올 때 테스트 실행
• testOnReturn (default: false) : 커넥션 풀로 커넥션을 반환할 때 테스트 실행
• testWhileIdle (default: false) : 유휴 객체 제거기(object evictor)에 의한 유효성 검증을 할 것인가에 대한 설정. validate에 실패하면 커넥션이 풀에서 삭제된다. testOnBorrow는 getConnection()을 호출할 때마다 테스트를 한다면 이 설정은 특정 주기로 여러 개의 커넥션을 모아서 테스트한다. (by object evictor thread.)
• timeBetweenEvictionRunsMillis (default: -1) : object evictor 쓰레드 실행 간격. object evictor를 활성화 시키려면 양수 값을 갖어야 한다. Tomcat DBCP는 이 값을 5초 정도로 해도 괜찮지만 Commons DBCP에선 성능 저하의 위험이 있다. Commons DBCP에선 기본 설정이 아예 false인 것으로 봐도 짧은 시간을 지정하는건 무리가 있는듯. (30초 ~ 60초 권장)
• numTestsPerEvictionRun (default: 3) : object evictor 쓰레드가 실행할 때마다 검사할 커넥션 개수. 검사 시간 동안 커넥션 풀에 락이 걸린다고 한다. 기본값 권장.
• minEvictableIdleTimeMillis (default: 1000 * 60 * 30, 30분.) : 커넥션이 축출 대상이 되기 전에 커넥션 객체가 풀에서 유휴 상태로 있을 수 있는 최소 시간.

• removeAbandoned (default: false) : 오랫동안 열려만 있고 close() 메서드가 호출되지 않는 커넥션을 임의로 닫는 기능을 설정. (removeAbandonedOnBorrow / removeAbandonedOnMaintenance)

Conquer and divide

In XP, We don't divide and conquer. We conquer and divide. First we make something that works, then we bust that up and and solve the little parts.
- Kent Beck.

애자일이나 TDD에 대한 가장 흔한 오해 중 하나는 그 방식들이 divide and conquer를 장려한다는 생각이다.
...
고객에게 가치를 전달하는 측면을 보자면 divide and conquer는 제대로 가치를 주지 못할 수 있습니다. 왜냐하면 experience를 주기보다 feature를 주기 때문입니다.
...
- 김창준님 페이스북

김연수 소설가의 일 中

1.
나이가 들면 성격이 바뀌지 않는다는 통념이 많지만, 마흔 살이 넘어도 나는 어떤 사람이 되고 싶고, 또 될 수 있다고 생각한다. 이건 무슨 바람이나 신념 같은 게 아니라 과학적 사실에서 나오는 말이다. 뇌과학에는 반복된 경험이 뇌의 구조를 바꾼다는 사실을 가리키는 신경가소성이라는 용어가 있다. 반복하면 할수록 뇌의 구조가 바뀌기 때문에 어떤 일을 계속 연습하면 사람이 달라진다는 사실은 20세기 후반에야 비로소 과학적으로 확인됐다. 쉽게 말하면 의식적으로 하루에 세 번 농담을 던지는 행동을 계속하면 뇌의 신경경로가 농담을 잘하는 쪽으로 변화하고 재구조화된다. 그렇게 일단 뇌가 바뀌면 사람이 달라진다. 그러니까 유머를 개발하려고 노력하고 생활에서 이를 실천하면 사십 년 뒤에 내가 농담을 잘하는 할아버지가 된다는 것은 거의 확실하다. 점점 우스워지는 사람이 있을 뿐, 날 때부터 우스운 사람은 없다.

2.
어떤 일을 할 것인가 말 것인가 누군가 고민할 때, 나는 무조건 해보라고 권하는 편이다. 외부의 사건이 이끄는 삶보다는 자신의 내면이 이끄는 삶이 훨씬 더 행복하기도 하지만, 한편으로는 심리적 변화의 곡선을 지나온 사람은 어떤 식으로든 성장한다는 걸 알기 때문이다. 아무런 일도 하지 않는다면, 상처도 없겠지만 성장도 없다. 하지만 뭔가 하게 되면 나는 어떤 식으로든 성장한다. 심지어 시도했으나 아무것도 하지 못했을 때조차도 성장한다. 그러니 일단 써보자. 다리가 불탈 때까지는 써보자. 그러고 나서 계속 쓸 것인지 말 것인지 결정하자. 마찬가지로 어떤 일이 하고 싶다면, 일단 해보자. 해보고 나면 어떤 식으로든 우리는 달라졌을 테니까. 결과가 아니라 그 변화에 집중하는 것, 여기에 핵심이 있다.

JavaScript 난독화

https://stackoverrun.com/ko/q/3910942

JavaScript Obfuscate.

/** 
* Obfuscate a plaintext string with a simple rotation algorithm similar to 
* the rot13 cipher. 
* @param {[type]} key rotation index between 0 and n 
* @param {Number} n maximum char that will be affected by the algorithm 
* @return {[type]}  obfuscated string 
*/ 
String.prototype.obfs = function(key, n = 126) { 
    var chars = this.toString().split(''); 

    for (var i = 0; i < chars.length; i++) { 
        var c = chars[i].charCodeAt(0); 
        chars[i] = String.fromCharCode((c + key) % n); 
    } 

    return chars.join(''); 
}; 

/** 
* De-obfuscate an obfuscated string with the method above. 
* @param {[type]} key rotation index between 0 and n 
* @param {Number} n same number that was used for obfuscation 
* @return {[type]}  plaintext string 
*/ 
String.prototype.defs = function(key, n = 126) { 
    return this.toString().obfs(n - key); 
}; 

사용 방법은 아래와 같다. 시간이 없어서 코드를 그대로 긁어다 붙였지만 예상대로 동작하지 않을 수 있기 때문에 사용하기 전에 충분한 테스트가 필요하다.

"abc;123!".obfs(13) // => "nopH>?@." 
"nopH>?@.".defs(13) // => "abc;123!" 

무슨 말인가 하면 아스키 문자에는 del 키나 backspace 키 같은 제어 문자가 포함되므로 난독화 과정에서 일부 문자가 소실될 수 있는 것이다. 아스키 코드 표는 아래 링크에 잘 정리되어 있다.
https://shaeod.tistory.com/228

이병철 회장의 경영 15계명

1. 행하는 자 이루고, 가는 자 닿는다.
2. 신용을 금쪽같이 지켜라.
3. 사람을 온전히 믿고 맡겨라.
4. 업의 개념을 알아라.
5. 판단은 신중하게, 결정은 신속하게.
6. 근검절약을 솔선수범하라.
7. 메모광이 되라.
8. 세심하게 일하라.
9. 신상필벌을 정확하게 지켜라.
10. 전문가의 말을 경청하라.
11. 사원들을 일류로 대접하라.
12. 부정부패를 엄히 다스려라.
13. 사원 교육은 회사의 힘을 기르는 것이다.
14. 목계의 마음을 가져라.
15. 정상에 올랐을 때 변신하라.