CLIEL LAB __ [ASP.NET] 세션(Session).pdf




HTTP는 비연결 프로토콜입니다. 클라이언트(정확하게는 웹 브라우저)가 서버에 특정 처리를 요청하고 나면 서버에서 그에 맞는 응답을 해주는 것으로 끝납니다. 연결이 계속해서 유지되어야 하는 FTP와는 다른것입니다.

 

이러한 HTTP통신 방식으로 인해 클라이언트가 어떤 데이터를 서버에 요청을 할때마다 서버는 어떻게 해서든 이 사용자가 누구인가 혹은 어떤 데이터를 다루고자 하는가를 구분해야할 필요가 있습니다. 이럴 때 세션(Session)이 사용될 수 있습니다. 다만 세션은 사용자를 구분하기 위한 유일한 방법이 아닙니다. 그저 사용자를 구분하는 방법중 '하나'에 해당할 뿐입니다.

 

세션은 쿠키와 비교될 수 있습니다. 쿠키는 클라이언트에 저장되는 반면 세션은 서버에서 저장되고 관리됩니다. 쿠키보다 훨씬 보안적으로 우수하지만(쿠키는 원한다면 얼마든지 사용자에 의해 변조될 수 있습니다.) 세션은 서버의 자원을 할당해야 한다는 측면에서 성능상으로 단점이 존재합니다.

 

 1. InProc

 

세션은 기본적으로 InProc모드로 관리됩니다. In-Process라는 것으로 HttpRuntime 개체(프로세스)의 내부 캐시에 세션을 저장하고 관리합니다. 이 때문에 실행속도가 가장 빠른 모드이지만 세션을 계속 참조상태에 유지하고 있고 이에대한 가비지 컬렉션은 별도로 이루어지는게 없어서 메모리를 계속 점유하고 있다는 단점이 존재합니다. 물론 그렇다 하더라도 메모리 점유는 만료시간이 20분이 경과하거나 별도의 구성파일에 지정된 시간이 지나면 자동으로 만료되므로 평생 세션을 저장해두지는 않습니다.

 

참고로 InProc모드에서의 세션은 dll이 빌드되어 새로 배포되거나 Web.config와 같은 구성파일의 변경등과 같은 이유로 프로세스가 다시 시작하면 기존 세션은 모두 손실됩니다.

 

ASP.NET에서 세션은 다음과 같이 읽고 쓸 수 있습니다.

 

Session["aaa"] = "aaabbb";
Response.Write(Session["aaa"].ToString());

 

세션은 ASP.NET의 모든 페이지에서 위와 같은 방법으로 엑세스할 수 있습니다. 만일 "aaa"라는 인덱스의 세션을 사용하는 특정페이지가 호출된다면 이 요청이 완료될때까지 같은 세션을 사용하는 다른 페이지는 대기상태에 들어가게 됩니다.(사용하는 세션의 인덱스가 다르면 영향이 없습니다.)

 

필요하다면 특정 페이지마다 EnableSessionState 속성을 조정함으로서 세션접근에 대한 권한을 조정할 수 있습니다.

 

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"

 Inherits="web_form_test.Default" EnableSessionState="True"  %>

 

True값은 세션에 대한 읽기/쓰기 권한을 모두 부여합니다. 같은 세션을 사용하는 다른 페이지에서는 세션이 잠기게 됩니다.

 

False값은 세션에 대한 권한을 주지 않습니다. 만약 False설정이된 페이지에서는 세션이 접근할 수 없습니다.

 

ReadOnly는 세션에 대해 오로지 읽기권한만을 부여합니다. 이 경우에는 세션잠금이 설정되지 않기 때문에 다른 페이지에서 같은 세션의 값을 읽을 수 있습니다. 하지만 세션에 쓰기가 시도되는 경우 모든 읽기또한 차단됩니다.

 

재미있는 점은 EnableSessionState가 False로 설정된 페이지는 설정이 없는 페이지요청보다 우선적으로 처리하게 된다는 것입니다. 따라서 계획적으로 잘만 설정된다면 성능적으로 이익을 볼 수 있습니다. 극단적으로 Web.config를 아래와 같이 처리하면

 

<sessionState mode="Off"></sessionState>

 

웹애플리케이션 전체에 대해 세션사용을 고려하지 않게 되므로 성능면에서 훨씬 이득이지만 세션은 사용할 수 없습니다.

 

 2. Out-of-Process

 

