HELIX: Hızlı Şifreleme ve Doğrulama

0
butch
Şifreleme üstadı Bruce Schneier ve Niels Ferguson tarafından geliştirilen HELIX sistemi hakkında detaylı bilgiyi bulabileceğiniz makale Emre Sevinç tarafından dilimize çevirildi. Hepimize hayırlı olsun. Makalenin orjinalini Dr.Dobb's Journal 2003, Kasım sayısında bulabilirsiniz.
Yazan: Niels Ferguson ve Bruce Schneier (*)
Çeviren: Emre Sevinç

Veriyi gönderirken - e-posta, VPN oturumu, uzaktan login ve benzerleri - iki tür saldırıya dikkat etmeniz gerekir: birilerinin iletişim hattınızı dinlemesi veya yolladığınız veriyi yoldayken değiştirip hedefe bu değiştirilmiş halini yollaması yani, araya girmesi durumu. Birinci türden saldırıya karşı tedbir almak için şifreleme, ikinci türden karşı saldırıya karşı ise mesaj doğrulama mekanizması kullanmanız gerekir. Açıkça görüldüğü gibi bu iki saldırı türü farklıdır ve bu yüzden bunlara karşı alınacak tedbirlerin de doğası farklı olmak durumundadır. Bir mesajı şifrelemenin en kolay yolu eldeki veriye bir simetrik şifreleme algoritması uygulamak ve şifreleme anahtarına sahip olmayan biri için veriyi okunmaz kılmaktır. Bir mesaj için kimlik onaylamanın yolu ise veriye Mesaj Doğrulama Kodu (MAC - Message Authentication Code) uygulamak ve sonra bu kodu veriye eklemektir. Sadece doğru anahtara sahip kişi doğru MAC kodunu hesaplayabilecektir, böylece alıcılar MAC kodunu doğrulayarak aldıkları mesajın yolda gelirken kötü niyetli biri tarafından değiştirilmemiş olduğundan emin olabilirler. (Şifreleme ve doğrulama açık anahtar [public-key] şifrelemesi ile de yapılabilir ancak performans sebeplerinden ötürü açık anahtar sistemleri sadece mesajın şifrelenmesi ve doğrulanması için kullanılacak simetrik şifreleme anahtarlarının değiştokuşunda kullanılırlar.) Her iki yöntem de önemlidir. Doğrulanmış bir mesaj hala açık metin halindedir ve saldırganlar bu şifrelenmemiş, açık metni okuyabilirler. Bu aşikar bir durumdur, bu kadar aşikar olmayan ise tersidir: Şifrelenmiş bir mesajın otomatik olarak doğrulandığını düşünemeyiz; saldırganlar içeriğini çözemeseler de yola çıkmış olan şifreli mesajı ele geçirebilir ve içeriğine müdahale edebilir, değiştirebilirler. Bu türden istenmeyen bir müdahalenin yol açacağı zararlar şifreli mesajın içeriğinin çözülmesinden çok daha fazla olabilir.

Alice ve Bob'ın güvenli bir iletişim kanalı üzerinden veri değiştokuşunda bulunduğunu varsayın. Hattı gizlice dinleyen Eve isimli kötü niyetli birinin eğer tüm veriyi çözebilirse ne kadar zararlı olabileceğine karar vermeye çalışın. Sonra da aynı Eve'in bu sefer veriye anında müdahale edebileceğini ve taraflara bu değişmiş veriyi yollayabileceğini varsayın, bunun vereceği zararları ölçmeyi deneyin. Çoğu durumda veriye fark ettirmeden müdahale edebilme çok daha ciddi bir saldırı kabul edilir ve sonuçları çok daha vahimdir. Bir başka örnek olarak IP tabanlı YAA (Yerel Alan Ağı) üzerinden depolama alan ağını (SAN - Storage Area Network) kullanan bir şirketi ele alabiliriz. Burada veri hattını dinlemek pasif bir eylemdir ve özel verinin açığa çıkması da kolay değildir (özellikle anahtarlama yöntemi ile çalışan yerel ağlarda). Ancak bir doğrulama mekanizmasının yokluğunda normalde doğrudan kişinin bilgisayarına bağlı depolama aygıtları kullanılırken gerçekleştirilmesi mümkün olmayan sektör seviyesinde veriye müdahale etme işlemi gerçekleştirilebilir. Mesaj doğrulama mekanizması devreye girdiğinde problem ortadan kalkmış olur. Ya da mesela kendi kişisel bilgisayarınızı düşünün. Veri doğrulanmadığı için virüslerin, Truva atlarının ve diğer kötü niyetli yazılımların kurbanı olmanız daha kolaydır. Şifreleme önemlidir ancak doğrulama daha önemlidir. Eğer bilgisayarınız uzaktaki birinin kontrolüne geçtiyse hangi şifreleme yöntemini kullandığınız çok önemli olmaktan çıkar.