Out-of-Process는 세션을 aspnet_state.exe라는 프로세스에 저장하는 방식입니다. 다른 물리적 서버에 해당 프로세스를 띄어놓고 세션을 관리하는 형태(세션을 처리하는 서버를 별도로 두는것)이지만 원한다면 로컬에 프로세스를 실행하는것 또한 가능합니다. aspnet_state.exe는 자동으로 시작되는 프로세스가 아니므로 서비스를 수동으로 시작해 줘야 합니다.

 

net start aspnet_state

 

위와 같은 명령줄 대신 Services 관리자에서 시작할 수도 있습니다.

 

 

이 프로세스는 TCP통신을 하는데 기본포트가 42424입니다. 이 설정은 아래 레지스트리경로에서 바꿀 수 있습니다.

 

[HKEY_LOCAL_MACHINE]\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\Port

 

세션관리를 Out-of-Process로 하기로 했다면 Web.config에서 세션설정을 바꿔줍니다.

 

<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424">

</sessionState>

 

mode를 StateServer로 설정하여 Out-of-Process 사용을 명시하고 stateConnectionString을 통해서 연결될 서버의 IP와 Port를 설정합니다. 예제에서는 로컬에서 사용할 것이므로 127.0.0.1:42424로 설정하였습니다. 다른 서버라면 그에 맞는 IP를 지정해 주시면 됩니다.

 

이 방식은 일단 이름에 걸맞게 프로세스를 벗어난 세션관리형태의 방식입니다. 그러니까 ASP.NET애플리케이션(코드)은 w3wp.exe프로세스에서 동작하는데 세션관리는 aspnet_state.exe 프로세스에 관리되므로 코드에서 세션을 참조할 수 있는 형태가 아닙니다.

 

그래서 세션에 단순한 문자열을 담는 경우는 상관없지만 클래스나 구조체등을 초기화 하고 세션에 담으려 하면 오류가 발생합니다. 코드의 동작과 세션관리가 다른 프로세스로 분리되어 있기 때문입니다. 이들 프로세스간 통신을 수행해서 세션처리를 정상적으로 처리하려면 사용하려는 클래스에 [Serializable] 특성을 선언해야 합니다.

 

[Serializable]
public class testClass
{
    public string myname;
}

 

클래스를 위와같이 작성하고

 

testClass tc = new testClass();
protected void Page_Load(object sender, EventArgs e)
{
    tc.myname = "cliel";
    Session["aaa"] = tc;
}

protected void Button1_Click(object sender, EventArgs e)
{
    Response.Write((Session["aaa"] as testClass).myname);
}

 

클래스를 세션에 담으면 정상적으로 코드가 수행될 것입니다. 다만 클래스(개체)를 [Serializable]특성을 사용해 직렬화 하면 직렬화되는 과정에서 크기가 다소 커질 수 있습니다. 그 만큼 aspnet_state.exe 프로세스는 관리해야 하는 세션의 크기가 커질 수 있다는 뜻인데 sessionState 요소의 compressionEnabled속성을 true로 하면 개체를 압축해서 저장하므로 크기에 대한 부담이 다소 줄어들 수 있습니다.

 

<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424"

 compressionEnabled="true"></sessionState>

 

하지만 실제 개체를 사용하려면 어떻게 해서든 압축된걸 푸는 과정이 필요하므로 InProc보다는 성능에서 불리할 수 있습니다.

 

 3. SQL 서버 세션

 

세션은 필요하다면 SQL 서버에서 저장하고 관리할 수도 있습니다. 이 방식은 이전에 말씀드린 방식에 비해 가장 느리지만 반면 가장 안전하게 동작하는 방식입니다. 심지어는 IIS전체가 재시작되는 경우라 하더라도 서버에 세션정보가 저장되므로 사용자와의 세션은 계속 유지될 수 있습니다.

 

SQL서버를 통해서 세션을 관리하려면 특정 DB안에 세션저장을 위한 구성이 추가되어야 합니다. 이 작업은 aspnet_regsql.exe 를 통해서 구현할 수 있습니다.

 

아래는 세션관리를 위한 aspnet_regsql.exe 실행 예시입니다.

 

aspnet_regsql.exe -S localhost -U sa -P 1234 -ssadd -sstype p

 

위와 같이 명령줄을 입력하면 해당 서버에 ASPState DB를 자동으로 생성하고 세션저장을 위한 구성을 완료하게 됩니다.

 

참고로 -ssadd는 지정된 서버에 세션상태저장을 위한 구성을 추가하는 옵션이며 반대로 -ssremove는 추가된 구성을 제거하도록 하는 옵션입니다.

 

-sstype으로 지정된 p는 데이터와 프로시저를 ASPState DB에 저장하도록 합니다. 물론 DB도 알아서 만들어 주므로 일단 편리함은 최고입니다. p외에 t라는 옵션도 있는데 이 옵션은 세션을 tempdb에 저장하고 프로시저는 ASPState에 생성하도록 합니다. 이는 세선을 임시테이블에 저장하는 형태다 보니 SQL서버가 다시 시작되면 세션데이터는 사라진다는 특징이 있습니다.

 

만일 ASPState DB에 세션저장과 프로시저가 생성되는걸 원하지 않는다면 c옵션으로 직접 세션이 저장되고 프로시저가 생성되는 DB를 지정해 줄 수도 있습니다.

 

 

 

aspnet_regsql.exe를 실행시켜 위와 같이 정상적으로 처리되었다면 이제 web.config를 수정하여 세션을 SQL Server에 저장하도록 해주면 됩니다.

 

<sessionState mode="SQLServer" sqlConnectionString="data source=127.0.0.1;user

 id=sa;password=12345"></sessionState>

 

참고로 ASPState DB가 아닌 다른 이름의 DB를 사용한다면 위 Web.config설정에서 database=mydb형식으로 내용을 추가해 줘야 합니다.



출처: http://lab.cliel.com/entry/ASPNET-세션Session [CLIEL LAB]





[[ASP.NET]] Session in ASP.Net - 강좌4 _ 네이버 블로그.pdf





'Knowledge' 카테고리의 다른 글

[MSSQL] 서버 연결하기/addlinkedserver  (0) 2018.07.12
[ASP.NET] 세션(SESSION)  (0) 2018.06.21
모노와 스테레오의 차이  (0) 2018.06.04
[스크랩] 비틀즈로 알아보는 모노와 스테레오의 차이  (0) 2018.06.04
SnapLock  (0) 2018.06.04



-

아,,그렇군요!!자세히설명해주셔서감사합니다!!

스테레오와 모노의 차이점은 스피커에서 나오는 소리를 어떻게 하느냐에 대한 차이입니다.

 

좀 쉽게 예를 들어 설명하겠습니다.

 

바이올린과 피아노를 사용한 클래식 음악이 있다고 하고 스피커는 2채널(2개)라고 하겠습니다.

 

일단 모노는 저 두 악기의 소리를 그냥 내보냅니다.

 

다시 말하면 2개의 스피커가 동시에 피아노 바이올린의 두가지 소리를 내보낸다는 것이죠

 

좀더 쉽게 설명하면 이어폰으로 들을 때 한개의 이어폰을 빼도 다른 한쪽의 이어폰에서

 

피아노, 바이올린 이 두가지 악기의 소리를 모두 들을 수 있는 것입니다.

 

그리고 스테레오는 저 두 악기를 각각 스피커 한개 씩 나눠서 내보내는 것입니다.

 

즉, 이어폰의 한쪽을 빼면 다른 곳에서는 피아노, 바이올린 이 둘중 한개만 소리가 나는 방식입니다.

 

물론 이것을 지원하려면 두 악기를 따로 녹음해야 합니다.

 

아 그리고 스테레오를 사용하는 이유는 좀더 현장감 있는 소리를 만들기 위해서 입니다.

 

영화같은 경우 5채널을 사용하는데요 스피커를 앞, 뒤 양옆 이런 식으로 배치하면 정말

 

현장에서 직접 소리를 듣는 느낌이 나겠죠?

 

그리고 용량차이가 나는이유는 기술상 스테레오가 좀더 많은 용량을 차지하기 때문입니다.

-

'Knowledge' 카테고리의 다른 글

[ASP.NET] 세션(SESSION)  (0) 2018.06.21
[ASP.NET] Session  (0) 2018.06.21
[스크랩] 비틀즈로 알아보는 모노와 스테레오의 차이  (0) 2018.06.04
SnapLock  (0) 2018.06.04
[.NET] Hashtable Generic  (0) 2018.05.30