Genellikle hem şifrelemeyi hem de doğrulamayı aynı anda kullandığımız için bu iki eylemi bir arada düşünmekte fayda vardır. "Advanced Encryption Standard" (AES - İleri Seviyeli Şifreleme Standardı) süreci esnasında hızlı bir simetrik şifreleme algoritması geliştirdik. MACler genellikle ya blok şifrelerden ya da "hash" fonksiyonlarından faydalanarak inşa edilirler ve benzer hız performasına sahiptirler (bkz. Tablo 1). Ancak bir arada düşünüldüğünde şifreleme/doğrulama bizim istediğimiz kadar hızlı değildir. Bizim bu probleme cevabımız: Helix. Helix hem bir şifreleme algoritmasıdır hem de bir MACtir. Temel fikir şudur: Tek bir algoritma uygula ve her iki sonucu aynı anda hızlıca elde et.

Helix algoritması Pentium II işlemcisi üzerinde çalıştırıldığında bir byte başına yedi saat döngüsünden az zaman harcar ki bu da şu anda resmen kullanılan AES algoritmasından en az iki kat daha hızlı olduğu anlamına gelir.

Helix İşlevselliği
Bir mesajı Helix ile şifrelemek için aşağıdakiler gerekir:
  • 32 byte kadar uzunluğa çıkabilen bir sayısal anahtar. Bu anahtar gizli tutulmalı ve sadece gönderici ile alıcı tarafından bilinmelidir. Pek çok mesaj tek bir anahtarla şifrelenebilir ve doğrulanabilir.
  • Her mesaj için sadece ve sadece bir kez kullanılan, 16 byte büyüklüğünde bir değer olan "nonce". Aynı nonce değerini aynı anahtarla ikinci kez asla kullanmamalısınız. Bu değer herkese açık bir değer olabilir, gizli olmak zorunda değildir. Her mesajın farklı şekilde şifrelenmesini garantiler. Nonce değeri genellikle mesaj sıra numarasından ya da başka bir sayaçtan türetilebilir.
  • Açık (şifrelenmemiş) metin. Bu gönderilecek mesajın kendisidir. (2^64)-1 byte uzunluğunda olabilir. Bunun hemen her türlü iş için yeterli kapasite olduğunu düşünüyoruz.
Helix iki değer üretir:
  • Şifreli metin: şifrelenmiş mesaj, açık metinle tam olarak aynı uzunluktadır.
  • 16 byte uzunluğunda bir etiket (tag): doğrulama işlemini sağlayan bir MAC değeri.
Mesaj anahtarını, nonce değerini, şifreli metni ve etiketi algoritmaya verirsiniz. Algoritma bunun karşılığında size ya açık metni döndürür ya da doğrulama hatasına dair bir bilgi verir. Doğrulamaya dair bir hata ise size şifreli metinde (ya da etikette, anahtarda veya nonce değerinde) şifreleme işleminden sonra bir oynama olduğunu söyler.