비틀즈로 알아보는 모노와 스테레오의 차이

http://soundz.egloos.com/4922031

비틀즈The Beatles 카탈로그가 재발매 되면서 모든 앨범이 스테레오 기준으로 제작되고, 또 이걸 죄다 모은 스테레오 박스와, 지금껏 구하기 힘들었던 모노버전을 별도로 모은 모노 박스가 발매된다는 소식은 이미 전해 드렸습니다. (국내최초단독특종보도였음을 당시 한번 강조하면서. 흠흠...)

그런데 이글루스 쪽은 아니지만, 네이버 쪽에서는 '모노/스테레오가 뭐 다른거삼?' 이런 질문을 매우 많이 받았습니다. 아무래도 주이용자의 연령분포의 차이가 이런데서 드러나는 것 같은데, 쪽지로 온 것은 대충 다 설명을 드렸지만 댓글로 달리거나 한 질문들은 별도로 답하질 못해서 겸사겸사 이런 포스트를 날립니다.

음향기기나 기술에 경험과 관심이 없는 중고생들은 그럴 수 있겠으나 자주 이어폰 꽂고 음악을 듣는 대학생이나 20대들이 스테레오가 기본적으로 어떤 개념인지 모르는 것은 다소 의외였습니다. 이런 것도 세대차이일까요? ^^;;

아무튼 가장 많은 오해는 모노와 스테레오를 음질의 차이라고 이해하는 경우가 가장 많았습니다. 그러니까 질문 안 한 분들 중에도 이런 식으로 잘못 알고계신 분들이 많다는 이야기겠지요. 모노는 음질이 후진 것, 스테레오는 뭔가 단어가 근사하니까 음질이 좋은 것 이런 식으로 이해하는 경우가 많았습니다.

결론부터 말하면 모노와 스테레오는 음질의 차이하고는 아무런 관련이 없습니다. 리마스터링으로 인해 나타는 음색의 차이와도 관련없습니다.

* 리마스터링이 단지 음질 업그레이드라고 생각하시는 분들도 많은데 리마스터링은 어느 엔지니어가 담당하느냐에 따라 단순히 음질의 개선 뿐만이 아니라 곡의 느낌에 상당한 변화를 줍니다. 

모노와 스테레오는 음의 입체감과 관련된 개념입니다. 모노는 이름 그대로 소리가 한 방향에서만 들리는 것이고 스테레오는 두 방향에서 들립니다. (그래서 결과적으로는 좌-중-우 세 방향에서 들립니다.) 이 방향을 채널이라고 하는데 채널이 두개라 stereo라고 합니다. 그래서 채널이 5개면 5.1채널이 됩니다. (0.1에 해당하는 서브우퍼는 특정 음대역을 재생하는 장치지 특정 채널을 재생하는 것이 아닙니다.)

이어폰이나 헤드폰이 두짝인 것은 사람 귀가 두개여서가 아니라 소리가 두 곳에서 나오기 때문입니다. 모노 이어폰은 당연히 한짝 밖에 달려있지 않습니다.

그니까 이런 차이는 전~~~혀 중요하지 않습니다.

스테레오의 개념은 이미 19세기 말에 정립됐지만 상업화 된 것은 50년대입니다. 그러나 클래식 음반에 먼저 적용됐고, 대중음악에는 60년대 들어서야 보급됩니다. 비틀즈가 데뷔할 무렵입니다. 그리고 60년대 후반이 되면 모노 우세에서 스테레오 우위로 대중음악 시장도 전환됩니다.

그래서 "화이트 앨범"까지의 비틀즈 앨범들이 모노와 스테레오 별도의 버전으로 존재하는 것입니다. 여기에 비틀즈는 스테레오 믹스의 두 채널을 기술적으로 합치는 방식으로 모노 믹스를 제작하지 않고 모노믹스를 우선 제작한 후 별도로 스테레오 믹스를 제작했기 때문에 여러 노래에서 모노/스테레오 버전의 차이가 발생했습니다. 

예를 들어 'Please Please Me(앨범말고 노래)'의 모노와 스테레오 버전을 각기 들어보면 스테레오 버전에서는 존이 가사를 틀려서 멋적게 웃는 광경이 그대로 들어있습니다. 즉, 모노믹스와 스트레오믹스에 사용된 보컬 트랙이 서로 다른 것이지요.

이런 이유로 그동안 수많은 팬들이 비틀즈 앨범의 모노버전을 (첫 네장의 경우는 스테레오를) 상업적으로 발매해 줄 것을 요구했었습니다. 인터넷에는 비틀즈 모노 버전 발매를 위한 세계 팬들의 청원 서명사이트도 있습니다. 이번에 비틀즈 박스가 스테레오와 모노 두가지 형태로 나오는 것은 돈 더벌기 위해 EMI와 애플이 꼼수를 쓰는 것은 아닙니다. 

아무튼 말로 설명하는 것보다 직접 듣고 확인하는 것이 더 정확하고 빠르겠습니다. 고맙게도 비틀즈의 현행 CD들을 보면 초기 곡들의 모노와 스테레오 버전의 차이를 확인 할 수 있는 트랙들이 있습니다.


비교 1. "1"앨범을 이용

너무 팔린 나머지 현대인의 생활소품이라는 지위를 획득한 "1" CD에는 'Can't Buy Me Love', 'A Hard Day's Night', 'Eight Days a Week'가 스테레오 버전으로 실려있습니다. 
이어폰이나 헤드폰을 끼고, 'Can't Buy Me Love', 'A Hard Day's Night' 두곡을 현행 "A Hard Day's Night" CD에 실린 같은 곡의 모노 버전과 비교해서 들으시면 모노/스테레오의 차이, 입체감의 차이라는 것이 무엇인지 확인하실 수 있습니다. 물론 음질의 차이도 느껴지시겠지만 그건 무시하셔야 합니다. 당연히 "1"은 2000년에 리마스터링한 음반이니까요. ^^;;
'Eight Days a Week'는 현행 "Beatles for Sale" CD의 같은 트랙과 비교하시면 됩니다.

비슷한 경우로 "레드앨범"이라고도 불리는 "The Beatles / 1962–1966"에는 위의 세곡 외에도 'And I Love Her'의 스테레오 버전이 실려있어 오리지널 CD의 모노 버전과 비교해 볼 수 있습니다. 

* "레드앨범"에는 'All My Loving'의 스테레오 버전도 실려있지만 이 믹스는 초기 2트랙 녹음의 한계로 모노 버전과 이미지의 차이가 크지 않습니다.


비교 2. "The Capitol Albums, Volume 1"과 "Volume 2"
미국에서 발매된 비틀즈의 앨범들을 모은 이 박스세트는 모든 곡들이 모노/스테레오 버전으로 함께 들어있기 때문에 이 박스 세트를 가지고 계신 분은 손쉽게 모노/스테레오 차이를 경험하실 수 있습니다.

비틀즈 초중기 곡들의 모노/스테레오 버전은 
거의 대부분 이 박스세트를 통해 처음 CD데뷔했습니다. 
특히 "Help!"와 "Rubber Soul"의 65년 오리지널 스테레오 믹스도 
이 박스세트를 통해 이미 공개됐습니다.


비교 3. "EP Collection"과 "Singles Collection"
갖고 계신 분은 그리 많지 않지만 92년에 나온 "EP Collection"과 "Singles Collection"에는 수많은 초중기 곡들의 모노믹스가 실려있습니다. 특히 "Magical Mystery Tour" EP의 모노 버전과 스테레오 버전이 함께 들어있기 때문에 비교해서 듣기 좋습니다.


일단 현행 CD를 통해 손쉽게 모노와 스테레오의 기술적인 차이를 이해하는 방법을 적어봤습니다. 앞에서도 언급했던 두가지 믹스에서 발견되는 소소한 차이는 비틀즈 카탈로그가 재발매되기 전에 한번 주욱 정리하도록 하겠습니다. :)


'Knowledge' 카테고리의 다른 글