Buraya kadar anlattığımız çok temel kriptografi bilgisidir, konu ile ilgili herhangi bir ciddi kitapta bulabilirsiniz (bu bağlamda kendi kitabımızı tavsiye ederiz: "Practical Crytography", John Wiley & Sons, 2003) Helix işlevselliğinin kolayca kendini ele vermeyen tek şaşırtıcı yanı "nonce" değeridir. Söz konusu nonce gerçek bir güvenlik fonksiyonu sağlar. Eğer aynı mesajı iki kere şifreler ve farklı nonce değerleri kullanırsanız iki farklı şifreli metin elde edersiniz. İletişim hattınızı dinleyebilecek olan kötü niyetli kişiler bu iki farklı şifreli metnin aslında aynı açık metne karşılık geldiğini fark edemezler. (Nonce değerinin başka türden güvenlik fonksiyonları da vardır bu yüzden de az önce bahsettiğimiz türden saldırıyı önemsemediğiniz için aynı nonce değerini iki kere üst üste kullanmaya kalkışmayın).

Helix elbette kendi nonce değerini üretebilir ve bunu mesaja ekleyebilir. Ancak pek çok sistem halihazırda bir mesaj numarasına sahiptir ve bunu yeniden oynatma (replay) saldırılarına (ve benzer şeylere) karşı kullanırlar. Mevcut mesaj numarasını kullanarak bir nonce değeri oluşturmak hem daha etkin hem de daha esnektir. Örneğin bir uygulama 128 bitlik bütün bir nonce yerine sadece 32 bitlik bir mesaj numarası gönderebilir ve eğer her iki yönde mesaj göndermek içn aynı anahtarı kullanmak istiyorsanız taraflardan birinin 0x00 ile başlayan bir nonce kullanırken diğerinin de 0x01 ile başlayan nonce kullanması konusunda anlaşabilirsiniz.

Helix Blok Fonskiyonu
Helix Şekil 1'de görülen blok fonksiyonunu kullanır. Tüm değerler 32 bitlik sözcüklerdir. Kullanılan işlemler 32 bitlik toplama ([+] ile gösterilmiştir), XOR (exclusive or) ((+) ile gösterilmiştir) ve bit döndürme işletimidir (<<< ile gösterilmiştir). 4 byte uzunluğundaki bir mesajı şifrelemek (ya da çözmek) için tek bir blok fonksiyonu yeterlidir. Gördüğünüz gibi 12 toplama, 11 XOR ve 20 döndürme işlemi vardır. İlk bakışta fonksiyonun hesaplanması için 43 saat döngüsü gerekir gibi görünmektedir ancak yüksek bir paralellik durumu söz konusudur ve modern işlemciler süperölçekli yapılarını kullanarak tek bir saat döngüsünde iki ya da üç işlemi aynı anda gerçekleştirebilirler.

Tek bir şifreleme işlemi esnasında bloklar numaralandırılır, i numaralı blok Pi açık metin "sözcüğünü" şifreler. i bloğunun tepesinde Z(i) mevcut durum verisi vardır ve bu da beş adet 32 bitlik sözcükten ibarettir. Durum bilgisinin ilk sözcüğü şifreleme işlemindeki anahtar akışı için kullanılır. (Açık metin verisi anahtar akışı ile XOR işlemine tutularak şifreli metin verisi -- ya da çözülmüş metin -- elde edilir). Blok fonksiyonun geriye kalan kısmı durum verisini aldıktan sonra bunu açık metin verisi, anahtar ve nonce değerinden türetilmiş "sözcükle" karıştırır. Sonuçta Z(i+1) elde edilir ve bu da mesajın bir sonraki parçasını şifrelemek için kullanılır. Bu durum verisinin boyu da dikkatli bir şekilde seçilmiştir. Intel mikroişlemcileri 7 yazmaca sahiptir. 5 yazmaç durum verisi için kullanılırken geriye kalanlardan biri mesaj "buffer"ını gösteren bir işaretçiyi depolar ve sonuncusu da anahtar akışı, açık metin ve anahtar sözcükleri depolayan bir çalışma yazmacı olarak kullanılır. Tüm işlemler bu yazmaçlar kullanılarak yapılabilir ve böylece ana hafıza erişimine olan gereksinim büyük ölçüde azaltılmış olur. Helix algoritmasının kriptografik gücü toplama, XOR ve döndürme işlemlerinin karıştırılmasından gelir. Bu işlemlerden herhangi ikisinin kullanıldığı bir fonksiyon kolayca analize ve saldırıya maruz kalabilir ancak üçü bir arada kullandıldığında ciddi bir şekilde matematik olarak analiz işlemini çok zor hale getirirler.

Anahtar Sözcükler
Xi,0 and Xi,1 olarak gösterilen anahtar sözcükler i numaralı blok tarafından kullanılır ve anahtar ile nonce değerlerinden türetilir. Xi,0 256 bitlik çalışma anahtarının sekiz sözcüğü üzerinden döngüye girer. Xi,1 sözcükleri ise daha komplikedir ve çalışma anahtarına, nonce değerine ve özel türden saldırıları engelleyen birkaç parametreye bağlıdır.

Her blokta Helix anahtar akışından bir sözcük üretir. Saldırganların anahtar akışını keşfettiklerini varsaymak zorundayız. (Eğer saldırganlar hem açık metni hem de şifreli metni biliyorlarsa anahtar akışını hesaplayabilirler.) Böylece 160 bitlik durum verisinin 32 bitlik kısmını öğrenmiş olurlar. Şimdi bu bilgiyi kullanarak bir saldırı gerçekleştirdiklerini düşünelim. Blokun başlangıcındaki durum verisinin 32 bitini biliyorlar ancak bloğun kendisi çalışmakta iken biz sisteme anahtar malzemesinden aldığımız iki sözcük daha ekliyoruz (ve saldırganlar bunların ne olduğunu bilmiyor). Böylece saldırganlar blok işlemin sonunda blok durumuna dair herhangi bir bilgiye sahip olamıyorlar.

Doğrulama
Peki doğrulama işlemi nerede? Helix'in getirdiği şık çözümlerden biri de doğrulama işleminin şifreleme işlemi ile aynı anda yapılmasıdır. Her blok işlemi gerçekleştirilirken açık metin girdilerden biri olarak kullanılır. Yani mesaj şifrelenirken blok fonksiyonu anahtarı, nonce değerini ve açık metni alıp harmanlar ve 160 bitlik bir durum verisi oluşturur. Doğrulama işte bu son durumdan türetilir. Temelde yapılan şey şudur: Son açık metin sözcüğünü iyice karıştırmak için blok fonksiyonu sekiz kere daha uygulanır ve sonra gelen dört adet anahtar akış sözcüğü de etiket olarak kullanılır.

Mesajı alan taraf da tam olarak aynı hesabı yapar ve aldığı etiket ile hesaplamış olduğu etiketi kıyaslayarak doğrulama işlemini gerçekleştirir.

Örnek Kod
Liste 1'de Helix'in Python uygulaması mevcuttur. Bu uygulama hız faktörünü göz ardı edip algoritmanın kolayca anlaşılması için bir örnek olarak sunulmuştur.

Başlangıçta birkaç faydalı fonksiyon tanımlıyoruz. _rol32 fonksiyonu 32 bitlik döndürme işlemini yapan fonksiyodur. _strToWords fonksiyonu bir byte dizisini içeren karakter dizisini LSByte uylaşımını kullanarak 32 bitlik sözcükler listesine dönüştürür. _wordsToString fonksiyonu ise ters dönüşümü gerçekleştirir. Helix sınıfının ilk fonksiyonu helixBlock isimli fonksiyondur. Bu fonksiyon Helix blok fonsiyonunu Z durumuna uygular. Burada Şekil 1'deki işlemin doğrudan bir uygulaması söz konusudur.

__init__ fonksiyonu her yeni Helix nesnesi yaratıldığında çağrılır. Argüman olarak anahtarı alır (bu Python karakter dizisi olarak kodlanmıştır) Anahtar 32 byte uzunluğa erişene dek dibine 0 eklenir sonra da sekiz adet 32 bitlik sözcüğe dönüştürülür. Bu sözcükler daha sonra blok fonksiyonu kullanılarak iyice karıştırılırlar. Kullanıcı daha kısa bir anahtar vermiş olsa bile karıştırma işlemi bu sekiz sözcüğün gelişigüzel olmasını sağlar. doBlk fonksiyonu helixBlock fonksiyonu kullanan bir fonksiyondur (wrapper function) ve bloka girecek olan iki anahtar sözcüğünü hesaplar. Bu fonksiyonun asıl işlevi kodun geriye kalanını daha okunabilir kılmaktır.