[ASP.NET] Session  (0) 2018.06.21
모노와 스테레오의 차이  (0) 2018.06.04
SnapLock  (0) 2018.06.04
[.NET] Hashtable Generic  (0) 2018.05.30
[스크랩] [C#] 람다식 작성  (0) 2018.05.30


링크: https://library.netapp.com/ecmdocs/ECMP1196889/html/GUID-7334EEB5-94E9-4500-BA40-681DEC572420.html


-

What SnapLock is

SnapLock is an alternative to the traditional optical "write once, read many" (WORM) data. SnapLock is used for the storage of read-only WORM data.

SnapLock is a license-based, disk-based, open-protocol feature that works with application software to administer non-rewritable storage of data. The primary objective of this Data ONTAP feature is to provide storage-enforced WORM and retention functionality by using open file protocols such as CIFS and NFS. SnapLock can be deployed for protecting data in strict regulatory environments in such a way that even the storage administrator is considered an untrusted party.

SnapLock provides special purpose volumes in which files can be stored and committed to a non-erasable, non-rewritable state either forever or for a designated retention period. SnapLock allows this retention to be performed at the granularity of individual files through standard open file protocols such as CIFS and NFS.

-

How SnapLock works

The WORM data on SnapLock volumes is administered in the same way as data on regular (non-WORM) volumes. SnapLock volumes operate in WORM mode and support standard file system semantics. You can create data on a SnapLock volume and commit it to the WORM state by transitioning the file from a writable state to a read-only state.

Marking an active writable file as read-only on a SnapLock volume commits the data to WORM. When a file is committed to WORM, it cannot be altered or deleted by applications, users, or administrators until the file retention date is reached. The exception is in SnapLock Enterprise volumes, where you can delete a file before it reaches the retention date by using the privileged delete feature.

The data that is committed to the WORM state on a SnapLock volume cannot be changed or deleted before its retention date. However, you can change or delete the empty directories and files that are not committed to a WORM state. Directories do not behave any differently than they would on regular volumes, with the exception that they cannot be renamed or moved once created. It is a requirement for regulatory compliance that WORM data be not only non-erasable and non-rewritable, but it must also be locked down in the same location at which it was created. In the case of WORM implementation, this means that the directory path to WORM files must be locked down and should never change.

In Data ONTAP 7.0 and later, WORM files can be deleted after their retention dates have been reached. The retention date on a WORM file is set when the file is committed to the WORM state, but it can be extended at any time. The retention period can never be shortened for any WORM file.

-




MD5

위키백과, 우리 모두의 백과사전.
둘러보기로 가기검색하러 가기

MD5(Message-Digest algorithm 5)는 128비트 암호화 해시 함수이다. RFC 1321로 지정되어 있으며, 주로 프로그램이나 파일이 원본 그대로인지를 확인하는 무결성 검사 등에 사용된다. 1991년에 로널드 라이베스트가 예전에 쓰이던 MD4를 대체하기 위해 고안했다.

1996년에 MD5의 설계상 결함이 발견되었다. 이것은 매우 치명적인 결함은 아니었지만, 암호학자들은 해시 용도로 SHA-1과 같이 다른 안전한 알고리즘을 사용할 것을 권장하기 시작했다. 2004년에는 더욱 심한 암호화 결함[1]이 발견되었고. 2006년에는 노트북 컴퓨터 한 대의 계산 능력으로 1분 내에 해시 충돌을 찾을 정도로 빠른 알고리즘이 발표[2]되기도 하였다. 현재는 MD5 알고리즘을 보안 관련 용도로 쓰는 것은 권장하지 않으며, 심각한 보안 문제를 야기할 수도 있다. 2008년 12월에는 MD5의 결함을 이용해 SSL 인증서를 변조하는 것이 가능하다는 것이 발표되었다[1].

알고리즘[편집]

단일 MD5 연산. MD5에서는 이 단일 연산을 64번 실행한다. 16개의 연산을 그룹화한 4 라운드로 묶인다. F는 각 라운드에서 사용하는 비선형 함수를 가리키며, 각 라운드에서는 각각 다른 함수를 사용한다. Mi는 입력 메시지의 32-비트 블록을 의미한다.

left shifts는 s칸 만큼의 레프트 로테이션을 가리키며, s는 각 연산 후 값이 변한다. Addition 은 모듈로 232 덧셈을 말한다.

MD5는 임의의 길이의 메시지(variable-length message)를 입력받아, 128비트짜리 고정 길이의 출력값을 낸다. 입력 메시지는 512 비트 블록들로 쪼개진다; 메시지를 우선 패딩하여 512로 나누어떨어질 수 있는 길이가 되게 한다. 패딩은 다음과 같이 한다: 우선 첫 단일 비트, 1을 메시지 끝부분에 추가한다. 512의 배수의 길이보다 64 비트가 적은 곳까지 0으로 채운다. 나머지 64 비트는 최초의(오리지널) 메시지의 길이를 나타내는 64 비트 정수(integer)값으로 채워진다.

메인 MD5 알고리즘은 A,B,C,D라고 이름이 붙은 32 비트 워드 네 개로 이루어진 하나의 128 비트 스테이트(state)에 대해 동작한다. A,B,C,D는 소정의 상수값으로 초기화된다. 메인 MD5 알고리즘은 각각의 512 비트짜리 입력 메시지 블록에 대해 차례로 동작한다. 각 512 비트 입력 메시지 블록을 처리하고 나면 128 비트 스테이트(state)의 값이 변하게 된다.

하나의 메시지 블록을 처리하는 것은 4 단계로 나뉜다. 한 단계를 "라운드"(round)라고 부른다; 각 라운드는 비선형 함수 F, 모듈라 덧셈, 레프트 로테이션(left rotation)에 기반한 16개의 동일 연산(similar operations)으로 이루어져 있다. 오른쪽 그림은 한 라운드에서 이루어지는 한 연산(operation)을 묘사하고 있다.

함수 F에는 4가지가 있다; 각 라운드마다 각각 다른 F가 쓰인다:

는 각각 XOR논리곱논리합 그리고 NOT 연산을 의미한다.

의사코드[편집]

MD5 알고리즘의 의사코드는 다음과 같다:

//Note: All variables are unsigned 32 bits and wrap modulo 2^32 when calculating
var int[64] r, k
//r specifies the per-round shift amounts
r[ 0..15] := {7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22,  7, 12, 17, 22}
r[16..31] := {5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20,  5,  9, 14, 20}
r[32..47] := {4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23,  4, 11, 16, 23}
r[48..63] := {6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21,  6, 10, 15, 21}
//Use binary integer part of the sines of integers as constants:
for i from 0 to 63
    k[i] := floor(abs(sin(i + 1)) × (2 pow 32))
//Initialize variables:
var int h0 := 0x67452301
var int h1 := 0xEFCDAB89
var int h2 := 0x98BADCFE
var int h3 := 0x10325476
//Pre-processing:
append "1" bit to message
append "0" bits until message length in bits ≡ 448 (mod 512)
append bit (bit, not byte) length of unpadded message as 64-bit little-endian integer to message
//Process the message in successive 512-bit chunks:
for each 512-bit chunk of message
    break chunk into sixteen 32-bit little-endian words w[i], 0 ≤ i ≤ 15
    //Initialize hash value for this chunk:
    var int a := h0
    var int b := h1
    var int c := h2
    var int d := h3
    //Main loop:
    for i from 0 to 63
        if 0 ≤ i ≤ 15 then
            f := (b and c) or ((not b) and d)
            g := i
        else if 16 ≤ i ≤ 31
            f := (d and b) or ((not d) and c)
            g := (5×i + 1) mod 16
        else if 32 ≤ i ≤ 47
            f := b xor c xor d
            g := (3×i + 5) mod 16
        else if 48 ≤ i ≤ 63
            f := c xor (b or (not d))
            g := (7×i) mod 16
        temp := d
        d := c
        c := b
        b := b + leftrotate((a + f + k[i] + w[g]) , r[i])
        a := temp
    //Add this chunk's hash to result so far:
    h0 := h0 + a
    h1 := h1 + b
    h2 := h2 + c
    h3 := h3 + d
var int digest := h0 append h1 append h2 append h3 //(expressed as little-endian)
  //leftrotate function definition
  leftrotate (x, c)
      return (x << c) or (x >> (32-c));
  • 참고: RFC 1321에 나온 공식외에 다음과 같은 공식을 쓰면 퍼포먼스가 향상될 수 있다(어셈블리어가 사용될 때 유용하다 - 다른 언어가 쓰일 경우에는 대개 컴파일러가 위의 코드를 최적화 해준다.)
(0  ≤ i ≤ 15): f := d xor (b and (c xor d))
(16 ≤ i ≤ 31): f := c xor (d and (b xor c))

각주[편집]

  1. 이동 Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger. “MD5 considered harmful today: Creating a rogue CA certificate”.


flux-setup.exe



시간에 따라 블루스크린 정도가 변경이 되므로, 최고값 최소값 설정을 잘해두세요.



전 최소 최대를 똑같이 맞추고 씁니다. 



(출처: https://justgetflux.com/ )





Pocket_ 7 Best Free Flowchart Tools for Windows.pdf


+ Recent posts