start fonksiyonu argüman olarak nonce değerini alır ve Helix şifrelemesini ya da şifre çözme işlemini başlatır. Öncelikle nonce kullanılarak X1 dizisi oluşturulur. doBlk aracılığı ile Xi,1 değerleri hesaplanır. Son olarak durum verisi ilk değerini alır ve herhangi bir düz metin verisi işlenmeden sekiz kere blok fonksiyonu çalıştırılır. Bu önkarıştırma işlemi nonce ve anahtarın iyice karışmış olmasını garantilemek içindir. finish fonksiyonu şifreleme ya da şifre çözme işleminin sonundaki görevleri üstlenir. Sekiz blok daha çalıştırır ve 16 byte uzunluğunda bir etiket üretir. Bu yardımcı fonksiyonlar kullanıldığında encrypt fonksiyonunu yazmak kolaylaşır. Tek problem açık metnin tam sayıda sözcükten oluşmama durumudur bu yüzden de gelişigüzel uzunluktaki açık metinle başa çıkabilmek için biraz çaba harcamak gerekir.

decrypt fonksiyonu encrypt fonksiyonuna benzemektedir ancak en önemli farklılık şifre çözme işleminin en son sözcüğü ile ilgilidir. Eğer açık metin 10 byte uzunluğunda ise sadece son sözcüğün 2 byte'lık kısmı kullanılır. Diğer 2 byte hesaplanacak etiket için sıfır olarak tanımlanır. Şifre çözme esnasında açık metin sözcüğünü veren hesaplama fazladan iki byte'ı sıfır ile doldurmaz böylece şifre çözme rutini etiketin hesaplanmasında kullanılmak üzere sıfır ile son düz metin sözcüğünün 3 byte arasında "mask out" yapmak zorundadır. Liste 1 basit bir uygulamadır ve her sözcük için basit bir "mask" hesaplar.

Sonuç ve Bir Uyarı
Helix önemli bir talebe cevap vermek için oluşturuldu: şifreleme ve doğrulama. Tekrar tekrar görüyoruz ki aslında zeki insanlardan müteşekkil komiteler tarafından geliştirilen protokoller şifrelemeyi zorunlu kılarken doğrulamayı önemsemiyorlar. WEP ve Bluetooth ilk akla gelen örnekler. Benzer şekilde IPSec standardının ilk sürümünde de şifrelemeyi kullanırken doğrulama gerçekleştirmeyen bir çalışma modu mevcuttu.

Geçen yıl, Bruce ile Bluetooth kablosuz iletişim protokolünün güvenliğini geliştirien bir mühendis arasında bir diyalog geçti. Bruce, bu mühendise Bluetooth'un gizlilik sağladığını ama aynı zamanda doğrulama da sağlaması gerektiğini söyledi. Mühendis ise psüdo-gelişigüzel frekans sıçramalarının veri izlemeyi neredeyse imkansız kıldığını ve zaten protokol çok kısa mesafelerde çalıştığı için potansiyel saldırgan sayısının çok fazla olamayacağını belirterek cevap verdi. Bunun üzerine Bruce konuyu biraz değiştirir gibi yapıp Bluetooth konusunda heyecanlandığını ve bu protokol yaygınlaşır yaygınlaşmaz Bluetooth destekleyen bir kablosuz klavye ile fare almak istediğini ve bunların ana istasyon üzerinden bilgisayarla haberleşeceklerini söyledi. Bunu duyan mühendis hemen atıldı: "Evet ama Bluetooth'u böyle bir şey için kullanmak istemezsin çünkü kötü niyetli biri araya girip senin yerine sisteme klavye ya da fare hareketleri yollayabilir!" Bruce adama baktı, gülmekle ağlamak arasında tereddüt etti. Uzun lafın kısası doğrulama hayati öneme sahiptir ve genellikle şifrelemeden daha önemlidir. Biz Helix'i bu iki işlevi bir arada sunmak için yazdık.

Helix, yeni bir yapı kullanan yeni bir tasarımdır. (Detaylı bilgi ve örnekler için: http://www.macfergus.com/helix/ ve "Helix: Fast Encryption and Authentication in a Single Cryptographic Primitive," Niels Ferguson, Doug Whiting, Bruce Schneier, John Kelsey, Stefan Lucks ve Tadayoshi Kohno; "Fast Software Encryption 2003: Lecture Notes in Computer Science, Springer-Verlag, 2003" isimli yayında çıkacaktır.)

Helix'i yapabileceğimiz kadar hızlı yaptık yani saldırılarla yüzleşmeye gayet müsait kıldık. Başka bir deyişle bu tasarım yüksek riski alan bir tasarımdır. Birkaç yıl içinde bu algoritmaya karşı düzenlenen saldırıları görmeyi bekliyoruz. Bunların sonucunda Helix'i ciddi uygulamalar için tavsiye ediyoruz. Eğer daha düşük performans sizin için sorun değilse geleneksel algoritmalardan birini kullanabilirsiniz. Eğer gerçekten böyle bir hıza ihtiyaç duyuyorsanız Helix'i düşünmelisiniz. Elbette insanlar algoritmayı detaylı olarak inceledikten sonra farklı önerilerde de bulunabiliriz.

Teşekkürler

Helix, Niels Ferguson, Doug Whiting, Bruce Schneier, John Kelsey, Stefan Lucks ve Tadayoshi Kohno tarafından tasarlanmıştır.
(*) Niels serbest çalışan bir kriptografi danışmanıdır. Bruce, "Counterpane Internet Security" şirketinin kurucusu ve baş teknik sorumlusudur. Niels ve Bruce "Practical Cryptography" (John Wiley & Sons, 2003) isimli kitabı yazmışlardır ve sırası ile niels at macfergus dot com ve schneier at counterpane dot com adreslerini kullanarak kendileri ile temas kurabilirsiniz.

Liste 1: Örnek Kod

Görüşler

0
eitatli
Bildigim kadari ile Helix'in bir acigi bulundu ve ayni gurup yamasini düzeltip yeni bir isimde yayinlamak üzereler. Ancak bu is yamalarla yürüyecek olursa, herhelde rafa kaldirilir. (Ref: See all Windows versions :-))
0
FZ
Afedersiniz, ben biraz araştırdım ama alakasız şeyler çıkıyor eğer sizin bilginiz varsa lütfen Helix şifreleme algoritması ile ilgili olarak bulunmuş olan açığa dair bir duyuru URLsi verebilir misiniz, gidip bir bakalım neymiş ne değilmiş.

Yamalara gelince, valla Solaris'te, GNU/Linux'ta bu iş nasıl yamalarla yürüyorsa o şekilde yürür herhalde (algoritmaları kast etmiyorum, işletim sistemleri ve uygulamalar bağlamında konuşuyorum). Şimdiye dek yama yayınlamayan ve bir sürü yama yapılmasını gerektirmeyen işletim sistemi ile pek karşılaşmadım. Tabii algoritmalar söz konusu olduğunda durum farklı, orada doğrudan fikirdeki bir zayıflığın elenmesi söz konusu, elenir mi elenmez mi onun da ayrıca incelenmesi gerekir.
0
eitatli
Acigin tam olarak ne oldugunu bilmiyorum, ancak gelistiricilerinden biri ile konustum ve kendisi yeni versiyonu üzerine calistiklarini söyledi. Adi da Felix.

Yama konusundaki yorumum ise yine kendisinden elde ettigim izlenimdi.
0
FZ
Meraklısına not: makalenin orjinalinin yayınlandığı DDJ yani Dr.Dobb's Journal dergisi 25 yılı aşkın süredir yazılım geliştiricilere yönelik çıkan çok güzel bir dergi ve Internet üzerinden 1 yıllığına abone olursanız aylık 6-7 YTL civarı bir para geliyor (hem basılı hali hem de arşivlere Internet erişim, html ve .pdf hali, vs.) Bu dergiyi Türkiye'deki bir satıcıdan almaya kalkarsanız 25-30 YTL civarı bir para vermeniz gerekiyor sayı başına. Bu da insanların önyargılı olmasına ve doğrudan Internet'ten abone olurlarsa en az aylık 25-30 YTL ödeyeceklerini düşünmelerine yol açıyor maalesef, oysa gördüğünüz gibi durum tam tersi, doğrudan abone olunca 5-6 kat daha ucuza geliyor.
0
Inspector
0
e2e
Ellerinize sağlık.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Wright Kardeşler ve Patentlerin Kötüye Kullanımı

sundance

İlk rastladığım gün Sweet Sweet Unemployement yazısı ile manevi kardeş bellediğim Maciej Ceglowski'nin Wright Kardeşler üzerine bir yazısına rastladım.

Havadan ağır bir araçla ilk kontrollü uçuşu gerçekleştirip, patentini alan, daha sonra da ikibuçuk yıl boyunca patenti lisanslamak ya da geliştirmek için hiçbir şey yapmayıp sadece bu alanda deneme yapanları dava edip para kazanan Wright kardeşler de, Tesla'ya yaptırdığı (ve parasını ödemediği) direkt akım jeneratörleri ile "alternatif akım hepimizi yakacak" diyen, bir file alternatif akım verip öldüren ve akabinde de elektrikli sandalyenin icadına bile vesile olan Edison'un yanında yerlerini almışlar.

Sistem Yöneticileri Günü

FZ

Onlar çoğu kişi için görünmez adamlar. Bilgi işlem odasının soğuk koridorlarında gezen ve şirketin kesintisiz bir şekilde çalışmasını sağlayan insanlar. Ancak bir problem çıktığında hatırladığımız meçhul kahramanlar. Hâlâ tahmin edemediyseniz söyleyelim: Onlar Sistem Yöneticileri ya da çoğumuzun alışık olduğu deyişle SA veya SysAdmin ve bugün onların günü, 26 Temmuz Cuma günü resmi Sistem Yöneticisi Günü olarak belirlenmiş durumda.

364 gün boyunca takdir etmeyi çok fazla aklımızdan geçirmediğimiz bu insanlara bir günü çok görecek değiliz herhalde! Yeni bilgisayarları ağa ekleyen, yeni kullanıcı hesaplarını açan, sistem yazılımlarını kuran, virüslerin yayılmasını engelleyen ve her türlü soruyu (abuk sabuk olanlar da dahil) cevaplayan bu cefakâr insanların duygularını belki de en iyi bu karikatür yansıtıyor.

Bugün Sistem Yöneticinizin şirket için ne kadar çalıştığını düşünün ve ona bir hediye alın (olası hediyeler ve asla alınmaması gerekenlerin güzel bir listesini ilk linkten öğrenebilirsiniz), en azından bugünü duyurarak ona hak ettiği saygıyı gösterin.

fazlamesai.net'e soralım: Boyu mu işlevi mi? 30 inç monitörler ve diğerleri...

FZ

30" monitörler ile bilgisayardaki işlerinizde kayda değer bir verimlilik artışı sağlayabilir misiniz? Yahoo'daki bu başlıklı makale önemli bir soruya parmak basıyor.

Hazırlanan bir rapora göre [PDF], gerçekten de 30" gibi büyük bir monitör ciddi üretkenlik ve verimlilik artışı sağlıyor. Diğer yandan tek bir kocaman monitör yerine 2 ya da 3 monitör tercih edenler (2 x 17", 19" + 2 x 17", vb. konfigürasyonlar) ve bunun çok daha verimli olduğunu iddia edenler de mevcut.

FM Camiasından Danışmanlık Talebi

FZ

Böyle bir haber yazacağım aklıma gelmezdi ama sanırım FM sitesi ve camiası epey olgunlaştı. Görelim o halde!

Mesele kısaca şu: Ağırlıklı olarak matematik, mühendislik ve bir miktar yazılım eğitimi almış, birkaç ay sonra mezun olacak genç bir dostum bana bugün aşağıdaki gibi bir e-posta yollamış:

fazlamesai.net'e soralım: Büyük Firmalar, Websitesi Kıranlar ve Müşteriye Saygı

Ragnor

Büyük masaüstü frp oyun geliştiricilerinden WhiteWolf'un sitesi cracker'lar (Hayır hacker demeyeceğim işte :)) tarafından kırılmış. Ama bu haberi yazma nedenim bunu söylemek değil. Nedenim WhiteWolf'un örnek ve de beklenmedik davranışı.